BeremoTe

A Bluetooth Project
Steen Larsen (zool@diku.dk)

Jesper Hansson (hansson@diku.dk)

15th December 2004

An electronic museum guide.

Abstract
This project concerns building an electronic museums guide, having BlueTooth
as the primary network source. Our primary goal was to study Bluetooth and to
develop a small application showing the advantages and disadvantages of BlueTooth
in a location and context-based environment like this. Another other goal was to
research and test the dierent stacks implementations and supported Bluetooth
hardware, which we had available. As a result we developed the museum application
using BlueZ for Linux, as the server part and using a Nokia 3650 Series 60 cell phone
with Symbian OS for the client side.
Our application seems to t our needs for location based services pretty well,
and even increases the context awareness as well. But we also uncovered some
disadvantages, as the re-connect time seems high and through-put at the other end,
not very high......

Preface
This report is written by Jesper Hansson and Steen 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 project
concerning Bluetooth and being remote.
The source code for the project can be found on the included CD-ROM. This
report itself can also be found on the CDROM in dierent formats.
Our CDROM contains:
source Contains the source code for the server and client.
report Contains this report in dierent formats.
report/litterature Contains the external litterature we had available electronically. Like small reports, larger references etc.
test Contains images, screendumps and videos etc. from our test scenario.

ii

Contents
1 Introduction
1.1 Motivation . . . . . . . . . .
1.2 The Structure of the Report
1.3 Prerequisites of the Reader
1.4 Goals . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

2 The Application Idea

2.1 Presentation of the Application . . . .
2.2 Outlines of the Application . . . . . .
2.2.1 Advantages of the Application .
2.2.2 The Application scenario . . .
2.2.3 System Description . . . . . . .
2.3 Limitations . . . . . . . . . . . . . . .
2.4 Why use Bluetooth? . . . . . . . . . .
3 The
3.1
3.2
3.3

3.4
3.5
3.6
3.7

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

Bluetooth Architecture
Bluetooth Introduction . . . . . . . . . . . . . . . .
Bluetooth network topology . . . . . . . . . . . . .
Bluetooth Protocols . . . . . . . . . . . . . . . . .
3.3.1 Bluetooth Radio (RF) . . . . . . . . . . . .
3.3.2 The Baseband . . . . . . . . . . . . . . . . .
3.3.3 The Link Manager Protocol (LMP) . . . . .
3.3.4 HCI interface . . . . . . . . . . . . . . . . .
3.3.5 Logical Link Control and Adaption Protocol
3.3.6 RFCOMM . . . . . . . . . . . . . . . . . . .
3.3.7 Service Discovery Protocol (SDP) . . . . . .
3.3.8 OBEX - FTP - PAN . . . . . . . . . . . . .
3.3.9 Audio . . . . . . . . . . . . . . . . . . . . .
Throughput . . . . . . . . . . . . . . . . . . . . . .
Bluetooth proles . . . . . . . . . . . . . . . . . . .
Low power operation . . . . . . . . . . . . . . . . .
Security . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1 Frequency hopping . . . . . . . . . . . . . .
3.7.2 Authentication . . . . . . . . . . . . . . . .
3.7.3 Authorization . . . . . . . . . . . . . . . . .
3.7.4 Encryption . . . . . . . . . . . . . . . . . .
3.7.5 Pairing . . . . . . . . . . . . . . . . . . . .
3.7.6 The device database . . . . . . . . . . . . .
3.7.7 Device address ltering . . . . . . . . . . .

iii

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
(L2CAP)
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

1
1
2
2
2

.
.
.
.
.
.
.

3
3
4
4
5
6
7
7

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

9
9
10
11
12
13
14
15
15
16
16
19
19
20
21
21
22
23
23
23
23
23
24
24

4 Platform System Engineering

4.1 BlueTooth Server . . . . . . . . . . . . . . . . . . . .
4.1.1 Bluetooth stack implementations . . . . . . .
4.1.2 Stacks on Linux . . . . . . . . . . . . . . . . .
4.1.3 Stacks on FreeBSD . . . . . . . . . . . . . . .
4.1.4 Stacks on Windows . . . . . . . . . . . . . . .
4.2 BlueTooth Client . . . . . . . . . . . . . . . . . . . .
4.2.1 Symbian OS . . . . . . . . . . . . . . . . . . .
4.2.2 Java . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Sony Ericsson T610 . . . . . . . . . . . . . .
4.2.4 Nokia 3650 . . . . . . . . . . . . . . . . . . .
4.2.5 Compaq iPAQ h3670 running Familiar Linux
4.2.6 HP iPAQ h1940 running MS Windows Pocket
fessional . . . . . . . . . . . . . . . . . . . . .
4.3 Choosing platform . . . . . . . . . . . . . . . . . . .
4.3.1 Bluetooth Server . . . . . . . . . . . . . . . .
4.3.2 Client . . . . . . . . . . . . . . . . . . . . . .
5 System Design
5.1 Connections . . . . . . . . . . . . . . . .
5.2 Positioning . . . . . . . . . . . . . . . .
5.3 Network Topology . . . . . . . . . . . .
5.3.1 Server/Exhibition Item setup . .
5.3.2 Choice of Power Class . . . . . .
5.3.3 Piconet - Scatternet . . . . . . .
5.3.4 Bluetooth server device bundling
5.4 SDP . . . . . . . . . . . . . . . . . . . .
5.4.1 The museum service record . . .
5.4.2 Handling of several clients . . . .
5.5 Security level . . . . . . . . . . . . . . .
5.6 The actual connection . . . . . . . . . .
5.6.1 Simple text . . . . . . . . . . . .
5.6.2 Data as les . . . . . . . . . . . .
5.6.3 Audio . . . . . . . . . . . . . . .
5.6.4 Video . . . . . . . . . . . . . . .
5.6.5 Miniprotocol over L2CAP . . . .
5.6.6 Establishing the connection . . .
5.6.7 Data transfer . . . . . . . . . . .

iv

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
PC 2003 Pro. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

25
25
25
26
28
28
28
29
29
30
30
31
31
31
31
32
33
33
34
35
35
37
37
37
37
38
38
39
40
40
41
41
42
42
42
42

6 Program Description
6.1 The BlueTooth server . . . . . . . . . . . . .
6.1.1 Bluetooth applications development on
6.1.2 Server Design . . . . . . . . . . . . . .
6.1.3 Implementation description . . . . . .
6.1.4 Problems arose during implementation
6.1.5 Server user guide . . . . . . . . . . . .
6.2 The Bluetooth client . . . . . . . . . . . . . .
6.2.1 Symbian Programming . . . . . . . . .
6.2.2 Bluetooth applications development on
6.2.3 Client Design . . . . . . . . . . . . . .
6.2.4 Implementation description . . . . . .
6.2.5 Problems arose during implementation
6.2.6 Users guide - Testing BeremoTe on the
7 System assessments and test
7.1 Testing the client (Nokia 3650) . . . . . .
7.1.1 Testing a connection . . . . . . . .
7.1.2 Testing disconnect and reconnect .
7.1.3 Conclusion about the client test . .
7.2 Testing the server (Linux PC with BlueZ)
7.2.1 Testing the HCI layer . . . . . . .
7.2.2 Testing our advertising . . . . . . .
7.2.3 Authentication . . . . . . . . . . .
7.2.4 Connection test . . . . . . . . . . .
7.2.5 Conclusion on the server test . . .
7.3 Other tests . . . . . . . . . . . . . . . . .
8 Conclusion

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

. . . . . .
BlueZ . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
the Nokia
. . . . . .
. . . . . .
. . . . . .
mobile . .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
3650
. . .
. . .
. . .
. . .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

44
44
44
45
45
50
50
51
51
53
54
56
58
59

.
.
.
.
.
.
.
.
.
.
.

61
61
62
62
63
64
64
64
64
65
67
67
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 . . . . . . . . . . . . . . . . . . . . . . .

A.5.1 Installing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80
80

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

vi

Introduction

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

1.1

Motivation

Our motivation arose back in 2003, when we took part in a robot competition
called Robocup (http://www.robocup.dtu.dk/). We build a rather embedded and
complicated 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 BlueTooth
network. Since our focus at the time was on the robot competition, we did not have
any 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 the
competition began to take place, we realized that our debug method was quite a
hazle. 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 debug
information we had recorded during a lap. This really motivated us to take a closer
look 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 also
make a real-time debugging a possibility. All this fuss about the robot increased
our interest and attention towards BlueTooth. It gave us a lot of other great ideas
like: remote controlling the robot, streaming the images from the robot etc. We
had to investigate what kind of possibilities BlueTooth oered.
During our early research (early 2004) we investigated dierent types of BlueTooth devices and what can and what can not be done with these devices. One of
the great advantages in BlueTooth lies in the huge support in all kind of devices. It
is supported in USB dongles to ordinary PCs, PDAs like the iPAQ, cellphones and
other embedded devices.
During our research Steen was on a small summer vacation to Spain (more
precisely Malaga) and visited the Pablo Picasso1 Museum.
While Steen wandered about in the museum it began to irritate him, that a
lot of the explaining text to the specic 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 get
the text in a Localized language (in Steens case: English or Danish) and get it
presented to him in a nice and easy way. We talked about the idea for some time
1

The 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 to
show 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 will
introduce the idea behind the application. In chapter three we will try to explain
the theory and go through the architecture behind Bluetooth and what kind of possibilities it has. The focus will be put on the parts of the Bluetooth stack, which
are relevant for developing the chosen application. The more hardware specic details and the lowest levels of the protocol will be only shortly introduced. We have
dedicated chapter four for concerns about choosing the platform and the BlueTooth
stack. We have done this because, we had not yet decided which platform to implement 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 a
program 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 anything
about bluetooth in advance although it would be a small advantage. Our audience
is targeted towards our fellow students taking Computer Science courses or other
developers just interested in Bluetooth.

1.4

Goals

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 dierent Bluetooth devices and stacks.
3. To implement a small application which show these advantages/limitations.

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 it
all2 . 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 greater
aspect. We developed our idea further and decided to make an electronic and remote
museum guide, which could provide information to a visitor at a museum, through
his or hers handheld device. In this way we would be able to stream out context and
location-based information to the visitor. To begin with the museum application
should of course be thought of as a service to a hypothetical museum that provides
the means of a client/server solution with the Bluetooth as a network connecting
them.
The guest should plot in his age, language, dierent kind of art taste, knowledge
level and other personalized information into his or hers handheld device (the client).
This would allow the museum server to rene the information presented and targeted
to the user as detailed as possible. The visitor will then get the information about
the art artifact in his language, at his level of knowledge and in his taste. The
handheld device would receive the stream from the server and explain by a text
message (or audio) what kind of exhibit he or she is standing in front of in the given
museum. It would also show images of other art artifacts related to the room or
exhibit 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 enormous
potential and could easily be extended to a lot more features such as: the visitor
could get an appointment about the start of special events at his handheld, bargain
souvenirs, announcements (the museum is closing etc.) or paging a human guide
etc. Guided services could also be oered, so that the handheld could show a specic
way 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 locationbased service will only strengthen the context-awareness. As we can see it, an end
developed and complete context-aware system like the, will have endless possibilities
to be implanted in real Museums and have many future extensions. One could
imagine a nice scenario at a real museum like "Arken" or even better "The Danish
Museum of Art" (Statens Museum for Kunst). . .
Actually we could as well have designed and implemented some other kind of
2

We 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 of
problems. They will involve a discussion of the many aspects and problems of using
Bluetooth as a network.
The objective for the project (goal 3) as dened in 1.4) will therefore be to
develop and implement a pilot project of the museum guide, which shows the limitations 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 the
state 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 the
advantages for them into two groups, to show that it is a mutual benet for the
visitor 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-exible. Our
solution could provide customization what audio to be played could be chosen by
the 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 information
particularly interesting to him. He could choose between dierent presentations:
text, audio, video, pictures etc. when he wanted to. Langague both in audio and
text settings could be implemented to suit tourists needs. The visitor could also
choose to save some of the data presented to him for later use, e.g. in a school
project or to show to his family - instead of having a lot of brochures with data
irrelevant to him.
The visitor could get the data presented to him in a personal way, if he entered
data about himself, preferences etc (a visitor prole). A tour could be generated for
him based on this (prole). This is the classic attendant tour, but suit to the single
visitors needs. Imagine the possibilities e.g. in "kids proles".
3

A 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.
4
kustode in Danish.

When the visitor leaves the museum, the museum could advertise for up-coming
event, and even put them into the visitors electronic handheld calendar - if the
visitor 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 where
the visitors have been and can thereby focus on which exhibits have fallen into
the interest of the visitors and which have not. This could be benecial for the
museum, because they could suit the visitors expections and needs better, which
might increase the number of visitors. Maybe fewer attendants would be needed.
This could be inect on the museums economy in a positive way.
The museum could deliver special on-demand announcements targeted at specic
guests (maybe determined by their registration prole), and when the visitor leaves
the museum could advertise for up coming events to promote their next exhibitions
or events. These event could be inserted to the visitors personal calender if he
wants to.
The maintenance could be done directly to the central database for simple management.
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 attendant

for 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 we
imagine it:
1. The visitor of the museum registers their handheld device, download and install
the 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 can
choose a dierent level of details.
4. The visitor chooses their own path through the museum and get information
about the dierent exhibit items they pass along the way.
5. This information could be audio streams, pictures or plain text, which will be
delivered 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 some
way relating to one or more art artifacts or pictures. Each of these devices are
interconnected to a bluetooth server which again is connected to a database server
(see gure 1). In this way we should be able to fetch data from the database and
send 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 be
some kind of ordinary TCP Local Area Network (LAN). A wireless LAN instead
of standard cables would be preferable though, because our virtual museum could
cover several 1000 of square meters where cables wouldnt be very comprehensive.
The wireless LAN speeds are now so high (54Mbit/s) that we think it could cover
the needs.

Figure 1: Our museum scenario and setup

Denitions .
To avoid confusion among dierent concepts we will here give some denitions which
we will use in all our forthcoming chapters. The denitions are related to gure 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 is
connected (wireless) to the central database server
Central database server A server which handles database queries between Bluetooth servers and a database.
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 implement
the entire idea as it was just presented. We will focus on the parts concerning
Bluetooth. For example considerations regarding GUI (Graphics User Interface),
database, proles of the visitor etc. will not be discussed, but some of the central
Bluetooth subjects, which we will cover, are: network setup, the Service Discovery
Protocol, connection handling and data transfer.
We will only present the part of the Bluetooth theory (chapter three) that we
nd important to this application, though our knowledge go deeper than this after
our 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 these
can 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 oer the features which we
need. Section four is dedicated to the discussion of what device to chose.

2.4

Why use Bluetooth?

The rst 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 a
short 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 its
long 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 embedded

devices 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 very
probable that it will become standard within the next few years. If a museum has to
purchase handheld devices with wireless support for the visitors it would be pretty
expensive (600$ a piece). At present time most people carry a cell phone with them
anyway, 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.

It 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

The Bluetooth Architecture

In this section we will go into the theory behind Bluetooth technology and how it
works. We will start out with a short introduction of Bluetooth and explain how
the network works. Then we will make a comprised walk-through of the dierent
layers 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 ideas
and limitations for how to set up the network in our application. In the protocol
walk through we will focus on the parts that are central to our application, but we
will 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, since
you can not program for Bluetooth without knowledge of the security functions.

3.1

Bluetooth Introduction

The Bluetooth technology was originally developed to give the end user a opportunity to get rid of small-length cables and unreliable IrDa (Infrared beams) and
to give them the opportunity to wireless communicate together within short range.
The Bluetooth standard it self was proposed by Ericsson in 1994 and is now one
of the most used and fastest developing de Facto standards within wireless communication. It was originally named after the great viking Harald II, nicknamed
Bluetooth due to a tooth disease (910-987 AD). Harald ruled during the 10th century in Denmark during a very troubled period of time. Also the ocial Bluetooth
logo is made out of old runes, consisting of a H and B.
Currently we have a lot of personal devices that support the BT technology, such
as: cell phones, headsets, PDAs, USB dongles for PCs, smart tags etc. Usually these
devices are used for synchronization, exchanges of les, 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 to
use wireless uplink (bridge) for laptops and because of the possibility of wireless
connection to Bluetooth headsets.
The development of personal Bluetooth units and smart tags in Denmark has
been enormous. The Danish company BlueTags[32] released a small smart tag
device this year that was able to track customers and their whereabouts. In Aalborg
ZOO in Denmark, BlueTags has provided the ZOO, one of Denmarks largest
zoological gardens, with a BlueTag tracking system allowing the Zoos visitors to
keep constant track of each other and their kids. Also in one of Denmarks (even
Europes) 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 be
able to take advantage of the system and keep track of each other. So now, all the
parents in Tivoli have to do is to rent a tag and attach it to the childs clothes or
place it on their wrist and thereby they can constantly know about their childs
whereabouts. This is done by the parents send out a SMS (Short Message Service)
on their mobile to a specic number, and gets back the childs position. The
position of the child (and smart tags) are snied by installed base stations (access
points).

3.2

Bluetooth network topology

The topology of the bluetooth network is a little dierent from the "normal" topology of a computer network, because of its ad-hoc nature. Thus the "normal" distinction between clients and base stations can not be made. This approach is chosen
because Bluetooth devices are often on the move, and they often only need a small
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 other
kind of topology. There are three kinds of Bluetooth network topologies (see also
g. 2):
a: Point-to-point Connection between two devices. One device is master the
other one is slave.
b: Piconet Also called point-to-multipoint. One master has two or more (maximum 7) slaves. The master is by default the initiating device that establishes
the communication. The master of the piconet controls the communication
ow in the piconet. These roles of the master/slave relationships are cancelled
when the piconet cease to exist. After that any device in the net can become
a master or a slave. The low number of participating devices is in order to
keep up the high network capacity (throughput) between the devices.
c: Scatternet Is when two or more piconets melt together. There will still be one
master per piconet. But one device can be master in one piconet and slave in
another. Scatternets have even worse network capacity, because one or more
devices participate in more networks. 6
The device that invites other devices to establish a connection becomes the
master of the network. In other words, it is only the master that can initiate a connection - this is only meant on the physical link level. For instance, an "application
connection" can be initiated by a slave.
6

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

10

Figure 2: The dierent kinds of topologies.

The protocol supports that two devices change roles (slave/master). This
can become necessary if a device serves as LAN access point and another device
connects to it and becomes master. If more devices are connected to the access
point, a master/slave shift is needed to keep the piconet topology (see g. 2). The
protocol 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 trac on a piconet goes
through the master. It means heavy workload for the master and a narrowing
of bandwidth, when more devices enters the network. Thus communication
between two slaves in a piconet goes through the master which broadcasts to all
other 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 can
not cover everything, we will try to focus on the parts that are important to the
development of our application.
The layers above the Host Controller Interface (HCI) are often referred to as
the "The Bluetooth Module", and the lower layers are often referred to as "The
Bluetooth Host" (see gure 3). The Bluetooth Module is the "hardware part" and
the Bluetooth Host is "software part" of the stack. The HCI layer is the driver
needed to get the two parts to communicate with each other.

11

Figure 3: The Bluetooth protocol

3.3.1

Bluetooth Radio (RF)

As explained before, Bluetooth is a wireless technology. It uses a radio to transmit

the 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 of
noise 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 other

devices 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 way
every package, is sent on a dierent frequency in a given time slot.
During connection the master gives the slave a "code" to synchronize the Frequency Hopping. In this way the two devices know when to send/listen on what
frequency. In this way the BT radio will retransmit packages on a dierent frequency, if a frequency is jammed up. The constant change of frequency has the nice
side eect that it makes evesdropping very hard.
Bluetooth channels use a FH/TDD (frequency hop/time division duplex)
scheme. The channel is divided into 625 microsecond interval time slots. This

12

gives a hop rate of 1600 hops/sec. A dierent hop frequency is used for each slot
according to the frequency hopping sequence of the piconet. The sequence is determined by piconet masters device address and its clock, and is distributed to the
clients. One packet can be transmitted per slot. A slave may transmit to the master
only if he was addressed in the previous slot.

Power Classes The range of Bluetooth is dependent on the power class of the
radio unit. 3 Power classes are dened. 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 most
common range is 10 meters, since it has the lowest power consumption, and the
Bluetooth 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 dened limits of each power class. See 3.3.3 for more
information, and [1] for Power Class denitions.
The RF is mostly relevant in our project in connection with network setup
considerations - 5.2 and 5.3. Frequency hopping also impacts security 3.7 and 5.5.

3.3.2

The Baseband

The Baseband layer, aka. the Link Controller, is also physical implemented in the
chip closely related to the sending/receiving mechanism. It creates the packages to
be send via the RF layer and receives packages from the RF band. The Baseband
manages the ow control - It is responsible for ordering and re-sending packages
and synchronization of the device clocks.
This section gives the fundamental understanding of the Bluetooth connection
types SCO and ACL. The connection is a very central issue in this report, and is
commonly referred to in chapter 3, 5, 6 and 7.
We will not discuss the package types in details, only mention that dierent types
exist. They represent dierent trade-os 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, time
slots (See 3.3.1) are reserved for the connection. This means that a device can be
sure that it can send to the other device regularly, but no resending can be done
because the next time slot is reserved for the next packet. A device can have up

13

to three SCO connections open at one time, three if it is to the same device or two
dierent devices. The SCO connection is often used for transmitting audio. The
throughput 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 dierent in piconets.
This is due to problems synchronizing two piconets.

ACL The packet based connection. There can only be one ACL connection between 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
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 are
controllable through the HCI layer - See 3.3.4.
Standby the device is inactive and the radio is turned o.
Inquiry & Inquiry Scan The inquiry procedure is a process where one Bluetooth
device tries to nd all neighboring enabled Bluetooth devices. A device that is
trying to scan for other devices is said to be in "Inquiry state". The device that
listens for an inquiry request is in "Inquiry Scan state". This "Inquiry Scan
state" 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 established - the low level connection procedure. When a device is about to connect
to another device found by the inquiry procedure it enters the Page state. The
paging 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 following
four substates: Active, Hold, Sni or Park. These states are essential to
Bluetooth 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 stack
a.k.a. The Bluetooth Module. Applications communicates to LMP through the
HCI interface (See 3.3.4).
The LMP controls the links to other devices. It both controls connecting, detaching and master/slave switches. Besides this, it is responsible for setting up the
ACL (data) and SCO (voice) connections. More connections between two devices
can be handled at one time. During establishment of connections the LMP must be
aware of the security level. For a more elaborate explanation read 3.7.

14

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 this
name.
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 Signal
Strength 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 receiving
this, can then decide whether it wants to adhere the request. Of cause maximum
and minimum power levels are dened, see [1].
Besides determining the throughput on a connection it can increase the overall
throughput, because there might not be room for extra connections and negotiations
for such will not be necessary.

3.3.4

HCI interface

The HCI (Host Controller Interface) is an interface which denes standards for the
Bluetooth Host to communicate with the Bluetooth module. An application can
access various functions in the Bluetooth module through this interface. We will
not 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 the
Bluetooth module to the Bluetooth Host. The HCI transport layer is the driver that
connects 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 oers both connection-oriented
and connection-less data services to the upper layers. This is the basic protocol in
the upper part of the protocol stack. All asynchronous data communication goes
through this protocol.
Many L2CAP links can be managed through one ACL connection. L2CAP manages the links through dierent 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, if
more connection inside one process should be handled. However, if more processes
are spawned, they can all listen on same PSM without conicting.

15

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 modem
commands can be used through RFCOMM, since it emulates the RS232 standard
serial port. By associating a COM port with the RFCOMM connection, standard
serial software as MiniCom and HyperTerminal can be used to read/write text/data
through the connection.
More RFCOMM channels can be open at the same time, they just have to have
the same number of L2CAP PSMs open underneath. The maximum number of
connections is implementation specic.
The protocol is a reliable connection oriented streaming protocol. It provides
ow 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 oers
and 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 oce. A Bluetooth device
enters the oce 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 a
device can be both client and server simultaneously. There can be maximum one
SDP server per device. Other devices, i.e. the clients, can then search and browse
these services.

Attributes A service is described through a number of attributes. These attributes contain information about what kind of service it is and how the client
should use it. The structure of an attribute contains a ID (16 bits) and a Attribute value (exible in length). Here is a list some of the more interesting dened
attributes:
ServiceRecordHandle A 32 bit number uniquely identifying a service record
within a server.
ProtocolDescriptorList A list of protocols which are needed to use the advertised
service.
BrowseGroupList A list of public groups which is used when browsing
services3.3.7
ProviderName The advertised provider name for the service.

16

ServiceName The advertised service name for the service.

ServiceDescription An attribute describing the service.
BluetoothProleDescriptorList A list that contains the bluetooth proles (see
3.5) supported by the service.
ServiceAvailability An 8 bit number that indicates the relative availability of
service for the clients connecting.
ServiceRecordState A 32 bit number that is changed whenever an attribute in
the service record changes.
A complete list can be found in the Bluetooth Specication [17]. As Bluetooth
evolves and new proles emerge more attributes will be dened.

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

UUIDs Each service record has a Universally Unique IDentier (UUID). The
UUID can either be dened in the specication and will thereby be unique or manufacturers can dene UUIDs. These UUIDs are also garantied (read very very improbable that clashes occur ) to be unique7 . Since UUIDs are unique, no central
database is necessary to control the UUIDs.

The SDP connection To establish a SDP connection to the SDP server, a

L2CAP 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 be
elaborated below. 8
7

The procedure and conventions for producing the UUID is not relevant to us, see [1] p.206 for more
detail.
8
For a more elaborate explanation of SDP connection establishment see p. 1106 in [17] and/or SDP
connection establishment p. 222 in [1]

17

Searching services A service search is when a device queries for one or more
services. This is used when a device wants to look for a (list of) specic service on
a remote device.
Standard procedure: First a "Service Search" is performed. When the ServiceHandle for a wanted service is obtained (if any) the inquiring for the attributes of
the service can be done ("Service Attribute").
Alternative procedure: "Service Search Attribute" which is a combination of the
rst 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 the
servers set of services is complex, this makes it more manageable and clear if a
client wants to browse through the servers services. The organization is done in
a tree like structure. A PublicBrowseRoot UUID is dened by convention, and is
known by all devices. From this root the tree is grown. A leave on the tree can
either be a service or a group. There can be no subtree from a service, and a group
can have one or more groups and/or services in its subtree.
A client can browse through the servers services starting from the PublicBrowseRoot.
The service provider can decide which services will be browseable[1].

Connection establishment We will here introduce the way a connection

should 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 specic class of service or browse through services on the remote
device
Retrieve the attributes for the chosen service record from the remote SDP
server

18

 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 the
procedure, 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 the

SDP protocol. Based on the chosen stack, it therefore varies a little how the
application 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 lot
from implementation to implementation, and so on. . .
This were the basics of the SDP idea, which we will use in our discussion of SDP
5.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 les and data through a simple interface. Originally
the OBEX is a IrDa specication standard (see www.irda.org for details). OBEX
includes, like the IrDa standard, means to represent data in a object model and a
session 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 objects
and visit cards (also called vCalendar and vCards). This provides an easy ad-hoc
way 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 le transfer utility.
Implementation of OBEX can very at little from developer to developer, since
no OBEX prole has been dened (there is only an OPP: Object Push Prole).
It runs on top of an PAN (Private Area Network) protocol (TCP/IP protocol and
more) or in some implementations on top of RFCOMM. Since it is a higher level
protocol 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 common
codecs 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.

19

When sending audio over a SCO link, the data is sent directly from the
Baseband 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 for
simple speech in headsets and its like. Especially when packets are lost (e.g.
when approaching maximum range) the quality reduces dramatically, since no
retransmission is possible on a SCO link.
It is also possible to send audio through an asynchronous data connection (ACL).
Recently new proles have been dened [15]. The Generic Audio/Video Distribution
Prole (GAVDP) and the Advanced Audio Distribution prole (A2DP) denes new
standards for sending better quality (e.g. mp3 quality) stereo sound through an ACL
connection. New protocols has evolved too, one of them is Audio/Video Distribution
Transport Protocol (AVDTP). As the names imply standards for streaming video
has been set. Unfortunately these proles are only implemented in very few stacks.
We also considered audio for the museum application - read more in 5.6.

3.4

Throughput

The bandwidth of a Bluetooth connection is hard to predict, because it depends on

many 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 (Actual
data throughput - without headers). This is calculated for an L2CAP connection9 ,
since it is the lowest layer protocol you can send user data through, and therefore
has the lowest header overhead.
These values will very rarely be achieved. Though distance between devices
has low impact on performance [9], packet collisions with packets in nearby
Bluetooth networks and disturbance/pollution on the radio spectrum decreases
the performance. Network structures other than peer-to-peer also decrease overall
performance (See 3.2). Error correction, channel congestion, and ow control also
limit throughput. Packet headers from higher layered protocols, will decrease
performance for them. The higher the layer, the more overhead, and thus worse
performance.
The throughput could be a problem for the museum system if the performance
is to poor.
9

Using packet type DH5 (the biggest packets available). The packet type greatly impacts
performance[9]. For more information on packet types refer to [15]

20

3.5

Bluetooth profiles

Prole denitions are issued by the Bluetooth SIG group. Proles introduces standards for Bluetooth services that implementors should follow. In this way fewer
interoperability problems arise when connecting dierent manufacturers products.
A prole can be described as a vertical slice through the protocol stack. It
denes options in each protocol that are mandatory for the prole.
All proles are based on the "Generic Access Prole" (GAC). Examples of proles are: FTP, Object Push, Serial Port, Sync, Headset, Dial up etc. (see gure 4)
shows a part of the prole stack. For a complete and up-to-date list, check [15].

Figure 4: Examples of the prole stack. The outermost prole is always the Generic
Access Prole (GAC).

3.6

Low power operation

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

21

active mode In this state the Bluetooth unit actively participates on the connection. The master and slave communicates on the same connection.
sni mode In this mode a slave device will wake up periodically to sni packets
to itself. If it receives any packets it stays "awake" until no more packets are
received. 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 link
for the period of the hold time. When in hold mode the device stays in the
current piconet. Usually a device goes into hold mode to free capacity to do
other things like: scanning, paging, inquiring or attending in other piconet.
park mode The device enters "Low Power Sleep Mode" most of the time when in
park mode. It only has to wake up once in a while to synchronize with the
master. 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!). This
means that no active communication between master and slave is done. This
mode is very useful if the Slave device needs no communication with server in
some 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, Sni is the least power ecient mode, then Hold, and the
most power ecient mode is Park. This active connection substate can be chosen
through 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 make
connections 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. A
Bluetooth device address (48bits) - hardcoded into the device, a private user
key for authentication (128bits), a private user key for encryption (8-128bits) (if
encryption is enabled), a pseudo-random number that shall be regenerated for each
new transaction (128bits). The keys and random number must be hidden for the
user, so that no overriding or altering is possible.
We will not go into full details with processes of authentication, authorization or
pairing, since it is only the ideas that are relevant to us. For the full procedures refer

22

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

3.7.1

Frequency hopping

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

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 easier
access 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 a

local service it must be authorized to do that. Often the user of the device will be
queried 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 that
the connection between the peers must be encrypted. Encrypting is for example
good when a mobile phone communicates with a headset or when a PC is uplinking through a mobile phone, since it protects against unintended listeners. The
encryption level is dened 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 pairing
succeed. 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
10

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

23

3.7.6

The device database

The Link Manager Protocol maintains this database. A device can be in one of
these three categories (Security level):
1. Trusted devices are devices which are already approved of. These devices need
not 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 authenticate themselves again. But if they try to access a service they must still be
authorized. The link key is stored.
3. Unknown devices. This is the category of devices not yet in the database.
These must authenticate to establish a link. Authorization is also necessary
for access to services to be granted. No security information is stored in the
device database.

3.7.7

Device address ltering

If the Bluetooth address of a peer device is known in advance, Bluetooth address

ltering can be used. This is done on application level.
We discuss the security in our application briey in section 3.7.

24

Platform System Engineering

We now have an idea about how Bluetooth works and what kind of basic requirements our application has. One of our requirements is to have a server part, sending
out the requested data, and another part to ask for the data (the client). We have
to choose a platform, and a Bluetooth stack and development environment (API
Application Programming Interface to the Bluetooth stack) to each of these. In this
section we will discuss the dierent possibilities to each one and we have therefore
separated the chapter into two parts: The Bluetooth server and the Bluetooth client
(see description in section 2.2.3). We will nish the chapter with a discussion of our
choices.
One of our goals with this project was to try dierent kinds of Bluetooth devices
and dierent 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 to
communicate between dierent types of devices.
As described before in section 2.3, we only had access to specic devices. They
cover 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.

4.1

BlueTooth Server

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 FreeBSD
platforms (our own primary operating systems).

4.1.1

Bluetooth stack implementations

Our rst task was to choose a Bluetooth development kit for the server platform.
The Bluetooth stack is available in many dierent implementations, some of them
are open source and free, some are not. The proprietary ones are very extended in
functionality, have excellent documentation and the support is great, but they are
unfortunately 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)
11

we have 2 of these

25

 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 stack/driver used with end-user bluetooth products, can be used, but the price is $1,495
for a license. Both the D-Link and the CSR dongle device and the Windows iPAQ
use this stack.
These APIs of course falls out of our league, because of our limited funds from
the university and we will not even consider using them. We also found some open
source projects which was available, free and promising:
Nokia Ax (http://ax.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-use
distribution. After installing Linux, which created several problems for us, we had
to settle for a stack.

Nokia Ax is a Bluetooth Protocol Stack for Linux developed by Nokia Research Center in Helsinki and released under a open source license (GPL). Ax
currently supports the core Bluetooth protocols like HCI, L2CAP, RFCOMM, SDP
and various Bluetooth proles. In the L2CAP and RFCOMM layer, Ax supports
a Socket interface just like an ordinary BSD-Socket interface when working with
networks. That is a neat feature which makes the development time a lot faster,
if the developer already know how to program standard networking under UNIX
and Linux system. Ax actually goes a step further and handles Bluetooth as a
network device on the Operating System. This simplies the API a lot, but it also
makes it far from a reference implementation like e.g. Bluez (see in later section).
Also the naming convention and function names used in Ax API do not comply
to the Bluetooth specications[17] they are oversimplied.
The Ax package provides control tools for the HCI, development libraries, and
server daemons for SDP etc. Ax also have very excellent documentation for their
API, with a lot of concrete examples and text explaining it.
Ax supports a lot of features:

26

 Ax is modular implemented
SMP safe (Symmetric Multi-Processing)
Multiple Bluetooth devices support.
Unied interface for all transport drivers. It makes it hardware independent.
which again makes it easy to use USB dongles or PCMCIA cards.
Runs on dierent 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 rst and gave a great set
of interfaces to the stack, which was proprietary. The BlueDrekar package includes
HCI, RFCOMM, L2CAP and SDP layers. BlueDrekar is actually an old reference
implementation of the BlueTooth standard. The stack and modules are available
all the way back to the 2.2.11 and 2.2.12-20 Linux kernels. Although it had some
okay documentation, good makeles and sample programs, the project was stopped
in April 2002.

BlueZ is the ocial 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 ocial stack in the
Linux 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 support
for 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 test
the Bluetooth equipment, which makes it easier for a new developer to make out new
code from the small code fragments of the samples. BlueZ, like Ax, comes with a
nice abstract implementation of the dierent 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 in
any satisfactory (only a small useless FAQ is available) way we realized that they
have a very active mailing list which almost answers any questions one may have
about 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
Unied 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

27

Axis OpenBT is a small open source bluetooth stack for Linux (and some other
operating systems) that supports the common functions of the dierent layers: SDP/L2CAP/RFCOMM. Although it supports SDP, it has no SDP parser functions or
libraries at all. Neither does it support dynamic registers in the SDP daemon. This
project has many aws: almost no documentation at all, and what exits seems to be
is very outdated and deprecated. Its a project that already have been discontinued
because of the ocial announcement of BlueZ implementation into the Linux kernel. A lot of the open source developers now work with the BlueZ implementation
instead. 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 possibilities as the Linux version. Although no documentation can be found at all, only
fragments of code bits from the dierent 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 appendix
A.1 for installation procedure. If hardware is not in the supported list (which isnt
that long), it will not work correctly. According to what we have read you have to
uninstall any software which come along with with the Bluetooth device, because it
will 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 approved
devices is not for sale in Denmark. It is a TDK dongle. Price in UK including
shipping 8-900,- DKr, but as far we have been able to read on newsgroups and
other forums, there seems to be dierent revisions of it, where only some of them
work.
The documentation is very good and good examples are provided.

4.2

BlueTooth Client

The choice of the client stack was quite limited because of our small selection of
devices. As described in chapter two, our handheld clients devices to be researched
consisted of these:
Sony Ericsson T610 (cell phone)
Nokia 3650 (cell phone)
Compaq iPAQ 3870 (PDA)

28

 Compaq iPAQ h1940 (PDA)

In the following sections we start out with some general APIs that to some
extend can be used on the dierent platforms. We have split up some of the next
sections into the dierent devices rather than specic stacks like with the server.
This is because handheld devices mainly have very embedded hardware which again
means a very specic API.

4.2.1

Symbian OS

Symbian Operating System[27] provides a nice C++ API to Symbian phones and
PDAs. It has a lot of examples. It has proven to be stable and is very active (new
updates in their API all the time). The Symbian OS package also ships with an
emulator, which emulates the small embedded devices like phones and PDAs. It
ships with dierent 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 doesnt support
Bluetooth. So a developer can only use the emulator to GUI programming, audio
and 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 aws, poor
part 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 exibility especially in our client, such that every visitor in the museum
only 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 dierence
doing it on PDAs or on cell phones. Cell phones and their limited capabilities
does not support the full-scale Java API and we would therefore be forced to use
Java J2ME (Java Micro Edition), which is a special Java environment developed for
limited devices. In order to do so, the cell phone has to support MIDlet 2.0 (due to
the lack of socket support in MIDlet 1.0)[51]12 and the JSR-82 standard[49] must be
implemented. The JSR-82 standard describes the Java API for Bluetooth towards
the 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 standard
Java API. But in order to support Bluetooth, the application has to use a library
that implements the JSR-82 standard and supports the given stack. For the JSR82 standard on standard Java there exists dierent implementations for dierent
12

A MIDlet is a J2ME application that can be run on practically any mobile communications device
that implements a Java virtual machine

29

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

avetana Bluetooth software is based on the most widely spread bluetooth

protocol stacks and does not use special Bluetooth hardware or software. It allows
programmers to easily use and oer bluetooth services. Avetana Bluetooth is a Java
JNI13 implementation of JSR-82 for J2SE and dierent stack implementations.
The implementation is actually quite platform independent and supports dierent stacks on various platforms:
Widcomm (Windows)
Apple System stack (Apple of course!)
BlueZ (Linux)
The Avetana software is not that expensive (25 Euros) and the implementation of the Bluez API is even free and opensource and can be downloaded from
http://sourceforge.net/projects/avetanabt/. All information about the software can
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) and
Linux. Although it seemed very nice and probably had some good APIs and documentation we couldnt get munch information out of them and their products
seemed 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 Mophun
operating 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 nd an API for C++ and since
Sony Ericsson have no intention on releasing Bluetooth support for the programmer
for 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 support
for JSR-82 neither, we can not use the Java API. We had to look for another API.
13

Java Native Implementation is a interface for writing Java native methods and embeddeding the
JVM into native applications like stack implementations as BlueZ, Widcomm etc.

30

At forum.nokia.com [19] we found an C++ API and some example applications for
Symbian 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 distribution
Familiar Linux made especially for the iPAQ. We found drivers on the Internet and
got 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 quite
unhappy about this since the potential of this device was quite promising.

4.2.6 HP iPAQ h1940 running MS Windows Pocket PC 2003 Professional

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

4.3
4.3.1

Choosing platform
Bluetooth Server

Since the Windows XP stack is implemented in a way such that it will work only
with a few specic hardware devices (which are not the common ones), we dont
want to use the Windows software. Besides we do not have one of the hardware
compliant devices.
We chose to use a stack on the Linux platform because of the availability and
costs. We also already had a Linux box up and running and had a lot experience
with it. One of us also have great experience with the FreeBSD platform, but we
did not chose to use it mainly because of its recently support for Bluetooth and the
lack of examples, documentation or mailing lists.
Actually, as we see it, there is only two competitors of stacks on the Linux
platform for our bluetooth server: Ax and BlueZ. We have chosen to implement
our server with a BlueZ stack due to the fact that it is the ocial Linux bluetooth
stack. 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 devices
and provides all the standard Bluetooth core layers and protocols in a very exible
manner (you can code like it was standard network sockets). This will make it somewhat easier to implement our server, because we already have good knowledge about
standard network programming like Berkeley-Sockets. Also the active BlueZ mailing

31

lists with quick answers and many qualied and skillful developers compensated for
the lack of API documentation.
Although Ax did have some excellent documentation and also covered a lot of
the core layers it seemed like it didnt follow the standards of naming conventions,
which bothered us a lot. This was because we only had knowledge from the Bluetooth specications[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 Ax stack since we had mainly
good experiences with Bluez. The install and usage instructions to BlueZ can be
found in section A.4.

4.3.2

Client

We have chosen to implement our handheld client on the Nokia 3650 Series 60 cell
phone using the Symbian operating system. Of course our implementation using the
Symbian API isnt 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 and
JSR-82 compatible, we where bound to use the 3650 and the Symbian operating
system. Though if we had or could get a cell phone supporting MIDlet 2.0 and
JSR-82, we would denitely think that it was worth spending some time trying it
out.
When we started to look at Symbian the documentation and HowTos were overwhelming. The huge information and documentation did, that the installation procedures, tips and tricks were unfortunately scattered around in dierent guides,
which made the installation pretty time-consuming. We have collected this information in an ultra short HowTo.
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 rst "Hello World" program.

32

System Design

In section 2 we explained the scenario and what capabilities the application should
contain. On basis of the scenario we will, in this section, discuss the Bluetooth
related design issues based upon the theory presented in chapter 3 and with the
chosen platforms in mind. Though we might not mention it so much, one of the
major concerns in the back of our minds is that it should as be fast and as easy to
use as possible for the visitor.
Though the Bluetooth protocol implements master/slave switches, it still
makes sense to dene who is the server and who is the client. The obvious
thing to do is to let the Museum have the server role. The major reasons
for this is, that it makes good sense to let the Museum advertise a museum service. 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. This
might not be the in which we have addressed them when designing/implementing
the 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 rst
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 network
topology? Considerations about where to put Bluetooth access points, and other
network design issues are covered in 5.3.
To establish the connection we will follow the procedure described in 3.3.7. Some
security concerns must also be made when establishing a connection, these are
covered in 5.5. We will make some considerations about SDP in 5.4 and next we
needed to decide what protocol we want to use for transferring data (see section
5.6).
We are now capable of establishing a connection, but how should we use it to
transfer data? This will be discussed in section 5.6.1

5.1

Connections

We would like to establish connections as proposed in the Bluetooth specication.

The server advertises a service where connection information can be found. The
client gets this information and after that it logs on. See also 5.6

33

Should the connection remain on? We will here give a short discussion on
connection 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 the
Bluetooth server. "Connect on demand" is very appealing because fewer Bluetooth
server dongles are needed than if always on strategy is chosen. The downside of
this 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 be
established. 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 device
could be set in "park mode" when not busy for a while, to save energy and free
bandwidth on the server.
With this approach we get a client, which tries to connect to a another Bluetooth
server as soon as it looses its initial connection. In that way the reconnection can be
done 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 to
have patience until resources are released and a connection can be established. The
client 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 visitors device
cant see where it is. The Bluetooth Radio is not suited for distance measurements,
actually it is pointed out in the specication, that attempt to do so should not be
made (See [11]), so it can not even see what devices it is close to. It can only know
whether a device is within range or not.
This means that the we need to nd another way for choosing the wanted exhibit
item:
1. Triangulation to position the client.
2. An external tracking solution (not Bluetooth) could be developed - a chip
carried or camera surveillance.
3. Handle it in Bluetooth on the cost of more user interaction.

34

Our Solution: The idea of triangulation is an attractive way to solve this problem, but the precision we seek can not be provided by Bluetooth (maybe down to a
few centimeters for items on the same shelf). Singe a range can not be calculated on
basis of the signal in Bluetooth, this solution is not very well suited for Bluetooth.
It would require a very well placed network grid of Bluetooth devices, and still only
give a rough triangulation. - In addition the need of a piconet with Bluetooth client
as master would be required to do this. This will not be possible unless scatternet is
supported on the client, because the client also needs to be a slave in the connection
to the Bluetooth server device, which will be master in its piconet.
Though solution two probably would be the best solution, it was not the intention
to use such extra facilities. Solution two would still not give the desired precision.
Instead we will let the user pick the item he or she wants to see through the client.
This could be done from a list of items. Potentially the list could get long, so a tree
kind of presentation could be useful, if many items can be chosen.

5.3
5.3.1

Network Topology
Server/Exhibition Item setup

The creation of such a list depends on the network topology. Since the range of
Bluetooth is limited, every exhibition item must be in range of a Bluetooth server.
The two most obvious ways to achieve this are:
1. One device is bound to one exhibition item.
2. A group of exhibition items are bound to one device.
To decide which solution to take, another problem is to be taken into account.
The problem of ltering devices. When a Bluetooth device discovery is made. Many
non museum devices would be found (probably the other visitors devices). These
should be sorted out.
If the 1st solution is chosen, the user must choose a device from a list of all nearby
devices. The name of the device could correspond to the exhibition item. When the
device is chosen the item is implicitly chosen. In more detail the procedure would
be:
1. Find all devices
2. Filter museum service
3. Show list to the user
4. User chooses a device from the list
5. Query SDP museum connection info
6. Connect

35

When a new item is to be selected a new connection must be established.

If the 2nd solution is chosen, the connection is established without user interaction. But the user still has to make a selection, i.e. he has to select the exhibition
item from a list retrieved from Bluetooth server. In more detail the procedure would
be:
1. Find a device
2. Filter for museum service (if no museum service present goto 1)
3. Query SDP museum connection info
4. Connect
5. Retrieve list of items from the selected device
6. Show list (tree structured if needed) to the user
7. User choice
8. Connect
A new connection must be established when the user moves outside the range of
the device bundle. In this case the Bluetooth server must contain information on
every item in its range - and only these.
Our solution. The second solution is absolutely preferable because fewer reconnections must be made. Reconnection only has to be done when leaving the range
of the current Bluetooth server. In the 1st solution a reconnection must be made
every time a new item is chosen. These reconnections are time consuming (a few
seconds) and annoying to the user.
Another good reason for this choice is the ease of maintenance. When new
exhibitions arrive to the museum it is not necessary to add more devices in the
room or recongure Bluetooth server device names, the new entry just has to be
associated with the Bluetooth server in the central database server (see gure 1).
Also the number of devices in a bundle are easier tted to the needs of connections,
since fewer device than exhibition items might be enough. See 5.3.4.
It would be sensible to let the dierent Bluetooth servers range overlap, just
to make sure all items are covered. This will also give fewer reconnections when a
client moves around in the outer rim between to Bluetooth servers.
In this way, a client will always be covered by a Bluetooth server, which contain
information about the item next to the client. When the client is on the move, it
will automatically connect to an appropriate Bluetooth server.

36

5.3.2

Choice of Power Class

We have considered the use of Bluetooth devices from Power Class 3 (range 100m)
on the servers, but the common Bluetooth handheld device has a range of 10 meters
(see 3.3.1), so in order to communicate with the server it needs to get into range
anyway. This means that there must be a device within 10 meters (maybe less than
10 meters in practice) of each exhibition item.
If 100m becomes a standard in the future, and 100m devices are chosen instead,
the system would be scaleable. Though the number of items in range would increase
dramatically if 100m range.

5.3.3

Piconet - Scatternet

It could be possible to let the client be connect to the Bluetooth server and then
forward information to other clients. In this way a scatternet would emerge. We
have chosen not to let the museum application support scatternet, since very few
devices supports scatternet. Moreover it would complicate the implementation a
lot, and it also might give some problems with the security between clients. This is
because clients would be able to use other clients to connect to the server.

5.3.4

Bluetooth server device bundling

A bundle of devices could be used if one device on the server is not enough to
support the network load from the connecting clients. Since we use piconet there
can be a maximum of 7 actively connected clients per Bluetooth server device. It
would be possible that more than 7 devices would connect in an area of up 100m2.
Some kind of load balancing on such a bundle would be preferable, but we will
not go deeper into this problem.

5.4

SDP

SDP is one of the main features in Bluetooth that makes it special compared to other
network specications. And we found it very interesting to implement. Besides this,
SDP has some nice features.
Knowing that a Bluetooth server advertises a Museum service through SDP, we
can test whether a device has the Museum Service or not, and that without making
a data connection to it. Keep in mind that an actual data connection can not be
established over an SDP connection, thereby security is maintained for other client
devices.
It gives a nice and dynamic way to communicate connection setup parameters.

37

5.4.1

The museum service record

Since there is no prole (see 3.5) dened for a museum application (surprise!), we
have dened our own service.
Besides the mandatory attributes ServiceRecordHandle and ServiceClassIDList,
connection information must also be present. This is done in the attribute ProtocolDescriptorList. Besides this we will use the ServiceName, ServiceDescription and
ProviderName though they have no function besides informational.

5.4.2

Handling of several clients

Problem: Server handling of connections and updating the advertised PSM.

Due to the network topology of Bluetooth, we have a problem when we have
advertised a service through our SDP daemon. This is because only one device can
be connected to a PSM at the same time. So when we have a scenario with two
visitors trying to connect to the advertised service, they will hit the same PSM.
This is a problem because only one client is allowed to read and write to the PSM
port. The other client will therefore fail.
We have considered four ways to solve this problem:
1. We could solve this easily by just adding a bunch of service records with
dierent PSMs. This is not very nice because the client does not know which
services that are already taken, and thereby have to iterate through all the
service records to get one that is available. This is very time consuming for
the client, and therefore a real hazard to the visitors!
2. We could implement some kind of control in our server application, so that we
could update the PSM in the advertised service record. This however means
that we somehow have to synchronize (via. a kind of monitor or semaphore)
the method to make the update. This is because we have a critical region when
two clients can read and write to the same resource, also called readers/writers
problem. We also have to implement a method in the client for getting a new
service record if the rst one fails. The rst one can fail if a PSM is to be
updated (a client already have connected) but the old PSM still is advertised.
3. We could "hack" the SPD daemon to call back to our application. This means
that the SDPd could answer back to the application and give us how many
clients that have seen our advertisement, how many that are connected and so
on. This could be very elegant, to have a message passing system, but would
also require a lot of work and would be very time consuming. Besides it is not
that nice to hack the BlueZ protocol to suit our needs.
4. We could make a SDP service record containing a lot of dierent PSMs. The
client then have to take the connection into consideration. So, every time the

38

client receives a disconnect, because the PSM is occupied, it should continue

to the next one. This could also be implemented in a smart way, such that the
application would use and update the ServiceAvailability attribute in the
SDP service record (see section 3.3.7) and thereby indicate how much "free
space" there is. The client could then just to read the ServiceAvailability
attribute and see if it could connect or not.
Taken all into account our nal solution for solving our multiple clients will
be based on updating a advertised PSM. We thereby have to build in some kind
of control in our application. We have chosen solution two because of relative
simpleness and because the other solutions just where to time consuming or too
slow for the client.
Of course the client could be unlucky and hit our advertised SDP record (which
another client already have), just when we are updating it. Thereby the PSM will
be busy. A quick x for this will involve the client to reconnect and try again. In
the case where all our PSMs are occupied and no more bluetooth server devices
could be assigned (a busy day at the museum), we could remove our service record
and stop our advertisement. We would then start it again, when a client stops
using our application. Another way of implementing this could be though the
ServiceAvailability attribute, as discussed earlier.

5.5

Security level

When a person goes to a museum, he gets in for free or he pays a fee to get in. In
paying this fee he is allowed access to the museums exhibits and knowledge. The
normal purpose of museums is to broaden their knowledge, so in that way, you can
say that need of security is small, since there is no secret information. In case any
private or condential material is present on a server, a client should not be allowed
to access it through a Bluetooth connection.
If the source code implementation is kept as closed source, it is hard to know
how the communication protocol above the Bluetooth layer is interpreted (our mini
protocol see 5.6.1). So misuse of the communication channel is dicult.
The Bluetooth protocol always uses Frequency hopping, which make sning
very hard.
According to the theory (3.7) the following security level possibilities are provided in Bluetooth:
Pin code security (authentication)
Authorization
Encryption

39

 Bluetooth address ltering

14

At sign in time (registration) the Bluetooth address of the visitors device could
be acquired and stored in a database. When a visitor device tries to log on to
a Bluetooth server it could be ltered trough this database. Encryption of the
connection could also be used.
If authentication was to be used, it would be necessary to use this transparent
to the user, for the sake of user ease. The visitor should not be bothered with
entering pin codes at each log on. This can be solved by giving the visitor device
the pin code at log in. The pin code could be generated in several ways. For
example one pin code could be chosen for all devices - New pin codes could be
determined every day - Or a dierent pin code could be generated for each device all depending on the chosen security level.
Since our major concerns are not about the security, we will make the implementation as simple as possible. Though it in some cases would be preferred by the
museum to implement a higher security level, we have shown that the possibilities
are certainly there. E.g. if the museum wants to have dierent services available for
the user, e.g. text, pictures, audio streaming or video streaming, they might want
to charge dierent prices. In that case dierent services could be given dierent
PIN-codes to solve the problem.
In BlueZ dierent security settings can be chosen. One of them is to always
accept incoming connections. It has also got a PIN-helper script, which is meant to
modied to suit available needs. We will congure it to a minimum of security, so
no PIN-code has to be entered.
We will not use pairing, since the server accepts all incoming connection requests
anyway. And the chance that a client re-attaches to the same Bluetooth server device
is not very big, so it makes little sense to use this feature.

5.6

The actual connection

As seen in the theory, chapter three, Bluetooth supplies dierent protocols. Before
we can make an actual data connection, we have to decide on a protocol from the
Bluetooth stack to do it through. Dierent protocols must be taken into account
dependening of the type of data.

5.6.1

Simple text

Simple text transfer is the basic way to communicate over a connection, and is
thus our starting point. RFCOMM and L2CAP can be used to handle simple
14

Not supported by the Bluetooth stack itself, but it could be implemented

40

transfers like strings. They are both very usable for this. The major API dierence
between the two protocols is that RFCOMM delivers data as a stream, and L2CAP
is packages oriented. In practice it does not make a big dierence.
Simple commands can be issued from the client to the server through
L2CAP/RFCOMM without problems. And text can be returned to the client,
also through L2CAP/RFCOMM.
We will implement both L2CAP and RFCOMM, but L2CAP will be the preferred choice since it has a smaller overhead. RFCOMM has the advantage that it
works in a way similar to a serial port. This means that data sent over RFCOMM
can be read from HyperTerminal (in Windows), MiniCom (Linux) or other simple
serial port applications. This makes debugging easier, since we can test with a
known working client or server from the beginning.
When choosing L2CAP as protocol a packet size must be agreed. We have chosen
to hardcode the size to 672(bytes), which is common practice. The size inuences
the throughput of the connection. If the data packages sent are big, the packet size
should be bigger. If smaller packages are sent, the packet size should of cause be
bigger. 15

5.6.2

Data as les

OBEX is designed for pushing les in a FTP like manner. This could be very usable
if pictures, audio les (non streaming) are to be sent. But the overhead for these
packages is very big.
Of cause it is also possible to send a picture as bytes through L2CAP. This would
however require a small protocol to determine when all data have been transfered.
If text also could be send over the same connection, a small protocol would denitly
be suitable, see 5.6.5.

5.6.3

Audio

An appealing concept is the Head Set prole. The head set prole bases its connection on a SCO link (see section 3.3.9). This could be used in two ways in our
application:
1. A Bluetooth headset could be connected directly to the Bluetooth server .
This could work, but the visitor would have no user interface to the server,
and the visitor would probably not want to remove the partnership (pairing)
between his phone and his head set16 . (Also see 7.3)
2. Some kind of control of the head set link through the client could be imagined. We have made some tests with our hardware, and it showed that the
15

To mention another usage for SDP, the value could be advertised in the SDP service to make packet
size changes more dynamic.
16
This is required to link the head set to another Bluetooth device

41

Nokia 3650 can not be connected to a headset (Jabra BT-250) meanwhile it

is connected to another device via an ACL connection, i.e. a serial port or
the museum service to another device. So this seems impossible with our
hardware.
This means that if we want to send audio through Bluetooth it would probably
be the best solution to send the entire le or to stream it through a L2CAP link
and then use a good old fashion head set with a wire.

5.6.4

Video

Streaming of video has recently become standardized with the new Bluetooth prole
(GAVDP). We have not really researched this area yet, so we do not exactly know
whether it has any specic hardware or software requirements or not. But we know
that some of the newest generation mobile phones have video conferencing, and
thereby the ability of streaming video should be possible. With an API to a codec
and a player it might be possible to stream video. So our limitation lays in the
client.

5.6.5

Miniprotocol over L2CAP

As indicated above a protocol could be developed, so dierent data types could be

sent over a single L2CAP connection. It could contain information about the type
of data, the length, whether it is a stream or not and so on. We will not discuss the
protocol in detail, since we did not have the time to implement it.
For starters we will only implement a dierent answer for the server depending
on the input, to show the concept.
When a connection is established the scenario would be something like: A visitor
is pressing a specic key on his or hers cell phone, it will send out a request
containing what the visitor wants to get information about (the given art artifact
and the type of information). The server processes the input and returns the data
requested. Thus the visitor is able to see or hear the text, picture, audio or whatever
requested.

5.6.6

Establishing the connection

When our L2CAP connection is established between the client and the server, we
can transfer data. Actually there is not much to say about this, since it follows the
theory very close. So it has already been covered in 3.3.7 and partly in 5.3.

5.6.7

Data transfer

Earlier we choose to have one process on the server per client. This means that we
do not have to take any special precautions on the server regarding sending and

42

receiving to and from the wrong client.

We have chosen to receive and send data through one connection, that is half
duplex. Whenever the connection is idle the device should listen, and thereby wait
for a incoming message. When a message is to be sent, it will go into send mode,
send it and return to receiving mode.
Typically the user will eventually press a button, and generate a send message
on the client. The client will then stop listening, send the message, and go back to
listen mode. The server receives this, and returns the result by going to send mode.
Another possibility is to make two separate connections - one for receiving and
one for sending. A major disadvantage of this solution was that multiprocessing
had to be developed on the client. Though it supports threads, it is still very
cumbersome, because synchronization has to done, and since we had no knowledge
of the Symbian OS in advance. The gain is also very limited, since the bandwidth
is the same, i.e. from the applications view it to full duplex lines, but in reality the
it is still half duplex in the RF layer.

43

Program Description

In this section, we will try to outline our design and implementation of both the
client and the server. Since we have only implemented the Bluetooth server and the
Bluetooth client, we will only describe the implementation of these.
In the previous chapter, we have summoned up our needs and our choices concerning design of the communication procedures, data transfer and the network
topology. With this in mind we have implemented our application.
As earlier stated we will focus on Bluetooth functionality, but we will not go into
subjects like audio and video transfer and power saving in the program description,
since we have not implemented them yet. We would have liked to work with the
power saving capabilities of Bluetooth on the client, e.g. "park mode" (see 3.6 and
5.1). Unfortunately there is no documentation on how to implement "park mode"
- only needed on the client, but we found indications that it could be done when
browsing through the header les of Symbian API.
When describing our problem solution from the last chapter, we will make use
of UML17 . In this way we should be able to get a better understanding, and thereby
also get a clearer and a better implementation. We will describe both the client and
server solution using a state diagram, that will show the dierent states and give a
nice overview of our application. A class diagram will support our implementation
description, showing the interconnection and structure of our classes.
All our source code for both the client and the server is well commented, and
any given developer should be able, with the help from this chapter (6), to get an
insight of our implemented methods through this. We have used the javadoc style
for describing it.
Again all our code can be found on the included CD-ROM under the source
directory.

6.1

The BlueTooth server

In this section we will briey try to walk through the dierent development cycles,
that we went through when we developed our server part of our application. We
will take a look at the design and the thoughts that lies behind our program and
go further into implementation details and describe our implemented classes.

6.1.1

Bluetooth applications development on BlueZ

When developing in BlueZ, we make use of the standard GCC compiler under Linux.
Of cause the compilation of the server need to have our chosen stack, the BlueZ
stack, installed. An installation guide is provided in appendix A.4. This makes our
17

Unified Model Language standard (See [7])

44

compilation possible because we now can dynamically link against the BlueZ library
(libbluetooth.o).

6.1.2

Server Design

When our understanding of BlueZ was in place we started to make the design of
the server. Through our last chapter (System Design) we considered some of the
problems involved in developing a client and a server. For the server part we had
to advertise a SDP record and make some kind of server service for the client. We
came up with these basic capabilities of the server application:
Advertise the service through the SDP daemon
Listen for incoming connections on the advertised PSM
Receive commands from the Client (picked data for the given art artifact)
Send back data to the client
reconnect methods if errors or other failures occur.
So with this in mind we draw a UML state diagram, to reach an even better
understanding of what we had to develop (see g 5).
This gives a quite good overview of the application and almost delivers the classes
and methods to us.

6.1.3

Implementation description

In this section we will outline a description of our implemented classes and all of
their functions and methods.
We used the BlueZ headers for communicating with the stack, which is: bluetooth/bluetooth.h, bluetooth/sdp.h, bluetooth/sdp_lib.h, bluetooth/l2cap.h, bluetooth/hci.h, bluetooth/hci_lib.h.
Because of the lousy documentation (see section 4.1.2) we simply started out
by reading the supplied applications in the BlueZ package: l2ping.c, l2test.c,
hcitool.c sdptool.c etc. and thereby achieve a good understanding of BlueZ and
how it is interconnected.
We will now shortly introduce the dierent classes, mostly dependent on who
initiates and who is calling who, and of cause the main class will be the rst!.

The main class is almost described by the UML state drawing (see g. 5).
It starts out by setting some initial values for our protocol, PSM and Bluetooth
addresses. These values are then advertised through the SDP daemon (see next
section). After the advertising is started, our server starts to listen for clients
connecting (see the prot class). If a client then connects, the server spawns of a
new process by calling fork, thus allowing other clients to connect and disconnect

45

Scratch

Init

Start SDP deamon

Service added

Start BermoTe

Add Service to SDP

Open socket and listen

Waiting for
connection
Close connection and listen

Service record update

parent
Connected
Fork process
Connection accepted

Connection failed

Send succesful

child

Processing request

Waiting for
client request

Sending
send requested data
to client

client request received

Connection failed /
Read error

Connection failed /
Write error

Disconnect

Kill child

Figure 5: Statemachine for the server

as well. If a client is connected, it can send a command to the server and get back
an answer (see later section). If they somehow disconnect, only the child process
will exit. We have implemented this though a sigaction, which is used to control
processes. Our main can be explained by the following class diagram, that shows
how main initiates the dierent classes (see g. 6).
main

Communicator

device

SdpService

prot

utils

Figure 6: Class diagram of the server

The Communicator class is a general communication object. It is used to

make an easy way of constructing new protocol types. This is actually the only
object which is initiated in our main class. It stands for all the bluetooth communication. Instead of calling the L2CAP and RFCOMM directly from their own classes

46

in our main class, we wrap them into our communication object. In this way we can
use the same methods for connecting, listening and adding SDP services etc. The
only thing we have to do, is to initiate a protocol on the communication object that
we want to work with. This is especially very handy when testing. We just had to
alter some of the parameters. We will only shortly introduce the methods in our
Communicator class because it is mainly a wrapper class which will be explained
deeper in the forthcoming sections.
We have these wrapper methods:
addService() initiates a new sdpservice object, which again advertises the given
service.
listen initiates a Prot object and returns the given socket.
connect initiates a new Prot object and starts using the protocols through that.
This is only used for test purpose.
This of cause could have been done even better and in a more Object Oriented
way. Instead of doing it like we do: initiating the give proc class in our Communicator class, we should have used a more polymorphic design pattern. We could do
this by making our Communicator class a kind of base class and let the L2CAP and
RFCOMM classes inherit from it. Thus making our inheriting methods overload
the base class methods (which should be declared virtual). In that way we could
have dierent implementations in our inheriting classes (L2CAP and RFCOMM,
what we now call prot). This will do that all our dierent objects in our member
function react in the same way.
We would in this way, also be able to easily implement an intelligent constructor
for the Communicator class. This could for example initialize the advertisement
and setup default values. And the destructor could likewise destruct our L2CAP
or RFCOMM object when we are nished using it (because it inherits from it). It
would also be able to clean up unused memory and close the active sockets, stop
the advertisement and delete the SDP service record.
A somewhat smart design that we surely would have implemented if we had the
time. But we focused on what was relevant, and because this was a pilot project,
so we thought it was a ok design.

The Prot class contains our dierent protocol implementations.

we implemented it in a pretty naive way. Of course we could have implemented

such that we only had one method for both L2CAP and RFCOMM instead
of two, because they are very similar. The only thing roughly dierent about
the two is the socket initialization. The RFCOMM is initializing the socket
by: socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM) and L2CAP by
socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP). The parameters are
just indicating the address family, the socket type and the protocol. But it was

47

nice to have this split into dierent methods during our test, because we could set
up dierent parameters on the sockets. We also tried to setup some encryption and
master/slave switches for the sake of research in the HCI layer.
listenRFCOMM() and listenL2CAP() is one of our main methods. These sets up
the sockets, congures them and using them to accept incoming connections from
clients. They do this by using the default socket setup: socket(), bind(), listen()
and accept(). When we have called the listen() method, we use fork() to spawn
o a new thread (see also g. 5). In this way we can service two or more clients
at the same time. Also it allows us to let the client disconnect, without closing our
main (parent) process, which handles the new connections.
To explain it in details: we make our server block on the accept(), waiting for
a connection. Once the connection comes in, the server fork()s, the child process
handles the connection and our parent process is able to service new incoming
requests for any new clients.
We could also have used the select() function instead. This would imply that
only one process (instead of a process for each request) multi-plexes all the requests
and servicing each request as much as it can. This of cause would have been more
"light" for the server, because it will only require one process. But we have chosen
to implement it using fork() because we nd it more convenient and transparent.
For example with the fork() solution, the child does not have to worry about
new connection or the existence of other sockets, it only have to handle the actual
connection it is given.
listenOBEX() is not really implemented. This is because BlueZ currently dont
support this protocol. In order to implement this method we need to install
OpenOBEX (http://openobex.sourceforge.net/). We havent done this because we
didnt really need this functionality.
The class also implements a method for connecting towards the server (like the
cell phone) with dierent protocols. We have used these connection methods for pure
testing, because our real client (the cell phone) already do this. We implemented
connectRFCOMM() and connectL2CAP() for that purpose. In this way we could
simulate more multiple substantiating clients connecting and disconnecting.

sdpservice class is containing methods for adding, deleting and updating a

SDP record. One of our most important methods is add_museum_service() which
is used for adding and advertising services. Until now we have only implemented two
services: a museum service and a museum audio service. The latter one is actually
just for testing purposes. In this way we could test if we could have dierent services
the client could connect to. add_museum_service() makes a connection towards the
sdpd and starts adding attributes to our SDP service record as explained in section
5.4.1. We build up the list by lling in our ProtocolDescriptorList with our protocol
(L2CAP) and the PSM, which is set to 5. Besides that, we setup the ServiceName,

48

ServiceDescription and ProviderName. This only contains optional information

about our service, like the name ("MUSEUM SERVICE"), the description of the
service ("Electronic Museum guide service") and the provider name, which we have
set to "BeremoTe". When this is done, we register the service and closes the
connection. Our Museum service is now advertised.
When we have our advertised record, we can unregister it again by calling
unregister_museum_service()that implements our method for deleting a specic
service, with a given record id.
The updatePSM method updates the given advertised record and also updates
the given socket. This means that when a client have connected our server, it uses
this updatePSM to synchronize the advertised PSM and the socket. In this way we
should be able to have multiple clients connecting on dierent PSMs. We use the
device class (see later in this section) to get all our active connection and thereby
can see how many clients that are connected.

The sdpclient class is actually just used as a test class for testing against our
advertising service and sdpd. It calls the method museum_sdp_search for searching
for our museum sdp record. It will then try to get some of the records and print
them out.

The utils class. When we have advertised and listened on our given port, we
want be able to receive the data when a client connects to it and starts to send
requests. It receives in one byte chunks, because we only have to read the rst byte
of what we receive from the client (see 6.2.6). recvData()handles this. It reads
from the given socket and does so until our stream returns -1, which is the end of
the stream. We also checks to see whether our stream returns 0x4 (hex), which is
the End Of Transmission (EOT). We get in these states if a given client uses its
disconnect functionality.
If a correct request is sent from the client (in our case, a lename), then
readMuseumFile()is called, which again reads the given le and sends it back to
the client via. the sendData() function (is actually just a write on the socket). The
readMuseumFile()should of cause be replaced by a more dynamically solution like
a database or so, which we already have mentioned before. But in our case it is a
perfect solution for a proof of concept.
We also implemented a method sendData() which just takes dierent parameters. It for test purpose only (echo server) and just sends out user input on the
commandline to a given socket.

The Desvice class is a small utility class developed for scanning, acquirering
info on Bluetooth devices and so on. We used the hci.h and hci_lib.h functions
which BlueZ provided. It gives us the possibility to get the device name, address,

49

active connections etc (all in the HCI layer).

we use the getActiveConnections() for getting all our active client connections
on our server and to see their master/slave state. getLocalDevice is used for getting
our local Bluetooth devices. In this way we can see how many local dongles that
is plugged into our server and also assign a specic device to our service. We used
this in our test phase. deviceInquire() is used only for test purpose.

6.1.4

Problems arose during implementation

During implementation of our design, we ran into two problems.

The updatePSM function should have been used to update the PSM in the advertised record and on the given socket. In this way, our server should update the
PSM when ever a new connection was made. However, during our research we
found, that the update isnt really necessary. This is due to the fact, that the listen() and accept() part of BlueZ is implemented just exactly as an ordinary socket,
and therefore we can restrict our self to use the fork(). The PSM actually works
like a normal TCP/IP port that can serve two or more clients. See also details in
section about the prot class.
Later we found, that the update function to the SDP service (called
sdp_update_service() was not implemented correctly in BlueZ. We would have
used this to update our PSM, but the mechanism simply didnt work. 18 As our
need for updating the PSM were not present anymore, we didnt want to dig any
deeper into this problem.

6.1.5

Server user guide

A Makele le in our project is supplied to compile the necessary targets.

all compiles the entire project.
server compiles only the server side.
client compiles only our bluez test client.
test compiles all our test classes.
clean removes the binaries and linkable objects.
Now it is easy to compile the server program. This is done just by typing make
server. This target will build all the source code, and the compiled executable code
will be placed in the current directory. Now we can start up the BeremoTe museum
server by typing:
1. modprobe hci-usb (load the specic drivers for USB BT units, being root)
18

We announced this on the BlueZ mailing list and got an answer back, that most of the developers
never have used this function. They told us to remove the whole old sdp record and insert a new one.

50

2. sdpd (starts up the listening SDP daemon)

3. ./beremote

6.2

The Bluetooth client

In this section we will take a look at the environment in which we developed the
client application, and give an overall explanation of the client implementation.
At rst we will introduce a few Symbian OS idioms, which could be handy for
the reader, who has not yet been acquainted with it, to understand the code. Before
we go through the structure of the application and the program ow, we will make
some comments on the programming environment. In the last part of the client
implementation part we will discuss some problems which we encountered during
implementation.
At last a quick user guide for the client software is included.

6.2.1

Symbian Programming

Though Symbian applications are coded in C++ it is dierent from what we would
call "normal C++ code". We will here give an ultra short introduction to Symbian
programming. We will mention some of the ideas/conventions, which are good to
know, before trying to read our code. For a more elaborate explanation refer to [2]
and [3] in the litterature list. These references have been invaluable to us, when
coding - especially the reference manual.

Naming conventions We will here mention some of the essential naming convention in Symbian coding:
Classes starting with an capital [C] is a heap-allocated class, that are derived from
a base class CBase.
Classes starting with an capital [R] is a resource class, that contain handles to a
real resource which is maintained elsewhere
Classes starting with an capital [T] is a value class, that do not own any external
object. Also used for structure types though capital S is sometimes used.
Classes starting with an capital [M] is an interface class, that dene abstract
protocol denitions that are implemented by derived classes.
Integer names are written in capital letters starting with a [K].
Functions ending with an capital [L] can leave
19

19

leave: is when something causes program execution is halted by an error.

51

New objects and ELeave When creating new objects in Symbian OS it is

done with the new command. It is so common in Symbian that the new function
will leave, that it has been overridden to an ekstra parameter, namely the (ELeave).
When the new command is called with (ELeave), new will leave well behaved and
the leave can be caught, if allocation fails.
New objects are normally constructed with a NewL or NewLC command.
NewL() creates the object on the heap and leaves if an out-of-memory error
occurs.
NewLC() creates the object on the heap, leaving if an out-of-memory error occurs,
and pushes the object to the cleanup stack 20 .
Applications should use NewL() if a member variable will point to the object,
and NewLC() if an automatic variable will point to it.

The 2-phased constructer is used to ensure a save allocation of resources

when creating an object. For instance, If an object contains another c-class object
(always allocated on the heap) it will need to allocate memory for this during its
construction. If allocation of memory for this fails, the function can not leave and
an half object is constructed. In Symbian OS an object is allocated at rst and
when it is safely allocated, it calls the ConstructL function by convention.
In ConstructL new objects, pointers etc. can be allocated, if allocation fails
here, the object can be garbage collected, because it was properly constructed at
rst.
In this way allocation of objects can happen properbly, even if allocation fails.

Active objects and threads The CActive class is used for inheritance when
a object needs to communicate asynchronously with other objects. Objects that
inherits from CActive are called active objects. A global active scheduler controls
and schedules the active objects. Among others, these objects must implement a
RunL function. When the object is set active this function can not be called, until
an outstanding request is completed by another object.
Symbian OS also provides the possibility for thread programming with use of
RThread and TThread. We have not implemented this because it was not necessar,y
when we could use an active object to suit the asynchronous needs our application
has. An active object is actually required to implement the SDP functionality and
when using sockets.

TRAPs Is a sort of try/catch macro in Symbian. It enables the user (programmer) to handle leaves. If a Leave is not caught by the user it will by default propagate
back and be caught by the active scheduler. The use of TRAP and TRAPD macro
catches the leave and program control is redirected to the trap harness macro.
20

For explanation of the cleanup stack, see [2] or [3]

52

6.2.2

Bluetooth applications development on the Nokia 3650

The Emulator The framework includes a Series 60 phone emulator, which

makes it a lot easier to test applications (is not 100% the same as the phone but it is very close). With the emulator, development time speeds up very much.
Our major problem with the emulator is that it only support Bluetooth in a very
limited way (see 4.2.1 and [21]). This means that that we need to compile, crosscompile, make an installation package, send it to the phone and install it (see appendix
A.3, before we can test the application (i.e. very time consuming).

Debugging and GUI problems It is common knowledge that a lot of time

is spend on debugging, so a good debugging environment is essential. When testing
Bluetooth applications on the phone there is no debug facility available. The only
way we could debug was with print-outs. We could do this by writing to the display
or to a le.
Unfortunately no print to screen function is available. All data need to be
written into some kind of graphics object before it can be presented to the user
though the Series 60 GUI. When writing to a display output is lost if a compiletime
crash occurs, so it is not always the best solution. But is often convenient, because
debug output can be seen real time.
If we write debug output to a le, a tool to read from a le and print the le to
the screen needs to be developed or the les needs to be send to the PC for viewing.
Sending les to a PC for output seemed impossible, because we needed Bluetooth
functionality (not present - so we should implement it ourselves to do this21 ).
In order to display written les we need to be able to write the data to the
screen. So no matter what, we need to implement such a functionality (both for
display and le writing).

Debug implementation - the application "Files" First we needed functionality to present a text through the GUI. We choose the CDesCArrayFlat and the
CEikTextListBox classes to do so. They provide the functionality needed (listbox
with textcontent, which could be printed in a window) and are relatively easy to
implement. We also have used the CAknInformationNote to show short messages
to screen. They are very easy to implement, but they do not always show if another
event occurs right after it is shown - which of cause is bad if used for debugging.
Next thing was to develop writing to a le. We made a object CFileLog to
handle this functionality, so that it could easily be instantiated several times, in
case debug output was needed to more les. This was later rewarded, since the
amount of debug output became to enormous to view in one le only.
After this was in place we developed an application "Files" to show the debug
21

ironic when this is what we try to implement!

53

output written to les. "Files" also includes the functionality to browse the lesystem on the phone. With this functionality we can browse the phone and select the
le we want to view and then view it. A le browse utility was needed, since no
description of where les is put nor the Nokia lesystem is provided. "Files" can
also delete a selected le on the phone.

6.2.3

Client Design

The design is mostly covered in chapter 5, but we will here give an overall view
on the application. The Bluetooth basic capabilities22 of the client application is
summoned up for starters:
Find a server which advertises the Museum application through SDP.
Connect to the server using the advertised connection parameters.
Handle simple user input (key presses), and transform them to server queries.
Query server and receive an answer (and present it to the user).
Reconnect to a Bluetooth server if connection is lost.
We have used the Nokia Application Wizard for Series 60 (refer to A.3 for a
"HowTo") as the basis of our application. We will shortly introduce the classes it
produces, before we continue to the Class structure of what we have implemented
ourselves. In section 6.2.4 we will go into more detail with the implementation of
these classes.

The Client State machine This statemachine (see g. 7) is central to ow

control in the client. Though the gure is not implementation specic, we will stick
to it in the implementation.

The Series 60 Application Wizard and the classes it produces When

a new project is started using the Series 60 Application Wizard from Nokia (See
appendix A.3), some classes are produced. The construction of the classes can seem
odd and un-familiar, and we will not go into detail with this (For more information
see [3] under "Series 60 AppWizard installation & users guide" ). Fortunately it
is not necessary to have a deeper understanding of these classes to implement an
application using them.
For a single view application23 the classes are as follows (when Project name is
BeremoTe):
22

These are also the capabilities of the application as it is in its current state.
Multi-view applications can also be made from the Wizard. A multi-view application is when the
application has more than one viewport (screen) defined at once. It is possible to switch between the
viewports. This could be useful in the final application, but as earlier mentioned, we will not spend to
much time on the GUI.
23

54

auto reconnect

Ready

SelectDevice

device not found no more devices

device not found more devices

disconnect done

device found

Disconnect

connect failure

Connect

connect succes
read error connection lost

Read
succesfull read

write succesfull
User input

Write

write error connection lost

Figure 7: Statemachine for the client

CBeremoTeApp Factory class which produces the CBeremoTeDocument.

CBeremoTeDocument The application class. It creates the CBeremoTeAppUi.
CBeremoTeAppUi The GUI part of the application. Here we can handle key
presses from the menu, and we can choose what items to be visible in the
menu. It also creates the CBeremoTeContainer.
CBeremoTeContainer This is the container in which we can put our code.
With this foundation we are ready to introduce the structure of the classes we have
implemented.

Class

structure CBluetoothHandler

is
instantiated
in
the
CBeremoTeContainer which is created by the wizard (se above). The classes
in Fig. 8 are used to handle the Bluetooth functionality. They make up the class
structure of the client. The white boxes in g. 8 represent the classes which we have
implemented. We have only mentioned the classes with relevance to Bluetooth in

55

the gure (and debug writing structure), and as it can be seen CBluetoothHandler
is the central class.

Client Class Structure

For debug write to file

RFs

RFile

CFileLog

MSdpAgentNotifier
MSdpAgentNotifier

MSdpAttributeVAlueVisitor

CSdpServiceSearcher

CSdpAttributeParser

CActive

CBluetoothHandler

RSocket

CBTDeviceDiscoverer

RSocketServ

CSdpSearchPattern

CArrayFixFlat<TBTDevAddr>

RHostResolver

CSdpAgent

Grayed boxes: From the framework.

White boxes: Defined in our code.

Figure 8: Client class structure for the BeremoTe client

A further description can be found below (6.2.4). For clarity, refer to Fig. 8 and
7 when reading the implementation description 6.2.4.

6.2.4

Implementation description

We will here give an explanation of the dierent classes in the client. We will not
go into detail with implementation of these. For a detailed description refer to the
comments in the code, which we have tried to make as intuitive and satisfactory as
possible. The code might seem a bit dierent from "normal" C++ code, because it
is coded for the Symbian OS.

Statemachine control - CBluetoothHandler The CBluetoothHandler

class is the class in control of Bluetooth communication. It is responsible for synchronizing events and controlling what state (see Fig. 7) the system is in.
The Symbian API states the fact, that we need to issue asynchronous requests
(when working with sockets) to synchronize socket communication. When a request
has been issued, RunL() can not be called until the request returns or is cancelled.
When the request returns RunL() is called by convention. The status of a request is
packaged into the TRequestStatus which is passed as a parameter on asynchronous
requests. An active object has such a TRequestStatus by default, which is called
iStatus. We use this in some of our synchronizations.

56

Thus the synchronization is done by implementing CBluetoothHandler as an

active object. When the object is activated from a submitted request, program
ow will be resumed in RunL() depending on the current state. The one exception is the Ready state. No requests are issued there, and it will just be passed
through if the TBool autoReconnect parameter is set ETrue. In the current version
autoReconnect can be set to false. If so, the program ow stops when Ready state
is reached (also see 6.2.6).
To summerize - Every time a request is submitted the object is set active. This
means that the CActive::RunL() function can not be called until the request is
complete. Upon request completion the RunL() function of the CBluetoothHandler
object is called. Thus the RunL() can be used as the key of statemachine control.

Connection - CBluetoothHandler CBluetoothHandler takes care of connecting and reconnecting. It uses RSocket to connect through. The RSocketServ
delivers the socket we need for communication. The socket has to be set up with
specic parameters depending on the protocol (this follows the Bluetooth Specication very close). The socket must be opened and a connect call must be done before
communication is possible.
CBluetoothHandler also registers disconnections. When the connection is
lost, the value passed from a read, write or connect request in iStatus of
CBluetoothHandler will be dierent from KErrNone. This is handled by disconnecting and closing (DisconnectL()), and then returning to the initial state
(ReturnToReadyState()). Reconnection will be done unless autoReconnect is set
to EFalse.

Read /Write - CBluetoothHandler Reading and writing is done as discussed in chapter 5.6.7. The program ow when reading and writing follows the
statemachine g. 7. When a button press is received from the user a potential
outstanding read is cancelled, and a write is done.
Right now the client reads data in 16byte chunks. This is an arbitrary chosen
value. It could be adjusted to suit the data transfered.

User interaction - CBeremoTeAppUi We also need to take care of user

input. Since the user has to be able to do some button presses, which has impact
on the CBluetoothHandler class. These must also be handled in the state machine.
But the user is restricted to make choice when connected (and in Ready state - in
this version). Input from the user is limited depending on the state. The state is
captured with CBluetoothHandler::GetState().
These choices results in a Write(...) data call to the CBluetoothHandler.
We use this info to dim buttons (render them invisible) in the popup panel in
CBeremoTeAppUi::DynInitMenuPaneL, so that the user can only press them when

57

we want them to. But we have still implemented the CBluetoothHandler defensively, so that user button presses in inappropriate states will be handled (mostly
nothing will happen).

Device discovery - CBTDeviceDiscoverer Device discovery is handled by

the CBTDeviceDiscoverer object. We have implemented two dierent way to select
a device. One where the user chooses a device from a GUI (It uses is a Symbian
plug-in). And one where the selection happens transparent to the user. The rst
one is mostly for debug use - since it can be very convenient to select the device you
want to try to connect to when debugging - especially when many Bluetooth devices
are present. The second one selects a random device from the surroundings, but if a
device has no Museum service another one is chosen. The algorithm chooses a new
device every time until no more are available. See g. 7 State = SelectDevice.

SDP & record attributes - CSdpServiceSearcher & TSdpAttributeParser The service discovery process is handled by the CSdpServiceSearcher
class.
It inherits from the Symbian class MSdpAgentNotifier, which
is a must, since it uses the functions NextRecordRequestComplete(...)
AttributeRequestResult(...) AttributeRequestComplete(...). These functions give the Symbian API to the equivalent functions mentioned in (section 3.3.7). The answer from the queries CSdpAgent::AttributeRequestL(...)
and the CSdpAgent::NextRecordRequestL(...)
will be returned into the
MSdpAgentNotifier functions, i.e. into the CSdpServiceSearcher object. To
handle the AttributeRequestResults, a special object TSdpAttributeParser is created. This is because of the rather tricky datastructure of the SDP record.
It helps cutting it into bits and pieces. It inherits from the Symbian class
MSdpAttributeValueVisitor, which is provided to help with this functionality.

6.2.5

Problems arose during implementation

We will here mention some of the problems we bumped into while implementing
the client. They are important to understand some of the things that we did during
implementation, and will be helpful for readers of the code.

UTF-8 or unicode strings Another problem, which also facilitated the

FileLog class, was the problem with dierent types of Descriptors and Buers (Symbian strings). Reading and writing to les and sockets is all done in UTF-8 (8-bit),
but all graphics presentation and string handling in general is done in unicode (16bit). In the log class we made a function to write both unicode and UTF-8. Creating
these functions was were tricky and long code, until we by coincidence stumpled over
a class which could do this for us, CnvUtfConverter.

58

RHostResolver / SDP Service discovery problem One of the biggest

problems we experienced during the implementation, was that we got another undocumented error, namely the return of -6312 from the NextRecordRequest query
in the NextRecordRequestComplete result in the service search. After browsing
the internet for this problem we found that another person had experienced a similar problem, and that it was due to the fact that a RHostResolver can not be
kept open when making a NextRecordRequest(...). This is very unfortunate (and
properly not intended by the Symbian OS implemententers) since it means that
RHostResolver::Next() function can not be used as intended together with SDP
queries. A hack solution was required. We saw two ways to solve it:
Open and close the hostresolver each time a new device is to be found. A list
of tried device must then be kept in order not to make a service search one
the same device over and over again.
Open the hostresolver and get all devices in range, and save them to a list.
Then close the hostresolver. Now the devices can be retrieved from the list
instead of with the RHostResolver::Next() function.
Both solutions are not satisfying. We have implemented the rst one, based on the
idea that a BlueTooth device server is found faster that the time it takes to get the
list of all devices. To choose the best solution both implementations must be tried
to see which one is the fastest in practice. The lookup and service search is pretty
consuming, so this is an important issue in the nal application, but we have only
implemented the rst.
To hold the list of tried devices we chose the CFixFlat class. It is easy to
implement and it dynamically increases its size when necessary. We chose it over
other array types like the RArray and linked lists. First we would have made a
linked list, but the implementation was a little troublesome. For more information
of choosing the proper Symbian Array type, refer to [1].

proper terminating Since we are working with Active objects combined with
user interaction, we need to secure a proper shutdown. That is if any requests are
outstanding at shutdown time the program will exit with a kernel error. To this
purposes with implemented a TerminateL() function in the CBlueToothHandler
object. When this is called it is ensured that when the next request is completed,
the program will shut down properly.

6.2.6

Users guide - Testing BeremoTe on the mobile

When the program "BeremoTe" is opened 2 buttons can be pressed: "Valg" and
"Tilbage". "Tilbage" always terminate the application. The "Valg" button gives
dierent possibilities depending on the Bluetooth state.

59

The program is still in a test version. This means that user need to press a
button to activate the connection process. When the program starts it is state
"Ready" (see g. 7), which gives the following possibilities if "Valg" is pressed:
1. (Conn auto Ser reconnect)
2. Conn auto Mus reconnect
3. (Connect auto Ser)
4. (Connect auto Mus)
5. (Connect UI Ser)
6. (Connect UI Ser)
7. exit
Items in parenthesis in the menu are only implemented for debug purposes. The
intended command is (2) which should be selected transparent to the user in the
nal application. Explanation to debug usage:
"Conn" = Connect. This means that connections procedure starts.
"auto" means that the client connects to a device without userinterface.
"UI" means that the user is prompted with a list of devices. And the user will
have to choose what device to connect to. (for explanation of auto and UI refer to
6.2.4).
If "reconnect" is selected the client will retry to search for devices when all
devices in range has been tested. If "reconnect" is not selected the program will
return to the Ready state and stay there until the user makes a new choice.
"Exit" also terminates - like "Tilbage" - the application.
When a connection is established data can be written to the bluetooth server
device by pressing "write" from the "Valg" menu. When data is received it is printed
to the screen in a pop message. This represents the pushing a button and receiving
corresponding data in the nal application. Also the buttons 5, 6 and 7 can be
pressed. This emulates an user choice, which is send to the server. When this is
done, the server answers with a message according to the key pressed. The message
will in this implementation be written to the client display. In our current version
it maps to a Hello World message dierent languages. Thus sending 5 you get it
in English, 6 in Spanish and 7 in French.
When running BeremoTe, data is written to a number of les used for logging/debugging/testing. These can be used with the program "Files". In "Files"
Use the joypad to selected and open le. Press left to exit from a le. "Tilbage"
and "Exit" terminates the application as in "BeremoTe".
When BeremoTe is restarted all debug and log data (for use in debug utility
"Files") is deleted (screendumps can be found on the CDROM).

60

System assessments and test

This project is a pilot project - so we will not make a full test, but only make a few
central setups to prove that it seems to work. Neither will we mention the internal
testing and progress of this. We will only say that as far as we are concerned our
internal testing of the client and server application seemed to work perfect.
What we will test is our application according to the functionality stated in 6.1.2
(the server) and 6.2.3 (the client). Since the server and client connect to each other
some of the client testing implicitly tests the server and vice versa.
We did not have the equipment to make all the tests we would have liked to
do, so some of the tests are limited by this problem. Thus we can not test the
actual load of many clients and servers, nor potential connecting problems with
many devices in a piconet.
The movie clip (found on the CD-ROM /test/video/clienttest.mov) contains an
example of a test of our application.
In the client as you are about to see, we tested towards a serial port, since we
have more dierent devices implementing the Serial Port Prole, and thus a bigger
test setup (more devices) could be set up.

7.1

Testing the client (Nokia 3650)

First it should be said that a huge amount of internal testing on the dierent
functions have been done. Some of the debug output is still retained in the debug
les24 . The reader should also refer to small pictures on the CD-ROM (test/pictures)
for test output, since its very tricky to send output from the phone to the PC in
another way.
During the development of the client, we tested against existing stacks which
implements the Serial Port Prole. We chose the serial port prole, because it is
implemented on almost every Bluetooth device, and because HyperTerminal (Windows) and MiniCom (Linux) can be set to read to and from a virtual Bluetooth
serial port. Testing against dierent stacks, already known to work, gives the advantages that we very well-founded can assume our client to work, if it works with
these. Moreover we nished the implementation of the client rst, so it was an
obvious way to test it as long as the server was not ready.
24

Can be viewed with the program "Files". The output files are btdebug.txt and btlog.txt from the
CBluetoothHandler class, btdevlist.txt (device list updates) and btdevdisc.txt from the CDeviceDiscoverer class and btsdplog.txt from the CSdpServiceSearcher class. They are created on the phone as
program continues. On the included CD-ROM (test/video/clientdebuexample.3gp) a video example of
viewing these files can be found.

61

7.1.1

Testing a connection

With this setup we could see if the text,our client sends is received correct, and
we could write text to the client and see if it was received correctly. We tried
to connect via the SDP functionality to the serial port. After information about
connection parameters where received from SDP we made a connection, and then
we tried to read and write some data.
Result: It worked, but the receive buer is currently implemented in a way that
it takes data in 16 bytes chunks (see 6.2.4).

7.1.2

Testing disconnect and reconnect

Since we have several devices running the serial port prole this makes it possible
to test whether the disconnect and reconnect procedure works. This functionally is
very close to the functionality of the Bluetooth part of the museum application. A
disconnection can happen for several reasons: Due to connect failure, due to read
failure and due to write failure. Since our client is implemented in a way such that
it always either reads or writes when it is connected, it will always discover when it
has been disconnected. We have also implemented a disconnect button (for debug
purpose).

Test setup 1 Several servers (3 with the Serial Port service and 2 without) and
one client all close to each other. Disconnect is done with a manual key press.
Result: It works. Connection is established to the Serial Port servers in turn.
It does not connect to a device without the selected service (Serial). We tested
connect time to be 1-17 seconds per connection with an average of 5,9 seconds25 .
Since much of the time is probably spend on searching the device without an
service, the following is assumed:
It is likely that connect time will go up when the number of device without the
service searched for gets higher compared to those with the wanted service.
Also the number of services on the nearby device is likely to raise the connect
time.
The more nearby devices, the more the connect times will probably spread. This
is due to the fact that more device in without the searched service will be selected
in a row.
Also connect time is under the inuence of interference from other devices etc
(See 3.3.1).
25

25 Reconnections (results in seconds):

3, 13, 5, 1, 5, 1, 4, 5, 2, 5, 4, 5, 17, 7, 5, 6, 5, 6, 5, 6, 10, 8, 5, 9, 5. Avg. 147/25=5.88.

62

Test setup 2 Several servers (3 with the Serial Port service and 2 without)
and one client. The servers are placed outside the reach of each other. Disconnect
happens when trying to write, due to too long range or due to unplug of server
Bluetooth device.
Result: It works, but how long time does it take until disconnect is recognized
by the client?
When pulling the Bluetooth plug on the server: about 20 seconds.
When writing: 1-2 seconds.
When moving outside range: 20-25 seconds in average26 .

7.1.3

Conclusion about the client test

At rst glance these results of Test setup 2 do not look good. But in practice waiting
20 seconds for a disconnection would probably not be an issue. Often a user will do
a key press when leaving an area covered by a Bluetooth servers, because he would
like to take a look at a new exhibition item, were he has gone to27 . 1-2 seconds after
the key press, he will be disconnected and reconnection can commence. This still
leaves the client with a waiting time of between 2 and 20 seconds28 , when changing
server. The worst case of 20 seconds would be annoying to the visitor. The average
case of about 7 seconds would tolerable for the patient visitor.
The best case is that reconnection is done transparent to the user: Sometimes
the user will maybe leave one Bluetooth server area and enter a new one, while
talking, watching an item or some else, and the disconnect reconnect procedure will
thus happen transparent to the user.
We could implement a "connection test write" or an update and thereby get a
quicker recognition of the disconnect, but is it really worth it?
We have made the above shown tests with Servers running the museum service
too. And the results seems - not surprisingly - to be the same. The two dierence
are, 1) that when sending from the client an answer is automatically generated and
returned from the server 2) the connection is done over L2CAP instead of RFCOMM
(see 6.2.4 for the dierences).
When a key press is done the appropriate answer prompted right away. That
the write and read of the socket is done in less than 12 a second, which is very nice.
26

This is probably 20 seconds. This slack is very probably due to the problem that device has to be
transported from inside range to outside range when tested, and it is hard to determine exactly when
the boundary is crossed.
27
Acquiring information about a new exhibition item requires user interaction - see 5.2
28
Disconnect (1->2) seconds + reconnect(1->17) seconds

63

To summon up, a connection to the Bluetooth server can be established with the
use of SDP. The connection can terminate properly and reconnection can happen
upon disconnection, though the reconnection time can seem a little to long. When
connected data can be received and sent.

7.2

Testing the server (Linux PC with BlueZ)

For all our testing purpose we used standard calls to printf and the syslogger.
All the incoming client connections and request are logged with the syslogger (see
appendix B.1), so that we can follow a trail of our virtual visitor in the museum as
earlier stated.

7.2.1

Testing the HCI layer

We had to test our HCI layer on the server in order to use our
getActiveConnections method. For doing this we used the hcitools delivered
from BlueZ to test our HCI layer on the server. With this in our hands, we could
compare the results. We listed the active connections with the command hcitool
con and the result was correct. We also used the hcitool dev to display our local
BlueTooth devices, which also was correct.

7.2.2

Testing our advertising

First of all we wanted to test our connection towards the sdpd. We connected with
the given API in BlueZ (sdp_connect()) and it seemed ne (the method returned
1). So now that we had a sdp session, we tried out to advertise a given service. We
had to assemble a sdp record that could contain all the details that we wanted to
advertise. We did that, but it took us hours to develop because of that vain and
somewhat lame list structure of SDP record in the BlueZ API. We added the record
and used the sdptool (which was delivered with BlueZ) to view our attributes. It
looked ok. We got all the attributes like our root node (Public Browse group), our
service class, our record handle, our protocol (L2CAP) and the advertised PSM
(which initially was 5). For testing more than one service, we also implemented a
museum_audio_service, which also worked correctly.
Our output from our small SDP test can be seen in our appendix B.2. This one
shows what SDPd are advertising, when we have constructed and updated the SDP.
When this was tested we tried to delete the services again. And it also worked ne.

7.2.3

Authentication

Although we earlier stated (see 5.5) we will not concern much about the security
level, we have to test our conguration (no authentication at all). We did this by
changing our server conguration le (/etc/bluetooth/hcid.conf ). This worked out

64

perfectly and we where able to connect with a client when we had the authentication
disabled. If we enabled the setting, we would be prompted with a password.

7.2.4

Connection test

When we have the advertisements in place we had to make our server listen to
the already advertised protocol and channel. This is quite easily done through some
objects and of cause works. When the establishment of the connection worked all the
way around we started to test our client against it. To test the server connection,
we implemented a small echo server which worked ok, but we had some trouble
controlling the size of the sequential packages (omtu and imtu in the source code)
in the L2CAP layer. But we easily solved it, by setting the size of the server and
client to the same value.
with this in mind, we quickly changed the echo server into our you museum
application server and developed it further. We implemented reading and writing
les to and from the client and tested it again. It worked like a charm.

One server Bluetooth device one client . The rst thing we wanted to
test in our application, was the simple point to point network layout. We started
up our server and tried to connect our phone. Our result was, that we could receive
the requests from the phone, and send back the data correcly. It worked on the
server side, as we saw in the client test(see 7.1.1). By the command hcitool con
we get the following output, which shows that a connection is establish from our
client (00:60:57:3D:67:95 is the Bluetooth MAC address of the client) towards our
server. It also shows that the client connects like a SLAVE.
Connections:
> ACL 00:60:57:3D:67:95 handle 43 state 1 lm SLAVE
To prove our concept with fork and sigaction works (see 6.1.3), we tried to view
our current processes before and after disconnecting with the client. We issued the
ps -ax|grep beremote command and got the following result when no clients where
connected:
beremote
We tried again when we had connected with the phone, and then got our beremote process with a child (the client connection):
beremote---beremote
Thus proving that our connection and process handling works out ne in a pointto-point network. In appendix B.3 all the processes running on our server can be
seen. In this way we can also see, that we execute our beremote parent process in
a bash shell and it forks out when a client connects.

65

One server Bluetooth device two or more clients . Having one client
connected, is one thing having serverel is another. For testing a small piconet
we tried to connect two clients to our server. Thus also proving that our fork and
PSM works ne, without updating it, which we earlier thought was a problem. For
testing with multiple clients, we used our own simple BlueZ client (client.cc) a long
with our phone. This was because, we only had one phone. The client was a simple
one, developed only to connect. In this way we should be able to simulate several
clients.
The connections to our server when we had the two clients connected, showed
what we had hoped for. We got the two clients in our incoming connection state
(see output down under), and they where both in a slave condition.
Clients connected to our server. The 00:60:57:3D:67:95 address is our phone and
the other one a bluetooth dongle using our simple BlueZ client code:
Connections:
> ACL 00:60:57:3D:67:95 handle 43 state 1 lm SLAVE
> ACL 00:01:53:00:0D:B5 handle 41 state 1 lm SLAVE
In this way we have showed that our server can handle multiple connections. We
also tried to send to the server, which also worked ok. It sends back an answer, with
the correct data (language options). Our server also spawns of two children, which
also indicates that our fork() and sigaction works ne when clients are connecting.
The beremote process with the two children:
beremote---beremote--beremote
When we disconnected with the clients the spawned children died o and only
the parent process where left behind. This is exactly what we wanted. The parent
process is yet operating and still can receive incoming connections. Our output from
the syslog can be found in appendix B.1.
During our research we also discovered that, when we connected with several
clients on the server (a piconet), the throughput went somewhat drastically down.
Through our naive and quick internal testing of connection speed, we got troughput
of 50-60KB/Sec if one client where connected and about 10-12KB/Sec if two where
connected. Unfortunately we did not have time to dig deeper into this, but it
certainly could be a show stopper if we wanted to make large video streaming to
the clients. Of cause this is a area that has to researched further if a real scenario
has to be implemented.

Two or more Bluetooth devices in the same server one client In

this scenario we whish to test whether one SDPd can advertise the given local
services to all the Bluetooth devices attached to it. We will also see if it is possible
to connect to all the devices attached to the server (if more than one).

66

We tested this by plugging two USB Bluetooth devices into our server with only
one SDPd running. By connecting the client to the server Bluetooth devices one at
the time, we saw that this could work. We used the device selection UI on phone
(see 6.2.4) to select specic devices to make sure that we hit both the server devices.

Full blown scenario. In this scenario we have a lot of servers (and server
devices) and clients. We have not yet tested this, because it is simply not currently
possible. This is due to the lack of equipment, but as we have seen in the previous
tests; it works with more than one Bluetooth device in the same server, and that
a piconet can be established on each of them. This indicates that the idea of
scalability.

Disconnect and closing. We have earlier showed that our fork() process along
with our accept() call in our server seems to work ne, we have implicitly showed
that disconnecting works as well. We have also earlier stated that we close the
parent process sockects correctly when our child spawns o (during the accept call).
This indicates that a correct disconnect feature is used. This though was the most
tricky part, when using fork to close the right socket, at the right time.

7.2.5

Conclusion on the server test

Our conclusion on our test must be, that our server seems to work ne in our small
mock-up scenario. Of cause we have not tested the server in real life with many
Bluetooth clients, but we have showed that it is clearly scalable. Our fork and
all the process handling works like it should do, also if two or more clients where
connected. Also our small text transfer (sending and reading) seems to work out
ne. We fetch our text and send out the correct data depending on the requests
from the client. The only thing that concerns us most be the throughput when
multiple clients are connected. But since we have not yet investigateed further, we
will not dismiss our idea about transfering a lot of data (e.g. video or audio streams)
to the clients.

7.3

Other tests

We would have liked to test the developed software on other Series 60 phones and
even maybe other Symbian OS 6.1 phones (not Series 60). As far as we can see
it should work on Series 60 phones, but you can newer know with this kind of
embedded devices. . .
We also made a small setup to see if we could connect the Nokia 3650 phone
to a Jabra BT-250 Bluetooth headset meanwhile it is connected to the Museum
application. As expected (see 3.3.9) in could not do so.

67

Conclusion

We will base our conclusion on the goals set in 1.4. Did we then achieve our goals?
a) To learn something about Bluetooth. Its advantages and limitations.
When we rst started on the project, our basic skills and knowledge about Bluetooth was very limited. After this project we have become very familiar with many
parts of the Bluetooth stack. This of cause, meant a lot of research, but it really
paid o. We have learned that Bluetooth has some limitations, e.g. in the network
topology, as well as we have seen that it seems promising in ad-hoc based networking.
b) To test dierent BT devices and stacks.
We have taken a look at some of the Bluetooth stacks currently available. We have
taken a deeper look into especially two implementations, namely BlueZ, the ocial
Bluetooth stack for Linux, and the Symbian OS 6.0 Bluetooth stack. Though the
implementations are good and well working, a great deal could be done on the
documentation side of them - especially BlueZ. Some functionality is also missed
once in a while. Setting up the phone environment have been time consuming hard
work, because of the lack of good and organized information. Programming in
general have often been trial and error coding. In Symbian programming has been
very inconvenient, because of the lack of debug facilities.
We have seen dierent devices work together: Windows PC with USB-dongle,
Linux PC with USB-dongle, iPAQ with Windows CE, Ericsson T610 with Mophun
OS and Nokia 3650 phone with Symbian OS. We would like to have tried Java on
the client, but we did not have the hardware to do so.
c) To make a small application which show these advantages/limitations.
Our tests of the chosen museum pilot project have not been as extensive as we
hoped for, i.e. we still need some large scale testing to say that the concept could
work in full. But except for the large scale testing we have achieved the basic
functionality that we had hoped for (see test conclusions in 7.1.3 and 7.2.5). It
is though worth mentioning that the reconnection waiting time seems some what
high, though managable (see section 7.1.3). Also limited throughput could give a
problem (see 7.2.5).
Unfortunately we have not had time to implement some of the more advanced
features like transport of pictures and streaming of audio and video or power
consumption modes, but as far as we have read about it, it seems very possible.
All in all it looks very promising, and the Bluetooth technology actually seems
to t well into context and location-based applications like this, as we see it right
now. It has been an interesting and fun project to work with Bluetooth and to build

68

up a small application like we did. Although it was quite time-consuming.

Future Work

Because our project is a pilot application, improvements can still be made. Eg.
we need a better error handling, and perhaps making it a try/catch model instead
of the current return staments, we could easily propagate our errors and handle it
some where we see t. This is a bit more messy in the default way in ansi c.
What we really would like to implement is the image/audio streaming, as we
stated earlier in the report. It could be very interesting to see how we could get our
clients (the cell phones) to stream these codecs and show/play them in a nice way.
We would also like to make a more real life scenario, where we could have a big
setup with a lot of servers and several clients connecting. Thus also making the
backend database server for fetching the text, video and audio. In this case it could
be very interesting to investigate how this would eect our throughput. Especially
now where Bluetooth have come in a version 2.0 (released 9th november 2004).
Maybe we could draw the advantage of the newly updated version of Bluetooth
which has a lot of advantages:
Three times faster transmission speed.. (sometimes up to 10 in certain cases)
Lower power consumption through reduced duty cycle
Further improved BER (Bit Error Rate) performance
Simplication of multi-link scenarios due to more available bandwith

9.1

Server

For the server point of view, it could be interesting to see if we could make a better
object oriented design as we discussed. Right now it is a little bit messy. We could
make somekind of "interface", which would make it possible to implement other
protocols easily and new method to these .
A java implementation of the server could also be of interest. This of cause
should only be done if the client also is developed using java. This would then
increase the consistency and make the design a lot clearer. This however whould be
somewhat more tricky.
As for now we have only found one API for the BlueZ stack in Java (avetana
bluetooth), which really do not yet have a fullling stack API. Therefore if we want
to implement the server in java, we have to implement some JNI/BlueZ our self,
which will be time-consuming.
An option we also discussed was to do load balancing on the Bluetooth server. It
could be interesting to examine if we could improve the throughput, if we had a lot

69

of bluetooth devices plugged into the server. And thereby distribute the incoming
client connection on the dierent server devices.

9.2

Client

In our implemented version of the client, we have only made a very limited GUI
for the user. This of cause should be enhanced to be more intuitive. This however
would require a lot of really advanced development skills in Series 60 programming
and other GUIs.
Of cause when we are involved with embedded devices, like our client is, some
interesting aspects arises:
How can we present the text/audio and GUI in a smart way?
How can we detect the type of Bluetooth device the user have and present the
data in a proper manner considering the devices properties?
How do we make our museum application portable?
As many dierent types of handheld devices exist, all with dierent technology
and features, our client should be able to detect the type of device and present
the information adapted to the technical capabilities of that specic device. E.g.
minimize the graphical performance and battery life time for smaller devices like
cell phones, and make better use of the audio/graphical system if it is provided.
E.g. a Handheld or Laptop has a more powerful graphical subsystem than a cell
phone. For example if the visitor have a iPAQ, we should be able to stream out the
information in a really advanced way, with a lot of graphics.
To solve this we could implement the client in Java instead. Java Midlet has
some interesting features like determining the type of a device, it limitations and
such.
We could also implement it directly in our application, such that a visitor has
to ll in some kind of device type, when he/she is checking into our museum.
Thereby the client could tell our server which type it is, and get the information
presented in a dierent way, depending on the device type. Also it would probaly
make our application more portable.
It is very exiting to see what the future will bring in handheld/mobile Bluetooth applications area. There is alot of dierent platforms out there, like:
Symbian, Java Midlets, Windows CE or smartphones. All of them having the
potential to be a standard in the future. This of cause is a area that interests us a
lot and we really like to research it further.

70

References
[1] Bray, Jennifer and Sturman, Charles F.
Bluetooth 1.1 - Connect Without Cables second edition
Prentice Hall, 2002. ISBN: 0-13-066106-6
[2] Harrison, Richards.
Symbian OS C++ for Mobile Phones
Wiley, 2003. ISBM: 0-470-85611-4
[3] Reference manual for Symbian OS.
Series 60 SDK for Symbian OS
Nokia 2003.
[4] Savitch, Walter
Problem Solving with C++, the object of programming (3rd ed.)
Addison Wesley 2001. ISBN: 0-201-70390-4
[5] Tanenbaum, Andrew S.
Computer Networks(Third edition)
Prentice Hall International Editions, 1996. ISBN 0-13-394248-1.
[6] Sechrest, Stuart.
An Inroductory 4.3BSD, Interprocess Communication Tutorial (socket documentation)
[7] Fowler, Martin
UML distilled second edition
Addison Wesley 2000. ISBN: 020165783x
Reports and articles
[8] Larsen, Steen et. al
Real-time image processing on an iPAQ based robot(iBOT)
DIKU, March 2002.
[9] Blum, Troels & Nimb, Ole
TCP/IP over Bluetooth
DIKU, 2002.
[10] Ian Mullins, Philip Garner and Reuben Edwards
article: Novel Peer to Peer Payment Mechanism for Personal Area Network
Mobile Gaming
Department of Communications Systems, Lancaster University
[11] Hopkins, Bruce and Antony, Ranjith
Bluetooth for Java
2003.

71

[12] Jeremy Kong Win Chang

An Interaction of Bluetooth Technology for Zero Interaction Authentication
School of Computer Science, Carleton University, 10 April 2003
[13] Marcel Holtmann, Andreas Vedral
Article: "Bluetooth Programming for Linuz"
Wireless Technologies Congress 2003, Sindelngen, Germany
Links and articles29
[14] www.google.com
Everythins starts here. . .
General Bluetooth information

[15] http://www.bluetooth.org
The ocial Bluetooth membership site.
[16] Article: Protocol Architecture
[17] Article: Bluetooth Core Specication v1.2
[18] https://www.bluetooth.org/foundry/assignnumb/document/service_discovery
Bluetooth assigned numbers specication
[19] http://forum.nokia.com and http://www.forum.nokia.com/main/1,6566,1_43,00.html
Provides a lot of help and the following articles:
[20] Article: Designing Bluetooth apps for series 60.pdf v1.4
[21] Article: Setting Up and Using Bluetooth Test Environment v1.2
[22] Article: Bluetooth Technology overview v1.0
[23] Article: Games over Bluetooth: Recommendations to the programmer v1.0
[24] http://www.benhui.net/modules.php?name=Bluetooth
The harmony of mobile development. Lots of Bluetooth stu.
[25] http://www.palowireless.com
A very well organized web page about Wireless Product. It contains a lot of
helpful information about Bluetooth.
[26] http://developer.sonyericsson.com/site/global/home/p_home.jsp
The developer site for Sony Ericsson Programmers
[27] http://www.symbian.com
The home of Symbian OS
[28] Article: Symbian os: Designing Bluetooth Applications in C++
29

Articles are mentioned after the address where they can be found.

72

[29] http://series60.com
The home of Series 60 devices
[30] http://www.csrsupport.com/
The leading manufacturer of Bluetooth chips.
[31] http://www.embedded.com/2000/0007/0007ia1.htm
Some general information about Bluetooth
[32] http://www.bluetags.dk
This site has closed due to liquidation. It once was a Danish Bluetooth
development company.
Installation

[33] http://www.debianguiden.dk/
Help on how to install Debian Linux - in Danish.
[34] http://www.debian.org/
Debian Linux home
[35] http://www.bluez.org
BlueZ: The ocial Bluetooth protocol stack.
[36] http://web.inter.nl.net/users/hanscees/bluezhowto.html#links
Another BlueZ Howto
[37] http://www.frasunek.com/HOWTO-Nokia7650-Bluetooth.txt
Another Bluez HowTo
[38] http://www.geocities.com/m_evmenkin/
Maksim Yevmenkins site with Bluetooth drivers for FreeBSD.
[39] http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
Platform SDK for Windows XP download page
Programming hints and examples

[40] http://cvs.sourceforge.net/viewcvs.py/bluez/utils/test/l2test.c?view=markup
BlueZ utils l2test.c sourcecode
[41] http://www.compsoc.man.ac.uk/ ashley/bemused/
The great Bemused Windows Remote for UIQ and Series 60.
[42] http://www.forum.nokia.com/main.html
Good Bluetooth example for Series 60 phones.
[43] http://devzone.possio.com/Examples/BluetoothStarter.html
J2ME Bluetooth implementation example for Possio JSR-82 implementation.

73

[44] http://www.lowtek.com/sockets/select.html
A short explanation of the idea "select()"
Newsgroups / forums

[45] http://www.lenholgate.com/archives/000102.html

[46] http://www.lenholgate.com/archives/000104.html
Bluetooth sockets on Windows XP SP1 and hardware compatibility.
[47] http://forums.devshed.com/
C++ newsgroup we attended.
[48] http://discussion.forum.nokia.com/. . .
forum/forumdisplay.php?s=9327fc6c339dbab5dc82233b8a2c3b0c&forumid=38
Forum Nokias Bluetooth discussion forum
Bluetooth with Java and J2ME

[49] http://www.jcp.org/en/jsr/detail?id=82
[50] http://www.jcp.org/aboutJava/communityprocess/review/jsr082/
The JAVA JSR-82 specications.
[51] http://www.microjava.com/
J2ME stu
[52] http://sourceforge.net/projects/javabluetooth/
Applications on sourceforge in category Java and Bluetooth
Links sites

[53] http://ttt.upv.es/pmanzoni/jinx/b_programming.html
HandOn Bluetooth useful links.
[54] http://www.mulliner.org/bluetooth/
Mulliners personal projects and links to Bluetooth
[55] http://www.holtmann.org/linux/bluetooth/
Many good and usefull links - but also some old and obsolete ones. Max
Holtmann is the main developer of Bluez.

74

A
A.1

Setting up the environments

Installation of bluetooth on Windows XP

Install windows XP (home or professional) Patch with SP1 Patch with

Q323183_WXP_SP2_X86_ENU.EXE from the archive bt_stack_rtm.exe
Install the Microsoft Platform SDK (only core needed for BT support) Install
the MS VC++
Plug in your designed for Windows XP Bluetooth hardware

A.2 Installation of BlueZ with Familiar Linux on an

iPAQ
Establish serial connection to iPaq:
Connect via minicom/hyperterminal with the following configuration:
-baudrate: 115200
-databit: 8
-par: none
stop bit: 1
flowctrl: hardware
Install bluez on the iPaq:
download bluetooth-modules-kernelversion-rmk3_
type in:
ipkg install bluetooth-modules... (modules og stack)
(ipkg install task-bluetooth
(dbt suite))
ipkg install bluez-lib
ipkg install bluez-utils
ipkg install bluez-hcidump
ipkg install bluez-sdp
ipkg install bluez-pan
ipkg install pskey
ipkg install rfcommd
Make a shell script for startup of bluetooth (/etc/init.d)
It is important to use the CSR chipset which is embedded into the iPaq.

75

Edit /etc/modules.conf to add the appopriate modules to the kernel at startup.

make a link in rc2.d for automatic startup of bluetooth.
modprobe hci_uart
/etc/init.d/bluez.sh start
sdpd has to be started to register services
commands:
Inquire BT devices: hcitool -i hci0 inq
BT navn: hcitool -i hci0 name <BT ADDR>

A.3 Getting started with programming the Nokia 3650

with Symbian OS
This describes What software we had to install to get the development environment
up and running on Windows. This is for C++ programming only (not Java).
We were not able to make it work on Win98SE.
Win2000 requires service pack 4.
WinXP requires service pack 1.
Internet Explorer should be version 5.5 or higher. We use IE 6.0 SP1.

Installation HOWTO
1. Install MS Visual C++ 6.0
(Higher version or .net version will probably work to)
Not for free download
2. Install SUN JAVA SDK 1.3.1 (1.4.2.01 ??????)
http://www.sun.com/
3. Install Active Perl 5.8.0. build 806
http://www.activestate.com/
4. Install Series 60 SDK For Symbian OS, Nokia Edition (Developer platform 1.0
and 2.0)
http://www.forum.nokia.com/

Setting up EPOC utilities in MSVC++

copy AvkonAppWiz.awx + AvkonAppWiz.hlp to MSVS template dir. (default
C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Template)

76

 Install the EPOC bar.

Copy the EpocTools.dll to the Add-ins directory.
Check the "EPOC Toolbar Add-in" in the "Add-ins and Macro Files" menu.
For detailed info see the README le. . .
<symbianpath>\Series60Tools\epoctoolbar\readme.txt

Setting up the Example HelloWorld From the command prompt do the

following: (there can be some problems with the mix of forward- and backslashes)
1. type cd <symbianpath>\epoc32ex\HelloWorld (the symbianpath defaults to
\Symbian\6.1\Series60)
2. copy the folder to your favorite "myfolder"
3. type: cd <myfolder>\HelloWorld\group
4. type: bldmake bldfiles
5. type: abld makefile vc6 (builds the workspace MS Visual C++)
This creates a workspace le in this (very long) path:
<symbianpath>/epoc32/build/"myfolderpath"/HelloWorld/wins/HelloWorld.dsw
fx our path is:
"C:\Symbian\6.1\Series60\Epoc32\BUILD\BT\OPGAVE\SOURCE. . .
\SYMBIAN\FSTEST\GROUP\FSTEST\WINS\HelloWorld.dsw"
6. Open MSVC++.
7. Open the created workspace.

Using the application guide framework This approach gives you the a
minimal application that will run on the phone. This is very usefull when you want
to start a new application from scrath. As you will experience the framework is
quite big and you will probably need some time to browse trough this minimal code
for a while before your are ready to begin the actual coding.
To do this just open MSVC++, press FileNewProjects"Series 60 AppWizard
v 1.9" and follow the guide.

Compiling and executing your code on the emulator

F7 saves all les and builds the project.
CTRL+F5 starts the emulator. First time the emulator is used in the
project you will be prompted for the path.
The path is <symbianpath>/epoc32/release/wins/udeb/epoc.exe

Compiling and executing your code on the phone This is a actually

easier and more robust using the commandprompt than using the EPOC toolbar
build utility.

77

1. Save all your les in MSVC++.

2. Open a commandprompt.
3. Go to the directory with the .pkg le. Usesually in the SIS or group directory.
4. Make sure that the paths in the .pkg are correct. If not you need to correct
them (They will not be if you have copied the les from another directory.
5. type: abld build thumb urel
6. Create a .SIS package from the commandline.
type: makesis -v HelloWorld.pkg hello.sis
7. Use "send to" (via bluetooth ir IrDa) to send it on the phone.
8. Go through the installation procedure on the phone. Hint! You cant copy the
.sis le to the phone if it already exists there in the rst place. So its clever
to delete the .sis le after each install if you plan to test with new versions of
your program.

Some problems we stumbled over when coding Adding libraries ...

The framework...
If you get this error:
* RCOMP failed - deleting output files
NMAKE : fatal error U1077: perl : return code 0x1
Stop.
It probably because you have edited the resource les without closing the emulator.
If You edit the resource les you will need to close the emulator to compile your
project.
If you add some new libraries it sometimes help to recompile the workspace to
make it compile in MS VC++. If your project compiles in the commandline, and
not in MS VC++ this is probably the case.

A.4

Getting started with Bluez on Linux

In this hole project we have used Debian GNU/Linux. This Linux distribution
set was chosen because of the nice and easy-to-use package system and its proven
stability of released source code. We downloaded the Debian Woody 3.0 release
2 CDROM image from the Debian website: www.debian.org and installed it.
Good information about installing Debian can also be found on the page. Besides
http://www.debianguiden.dk/ was of great help. Here after we had a complete operating system with kernel, standard drivers, shell and of course gcc on it. We start

78

out by upgrading the Linux kernel and patch it with some code by Holtmann (the
author of much of the bluez code). This was done because of Linux incompability
with bluez in the 2.2.x kernels (which ships with Debian). We choose to use the
2.4.18 kernel because of the stability. We tried out some newer kernels in the 2.6.x
codebase, but they did not prove to be stable enough or even work.

A.4.1

Upgrading the kernel

cd /usr/src
apt-get install kernel-source-2.4.18
bunzip2 kernel-source-2.4.18.tar.bz2
tar xf kernel-source-2.4.18.tar
mv kernel-source-2.4.18 kernel-source-2.4.18-mh12
cd kernel-source-2.4.18-mh12
download patch-2.4.18-mh12 from http://www.holtmann.org/linux/kernel
cd kernel-source-2.4.18-mh13
zcat /usr/src/patch-2.4.18-mh12.gz | patch -p1
answer: [No, Yes]
make menucong (include bluetooth stu as modules and remember to include
usb-support)
Check the .cong le to see everything is right (so we dont need to re-compile
again)
make oldcong
make-kpkg kernel-image (kernel-package package needed)
cd ..
dpkg -i kernel-image-2.4.18_10.00.Custom_i386.deb
answer: [No, Yes]
reboot
Pray and hope for the best :o)

A.4.2

Upgrade the distribution to unstable

This we have to do in order go get the proper bluez code which dont ship with the
Debian stable distribution.
use apt-setup and edit /etc/apt/sources.list to get an stable internet path.
edit stable to unstable ... make a copy of the line

79

 apt-get update (apt-get upgrade might be nessary)

Install bluez stack
apt-cache search bluez
apt-cache search sdp
install the listed packages found in the search with the command: apt-get
install <package names>

A.4.3

Loading the drivers and starting the BT stack

modprobe hci_usb install the HCI usb bluez driver in the kernel.
sdpd start up the SDP daemon.

A.5

Setting up BT on FreeBSD

Basically the Bluetooth stack handles the same way as the bluez stack on Linux.
That is when you installs it, itll behave like a NIC (network interface) where you
have tools like ifcong, ping etc. available.
Also bridging are available..

A.5.1

Installing

Because the Bluetooth stack is quite new it is only available in the FreeBSD 5CURRENT branch and is therefore not included in the standard kernel (which is
the stable FreeBSD 4.xx-RELEASE). Also some of the userland applications (a lot
of tools) in the port tree is available only for the UNSTABLE kernel. But we tried
to install it after all and it worked like a charm!.
To be sure to have the latest branch of the stack and userland applications you
have to download them for your self, by getting a snapshot from Maksim Yevmenkins
site [38]. The do the basic BSD make steps to build the libraries and ports by:
1. cd to snapshot/src/sysmodules/netgraph/bluetooth
2. make
3. make install
4. make cleandir
A small HOWTO can also be found on the ocial FreeBSD page at:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-bluetooth.html

Developing. When you have installed your BT stack and all your additional
tools, you are now able to develop BT applications for your self. All you need to do
is to add a bluetooth.h header in your C/C++ le (#include <bluetooth.h>).

80

Test results

B.1

Server output in syslog

Our output from our server in the syslog, when two clients are connecting. Of cause
the log is snipped, so only the interesting part is there.
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec
Dec

13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13
13

B.2

15:34:11
15:34:13
15:34:13
15:36:20
15:36:20
15:36:20
15:36:20
15:36:20
15:36:20
15:36:20
15:36:20
15:40:32
15:40:32
15:40:32
15:40:32
15:40:32
15:40:32
15:40:32
15:40:32

fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck
fsck

sdpd[615]: Bluetooth SDP daemon

beremote: Waiting for connect...
beremote: accept called! 0
beremote: child spawning 0
beremote: Connect from 00:60:57:3D:67:95
beremote: local address 00:40:05:60:41:0D
beremote: Accept ok.
beremote: Connected with [imtu 672, omtu 0, flush_to 65535]
beremote: starting to receive data
beremote: parent process returning 622
beremote: accept called! 622
beremote: child spawning 0
beremote: Connect from 00:01:53:00:0D:B5
beremote: local address 00:40:05:60:41:0D
beremote: Accept ok.
beremote: Connected with [imtu 672, omtu 0, flush_to 65535]
beremote: starting to receive data
beremote: parent process returning 625
beremote: accept called! 625

SDPd output

Here is what our SDP daemon replies back, when we uses sdptool to search our
service. Our service class list is set to 0x1FFF.
Browsing 00:01:53:00:14:EE ...
Service Name: SDP Server
Service Description: Bluetooth service discovery server
Service Provider: BlueZ
Service RecHandle: 0x0
Service Class ID List:
"SDP Server" (0x1000)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 1
Version: 0x0001

81

Language Base Attr List:

code_ISO639: 0x656e
encoding:
0x6a
base_offset: 0x100
Service Name: Public Browse Group Root
Service Description: Root of public browse hierarchy
Service Provider: BlueZ
Service RecHandle: 0x804d050
Service Class ID List:
"Browse Group Descriptor" (0x1001)
Language Base Attr List:
code_ISO639: 0x656e
encoding:
0x6a
base_offset: 0x100
Service Name: Museum Service
Service Description: Electronic Museum guide service
Service Provider: BeremoTe
Service RecHandle: 0x804d6d0
Service Class ID List:
"" (0x1fff)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 5

B.3

pstree -H beremote output

Output from a pstree -H beremote command, showing our child spawning of our
parent process of beremote. Thus showing a incoming connection.
[init[-+-atd
|-bash---pstree
|-[bash[---[beremote[---beremote
|-bash---tail
|-bdflush
|-cardmgr
|-cron
|-dbus-daemon-1
|-dhclient-2.2.x
|-3*[getty]

82

|-hcid
|-inetd
|-keventd
|-khubd
|-klogd
|-krfcommd
|-ksoftirqd_CPU0
|-kswapd
|-kupdated
|-lpd
|-portmap
|-rpc.statd
|-sdpd
|-sshd---sshd---sshd-+-bash
|
-sftp-server
|-syslogd
-xfs

83