Improved Performance of Bluetooth with Focus on Ad ... - DiVA portal

Improved Performance of Bluetooth with Focus on Ad-Hoc Applications Lennart Isaksson

Karlskrona, December 2004, Department of Telecommunication Systems, School of Engineering, Blekinge Institute of Technology, S-371 79 Karlskrona, Sweden

c 2004 by Lennart Isaksson. All rights reserved. Licentiate Dissertation Series No. 2004:10 ISSN 1650-2140 ISBN 91-7295-047-1 Published 2004 Printed by Kaserntryckeriet AB Karlskrona 2004 Sweden This publication was typeset using LATEX.

To my family

v

Abstract The number of devices making use of Bluetooth cable-replacement technology has rapidly increased in numbers thanks to the amount of implementations in cellular telephones, Personal Digital Assistants (PDAs), etc. Instead of the point-to-point technique used today the wireless community demands more sophisticated solutions to transmit information between two devices, e.g. using a chat program within an ad-hoc network. However, Bluetooth provides neither a routing protocol, nor is the slave/slave bridge, which is an important enabler for point-to-multipoint communication in so-called scatternets, implemented in hardware. Another issue relates to the time-to-connect which determines the usability of Bluetooth in scenarios where the units move around. In order to build research on these topics on trustworthy ground, we first address the validation of a Bluetooth simulation model, implementing the Frequency Hopping Spread Spectrum (FHSS) technique of Bluetooth version 1.1 in a correct way. A potential source of problems in reference simulation models has been identified and corrections are described. Next, an improvement is presented for the pseudo random hop sequence regarding the distribution of frequencies used in the Adapted Channel Hopping (ACH) scheme for Bluetooth version 1.2. Further, the impact of the random backoff boundary, which determines the duration of the inquiry procedure and thus of the time-to-connect, is studied by simulation. Obviously, the settings of this parameter contained in the specification leads to suboptimal behaviour. In this thesis, a lower random backoff boundary parameter is suggested, which yields much faster time-to-connect. Finally, the Modified Reverse Path Forwarding (MRPF) routing algorithm for Bluetooth is proposed. This algorithm reduces the amount of connections needed to transmit Asynchronous Connection Less (ACL) data packets as compared to the standard RPF, at the cost of additional overhead. Altogether, especially with the proposed improvements of Bluetooth performance, this technology can be considered to be well suited for nomadic scenarios.

vii

Preface This thesis consists of research in the area of low-rate wireless techniques such as Bluetooth. The work was done at the School of Engineering at Blekinge Institute of Technology. Parts of my research material have been published in the following papers.

L. Isaksson, M. Fiedler and Arne A. Nilsson, Validation of Simulations of Bluetooth’s Frequency Hopping Spread Spectrum Technique, in Proceedings of the 2004 Design, Analysis, and Simulation of Distributed Systems, pp. 156-165, Arlington, Virginia, USA. L. Isaksson and M. Fiedler, Optimization of the Random Backoff Boundary of the Frequency Hopping Spread Spectrum Technique of Bluetooth, COST 279 Technical Document 279 TD(04)027, 11th Management Committee Meeting 2004, Ghent, Belgium. L. Isaksson and M. Fiedler, On-Demand Ad-Hoc Routing with Modified Reverse Path Forwarding for Bluetooth, in Proceedings of the 2004 Australian Telecommunication Networks and Applications Conference (ATNAC 2004), Sydney, Australia.

ix

Acknowledgements First, I would like to thank my examiner, Professor Arne A. Nilsson, at Blekinge Institute of Technology for giving me the opportunity to learn more because this has become a dedication in my life. Second, I would like to thank my advisor Dr. Markus Fiedler for very long and interesting discussions during this period. Third, my gratitude’s goes to my colleagues in the telecommunication group for assistance and support during this period. The group consists of Docent Adrian Popescu, Doru Constantinescu, Henric Johnson, David Erman, Dragos Ilie, Patrik Carlsson, and Stefan Schevul. Further, the author wishes to thank Agneta Abrahamsson, Petra Lundberg, Patrik Nilsson and Henrik Possung, students at Blekinge Institute of Technology, for their contribution to different works regarding the Bluetooth simulator described in this thesis. Finally, a special thanks to my wife Carina and my son Fabian.

Lennart Isaksson Karlskrona, December 2004

Contents 1 Introduction 17 1.1 Background and Motivation . . . . . . . . . . . . . . . . . . . . 17 1.2 Thesis Definition and Scope . . . . . . . . . . . . . . . . . . . . 20 1.3 Thesis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2 Some Bluetooth Basics 2.1 Notations . . . . . . . . . . . 2.2 Timing . . . . . . . . . . . . . 2.3 Inquiry, Page and Connection 2.4 Frequency Hopping . . . . . . 2.5 Piconet . . . . . . . . . . . . 2.6 Scatternet . . . . . . . . . . . 2.7 Adapted Frequency Hopping 2.8 Bluetooth Versions . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

23 23 24 24 29 34 35 37 39

3 State-of-the-Art of Bluetooth-related Research 3.1 Scatternet Formation . . . . . . . . . . . . . . . . 3.2 Analysis and Simulation . . . . . . . . . . . . . . 3.3 Coexistence with IEEE 802.11b . . . . . . . . . . 3.4 Discussion . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

41 41 44 45 47

4 Validation of Simulations of Bluetooth’s FHSS Technique 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 The simulation process . . . . . . . . . . . . . . . . . . 4.2.2 Implementation of the process . . . . . . . . . . . . . 4.3 Empirical Analysis of the Inquiry Procedure . . . . . . . . . .

. . . . .

49 49 51 51 53 54

. . . . . . . . . . . . Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

xii . . . . . . . . .

54 56 56 56 60 61 63 64 66

Version 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67 67 68 68 69

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

73 73 73 74 75 75 80

7 Message Routing Protocol (MRP) for Bluetooth 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 7.2 Neighbour Discovery and Time-to-Connect . . . . 7.3 Routing and Protocol . . . . . . . . . . . . . . . . 7.4 Conclusions and Outlook . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

81 81 82 83 89

4.4 4.5 4.6 4.7 4.8 4.9

4.3.1 Measurement Setup . . . . . . . . . . . . . . . 4.3.2 Bluetooth Commands . . . . . . . . . . . . . . 4.3.3 Limitations . . . . . . . . . . . . . . . . . . . . Confidence Analysis . . . . . . . . . . . . . . . . . . . Individual Distribution Identification . . . . . . . . . . Time Measurement for Inquiry, Page and Connection . Software Analysis . . . . . . . . . . . . . . . . . . . . . Documentation of the State Machine . . . . . . . . . . Conclusions and Outlook . . . . . . . . . . . . . . . .

5 Improved Frequency Distribution 5.1 Introduction . . . . . . . . . . . . 5.2 Original AFH . . . . . . . . . . . 5.3 Improvement of AFH . . . . . . . 5.4 Results and Discussion . . . . . .

for . . . . . . . .

Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Improved Time-to-Connect 6.1 Introduction . . . . . . . . . . . . . . . . . . . 6.2 Simulation of the Random Backoff Parameter 6.3 Simulation Setup . . . . . . . . . . . . . . . . 6.4 Results from the static simulations . . . . . . 6.5 Simulation of the Inquiry Procedure . . . . . 6.6 Conclusions and Outlook . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

8 Conclusions and Outlook

91

Bibliography

93

Index

99

List of Figures 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9

State machine of the inquiry procedure. . . . . . . . . . . . . . State machine of the page and connection procedure. . . . . . . Register bank, 79-frequency system (23) [1]. . . . . . . . . . . . Selection box, 79-frequency system [1]. . . . . . . . . . . . . . . Piconets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bluetooth packet pairs (M=Master, S=Slave). . . . . . . . . . . Scatternet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Block diagram of Basic and Adapted Frequency Hopping Scheme [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adapted Frequency Hopping Scheme histogram, 50 channels. .

3.1 3.2

Piconet and Scatternet Topology Models [3]. . . . . . . . . . . 43 IEEE 802.15.1 (FHSS) vs. IEEE 802.11b (DSSS). . . . . . . . . 45

4.1 4.2 4.3 4.4 4.5 4.6 4.7

Verification and validation scheme. . . . . . . . . . . . . . . . . Bluetooth setup for empirical data measurements. . . . . . . . Inquiry times obtained from the Ericsson Bluetooth Starter Kit. Inquiry times obtained from our own simulator model. . . . . . Inquiry times obtained from the simulator RIBBIT version 1.0 [4]. Interval and Box Plot for C1, C2, C3, and C4. . . . . . . . . . Histogram for the time elapsed from Standby to the end of inquiry, page and connection procedure (validated simulations).

5.1 5.2

Channel selection histograms schemes, 20 channels. . . . . . Channel selection histograms schemes, 50 channels. . . . . .

for . . for . .

xiii

different . . . . . different . . . . .

frequency . . . . . . frequency . . . . . .

26 28 29 34 35 36 37 38 39

51 54 57 58 59 60 62

hopping . . . . . . 70 hopping . . . . . . 70

xiv 5.3

Channel selection histograms for different frequency hopping schemes, 70 channels. . . . . . . . . . . . . . . . . . . . . . . . . 71

6.1 6.2

Simulation steps for the backoff parameter. . . . . . . . . . . . Batch 1: Simulation of the inquiry time using a static backoff parameter between 0 and 1023 slot. . . . . . . . . . . . . . . . . Batch 2: Simulation of the inquiry time using a static backoff parameter between 0 and 1023 slot. . . . . . . . . . . . . . . . . Inquiry time with all simulation results, based on 72,000 simulation values (Figures 6.2 and 6.3 included). . . . . . . . . . . . Maximum inquiry time with different max random backoff boundary values of 1023, 912, and 896 slots. . . . . . . . . . . . . . .

6.3 6.4 6.5 7.1 7.2 7.3 7.4 7.5 7.6

Reverse Path Forwarding (RPF). . . . . . . . . . . . . . . . . . Modified Reverse Path Forwarding (MRPF). . . . . . . . . . . Examples of a scatternet using the Modified RPF for Bluetooth. Routing diagram based on the Modified Reverse Path Forwarding algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modified Reverse Path Forwarding Protocol. . . . . . . . . . . Modified Reverse Path Forwarding Algorithm for Bluetooth. . .

74 76 77 78 79 84 84 85 86 87 88

List of Tables 2.1 2.2 2.3

Parameters used in the simulation model. . . . . . . . . . . . . 25 Sequence from the Atrain . . . . . . . . . . . . . . . . . . . . . . 31 Sequence from the Btrain . . . . . . . . . . . . . . . . . . . . . . 33

3.1 3.2

Hopping rate in IEEE 802.11 FHSS. . . . . . . . . . . . . . . . 47 Packet type size vs. slot size. . . . . . . . . . . . . . . . . . . . 48

4.1

4.4 4.5

Command packets sent and event packets received from master device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-sample t. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mean value of times for inquiry, page and connection procedures based on 50,000 samples. . . . . . . . . . . . . . . . . . . Initialization parameters for the selection box. . . . . . . . . . . State machine table with sample data. . . . . . . . . . . . . . .

6.1

Inquiry times for different random backoff boundary values. . . 80

7.1 7.2

Payload of Bluetooth ACL packets. . . . . . . . . . . . . . . . . 87 Overhead and remaining payload in case of DM3 packets. . . . 89

4.2 4.3

xv

55 61 61 65 65

Chapter 1

Introduction 1.1

Background and Motivation

The number of devices making use of Bluetooth technology has rapidly increased thanks to the amount of implementations in different types of small devices. Bluetooth (IEEE 802.15.1) has a set of interesting possibilities. One is the ability to send and receive data and/or speech with hardly any disturbances using the Frequency Hopping Spread Spectrum (FHSS) technique. Especially in a heavy industrial environment with lots of signal disturbances, Bluetooth works perfectly thanks to the FHSS technique. The FHSS technique avoids disturbance by using pseudo-random jumps between frequencies over the spectrum of 2.402–2.480 GHz. Another advantage is the resistance to undesirable propagation conditions. FHSS together with error correction could also allow for more users than the number of available frequencies even though the probability of a collision will increase. Still, the error correction coding could recover the transmitted packet. Other secure techniques used by Bluetooth are the ability to have a secure channel based on authorization, authentication or encryption, and the ability to provide a particular service featured by the Service Discovery Protocol (SDP). Furthermore, Bluetooth has the potential of creating point-to-point or point-to-multipoint connections in order to create smaller ad-hoc networks, so-called piconets. A disadvantage with Bluetooth is the absence of a routing protocol. Another one is the poor behaviour when creating a scatternet using the slave/slave bridge. Our indications show that the slave/slave bridge is not implemented 17

18

Chapter 1

by hardware manufacturers. Therefore, in this thesis a simple routing protocol, called Modified Reverse Path Forwarding (MRPF), at the application layer is presented. The intention is to use a simple routing protocol with a known routing algorithm to exchange data between two or more devices in an on-demand ad-hoc network. This protocol uses one connection per message in order to avoid blocking of nodes. However, before going into a deeper discussion regarding a Bluetooth adhoc network, we have to investigate the possibility of decreasing the timeto-connect, which is currently a significant issue in creating an on-demand ad-hoc network for Bluetooth. Another motivation for reducing the time-to-connect is when two or several moving devices are expected to exchange data between each other. Bluetooth is using single-hop in small ad-hoc networks like piconets or multi-hop in scatternet. The time these devices are in range of each other can be quite small, e.g. a few seconds. That is why it is crucial to have a technique that allows one to make a connection fast to be able to exchange data between the devices. Regarding Bluetooth, the time-to-connect may be as high as 10.24 s for the inquiry procedure and 2.56 s for the connection procedure according to the Bluetooth specification [1]. In some scenarios this is by far not fast enough. The total time-to-connect depends also on the application and the operating system used. One part of the motivation for this thesis is to find a way to decrease the time-to-connect in such a way that makes it possible to reach even lower time-to-connect values, suitable for highly movable devices. The very candidate for optimization is Bluetooth’s baseband layer, as it hosts the selection box and state machine used for calculating the pseudo-random frequencies that different Bluetooth units use for finding each other. In other words, the baseband layer is responsible for how efficient the time-to-connect will be. Optimization of the time-to-connect behaviour of Bluetooth requires an in-depth knowledge of its FHSS technique. One good way to understand that concept and its inner nature consists in investigating and even creating detailed simulation models. However, the design of a simulation model has to be validated and its implementation must be verified in order to grant credibility and trustworthiness for the results. This implies that the output of available and self-designed simulation tools have to be compared against each other, and as far as possible against the specification and Bluetooth hardware. The latter is especially important, as the validation of the Bluetooth state machine is much harder to derive than that of the selection box. A thorough study of these issues, including a validated simulation model and work-arounds

Introduction

19

for existing simulation software is presented [5]. A good way to understand the concept of FHSS and its behaviour is to undertake the task of creating a simulation model and to understand the inner nature of the technique. The simulation model presented in this thesis can be tested against other simulation models available from the Internet. “If a model is not valid, then any conclusions derived from the model will be of doubtful value.” [6]. Before any study of data from a simulation model can be performed, one has to make sure that is accurate and trustworthiness is established. Thus, one issue of concern arises when evaluating performance data is derived from a simulation model: Is the simulation model correct? Can the results from the simulation be trusted? Are they fairly accurate? These questions are important because if the simulation model is wrong, all simulations derived from it may not be trustworthy. During a verification and validation of a simulation program it is important to use different techniques to establish a credible model. When more techniques are used, and results match, the simulation model in question is more credible. The validation of the Bluetooth state machine is much harder to derive because it is not measurable in exact values as in the selection box. Thus, by using a hardware device of some kind and by statistics states the behaviour between the two of them is feasible. This work was presented in [5]. Using the validated and verified simulation tool presented in [5], a study on how to reduce the time-to-connect was carried out. Two steps are used to reach a connection. Step one is the inquiry procedure and step two contains the page and connection procedure. As step one gives greater contribution to the time-to-connect, the investigations focused on the inquiry procedure. This work was presented in [7]. Finally, in an ad-hoc multi-hop scenario, all devices need to form some kind of scatternet to transmit their information. The main idea is to use an already known algorithm and modify it so as to make it suitable for Bluetooth routing. Bluetooth has no routing protocol and for that reason the Reverse Path Forwarding (RPF) [8] algorithm was chosen because of its simplicity to implement. The original RPF algorithm was modified to imitate the Extended RPF (ERPF) [8] and is called the Modified RPF (MRPF) algorithm. The main task of the ERPF algorithm is to periodically exchange routing information between the nodes. The main task of the MRPF algorithm is

20

Chapter 1

to incorporate the routing information into the same packet as the message itself. The MRPF algorithm reduces the amount of connections compared to the original RPF algorithm. This work was presented in [9].

1.2

Thesis Definition and Scope

Credible simulation model. The objectives of this work starts with a settlement of a trustworthy simulation model based on Bluetooth’s FHSS technique. This research is a foundation for the next steps to come. Improve the time-to-connect. The next step contains improvements regarding time-to-connect. First, it is determined which of the procedure inquiry, page and connection need most time during connection establishment. Then, this particular procedure is optimized. Efficient ad-hoc routing algorithm. Finally, partly based on previously developed knowledge, an efficient ad-hoc routing algorithm suitable for Bluetooth is developed. Consequently Chapter 3 is devoted to create a validated Bluetooth simulation model. In Chapter 6 this validated model is later on used in different simulations to reduce and optimize the time-to-connect between two Bluetooth devices. These results are later used in ad-hoc networking situations to motivate the use of Bluetooth in different scenarios which is described in Chapter 7.

1.3

Thesis Overview

Chapter 2, Some Bluetooth Basics. The chapter is devoted to the inner part of Bluetooth. A description of how FHSS is working is given. The inner part of the FH is described, which is the selection box. Especially the three steps to reach a connection between two devices, namely inquiry, page and connection, are described in detail. Next a description of the Adapted Frequency Hopping (AFH) in version 1.2 is given. Finally, the different versions of Bluetooth and important improvements are described. Chapter 3, State-of-the-Art of Bluetooth-related Research. In this chapter, a contemporary view on research activities in the Bluetooth contest is given. The latest in scatternet and ad-hoc formation together with

Introduction

21

different analytical and simulation studies is provided. Also, simulation studies for the data- and voice channel together with the coexistence of IEEE 802.11b are presented. Chapter 4, Validation of Simulations of Bluetooth’s FHSS Technique. In this chapter a description regarding validation of a simulation model using the Bluetooth FHSS technique is provided. Different simulation models were compared with our own simulation model and a hardware device. Results of time measurements of the inquiry, page and connection procedure are presented. A software analysis and corrections of a few simulation models available from Internet is also provided. Finally a method to verify the state machine is described and discussed. Chapter 5, Improved Frequency Distribution for Bluetooth version 1.2. In this chapter an improvement of the distribution of the frequencies used by Bluetooth version 1.2 is given. Chapter 6, Improved Time-to-Connect. In this chapter, a possibility to yield improved time-to-connect by optimisation of the random backoff parameter is described. Our simulations indicate some poor time-to-connect values and in some cases, no connection is established at all. After several simulations with systematic variations of the backoff boundary, an optimized value is found and presented. Chapter 7, Message Routing Protocol (MRP) for Bluetooth. The chapter presents a Message Routing Protocol (MRP) for Bluetooth. Some indications regarding poor behaviour creating scatternet motivates the development of a simple routing algorithm for Bluetooth. A well-known routing algorithm is used and modified. Chapter 8, Conclusions and Outlook. The chapter starts with a summary of the thesis and continues with a discussion of future work.

Chapter 2

Some Bluetooth Basics This chapter is necessary in order to ”understand” the remainder of this work. A short introduction on the operation of Bluetooth version 1.1 [1] is given. A thorough explanation of the inquiry, page and connection procedures is presented. Finally, the operation of the selection box is described. This section is an extension of paper [5].

2.1

Notations

The selection box, which derives the proper channel used in the Frequency Hopping Spread Spectrum (FHSS), depends on a number of input parameters. One of the parameters is based on the state machine’s substate. Each substate is represented by an unique algorithm which is denoted Z. The size of Z is presented in bits which are denoted a, b and/or c. The notation Za−b (,c) refers to which bit a to b (and/or bit c) are produced by the algorithm. In the following, the input X determines the phase which is a set of frequencies used based on the clock, (Tables 2.2 and 2.3). The inputs Y1 and Y2 switch between master-to-slave and slave-to-master transmission. The inputs A to F, derived from different parts of the Bluetooth address, determine the ordering within the sub-states. The variable koffset is used to toggle between the Atrain and Btrain (Equation 2.3). A train consist of 32 different channels. Each train uses different sets of channels to look for new devices for a preset number of times before 23

24

Chapter 2

using the other set of channels. For more explanations regarding the train, see Section 2.4.

2.2

Timing

Every Bluetooth device has a free running 28 bit clock and increments it every 312.5 µs. This clock is referred to as Clock Native (CLKN). A master device is responsible for the timebase in a piconet and this is referred to as Clock (CLK). An offset used to calculate the difference between a slave and a piconet is referred to as Master Clock Offset (MCO). A master device estimates the time difference to a slave in the page procedure and this is referred to as Clock Estimated (CLKE). An offset used to calculate the difference is referred to as Slave Estimate Clock Offset (SECO).

2.3

Inquiry, Page and Connection Procedure

Before one can use an ad-hoc network with Bluetooth devices, one or several connections must be established. This is done by using an inquiry, page and connection procedure to establish a connection between two or several Bluetooth devices (Figures 2.1 and 2.2). Inquiry Procedure. The master device is in inquiry substate when trying to send over an Identity or ID (ID1) packet (68 bits) to the slave device (Figure 2.1). The slave device is in the inquiry scan substate. In that substate the slave device is listening, but only during a time window of at least 11.25 ms (Table 2.1). When the first ID packet arrives, the slave device goes into a random backoff period uniformly distributed between 0–1023 slots, used for collision avoidance. The slave device wakes up from the random backoff period and goes into the inquiry scan for the second time. The random backoff parameter will be studied in detail in Chapter 6. There is a time limit to consider (inqrespTO). When this time limit is reached the process goes back to Standby state. When the second ID (ID2) packet arrives, the slave device goes into inquiry response substate exactly one slot later (625 µs). If the ID packet does not arrive in time, a timer is triggered and the slave device goes back to the Standby state. In inquiry response substate, the slave device sends an Frequency Hop Synchronisation (FHS) packet to the master device with information about the

Some Bluetooth Basics

25

Table 2.1: Parameters used in the simulation model.

Inquiry

Page

Connection

Parameter

Value

inquiryTO

20 s

inqrespTO

2.56 s

T inquiry scan

1.28 s

Tw inquiry scan

11.25 ms

Random backoff

0 – 640 ms

N inquiry

256

pageTO

2.56 s

pagerespTO

5 ms

T page scan

2.56 s

Tw page scan

11.25 ms

N page

128

newconnectionTO

20 ms

26

Chapter 2

Figure 2.1: State machine of the inquiry procedure.


27

slave, e.g. the Non-significant Address Part (NAP) of Bluetooth Device Address (BD ADDR)47−32 , Upper Address Part (UAP) BD ADDR31−24 , Lower Address Part (LAP) BD ADDR23−0 and CLK27−2 . The Master’s Device Access Code (DAC) is used for the synchronization of its lower part of the time, CLK1−0 . The slave device only tries to send the FHS packet once, goes back to the first inquiry scan substate and starts all over again. At the same time the counter N ir is increased by one. The master device has a time limit to consider (inquiryTO). If the master device obtains the FHS packet from the slave device, it uses the slave’s address by using DAC instead of the General Inquiry Access Code (GIAC). GIAC is used only during the inquiry substate because of the lack of knowledge about the potential slave of this point in time. DAC is used during the page substate dedicated to a known device. Page Procedure. When the master device has sufficient information (FHS packets from the slave device), it continues by sending a DAC (ID1) packet in the page substate using the slaves Bluetooth address and a SECO (Figure 2.2). The slave device recognizes its address when the DAC packet has arrived, and goes into the next substate which is the page response substate. At the same time, a part CLK16−12 of the clock is frozen. In this substate, there is also a time out period (pagerespTO). When this time limit is reached the process goes back to the Standby state. The value of N prs, used by the slave device for synchronization, is increased by one. This is conducted every time CKLN1 is set to zero. The master device has a time limit to consider (pageTO). In the page scan substate, the slave device is listening only during a time window of at least 11.25 ms (Table 2.1). In the page response slave substate, the device is trying to send over an ID (ID2) packet to the master device. When the master device has received the ID packet, it goes into the page master response substate. At the same time, a part of the clock and the parameter koffset are frozen (Equations 2.5 and 2.6). In the page master response substate, the device is trying to send over an FHS packet to the slave device. When the slave device has sufficient information (FHS packets from the master device), it continues by sending an DAC (ID3) packet using the master’s Bluetooth address and a MCO. The value of N prm, used by the master device for synchronization, is increased by one. This is conducted every time CKLN1 is set to zero. Both master and slave device have a time limit to consider (pagerespTO). When this time limit is reached the program goes back to the page substate for the master and page scan substate for the slave.

28

Chapter 2

Figure 2.2: State machine of the page and connection procedure.


29

Figure 2.3: Register bank, 79-frequency system (23) [1]. Connection Procedure. Finally, after having sent the ID (ID3) packet the slave device goes into the connection state and waits for the POLL packet to arrive from the master device (Figure 2.2). When the master device has received the ID (ID3) packet, it enters the connection state and sends a POLL packet to the slave device. An acknowledgment from the slave device is conducted by sending a NULL packet. When the master device has received the packet, a connection is established. In the connection state there is a time limit of 32 slots in case something goes wrong, e.g. POLL or NULL packets collide during the connection phase. Both master and slave device have a time limit to consider (newconnectionTO). In the connection state, a sliding technique is used to ensure the data transfer. If somebody tries to jam the communication on certain frequencies between the connected devices on several channels, the sliding technique assures the communication anyway. The frequency is changing every 0.04 s according to bit 7 in CLK27−7 (Figure 2.3 column F).

2.4

Frequency Hopping

The Bluetooth device is using the 79-frequency system in Europe and in the US. It only uses 32 hop frequencies for scanning and 32 hop frequencies for response, spanning 64 MHz (Figure 2.3). This covers approximately 81 % of the frequencies [1]. Two states Standby and Connection and seven substates inquiry, inquiry scan, inquiry response, page, page scan, page master response and page slave response are depending on four variables in order to calculate the next fre-

30

Chapter 2

quency. The first variable is a selection of the 23- or 79-frequency mode (where the number indicates how many frequencies are used). The second variable is the address-variable BD ADDR27−0 . The third one is based on clock CLKN, CLK or CLKE. The fourth variable is regarding the number of times each train of frequencies Atrain and Btrain should be used before alternating between them. These trains are groups of frequencies to be visited in a predefined order. Equations 2.1 and 2.2 produce a sequence of numbers to form the contents of the Atrain and Btrain depending on koffset . Phase 0 in the Atrain includes the frequencies f (k − 8) . . . f (k) . . . f (k + 7) and the phase 0 in Btrain includes the frequencies f (k + 8) . . . f (k + 15), f (k − 16) . . . f (k − 9) (Tables 2.2 and 2.3). Corresponding entries for the Btrain are obtained by adding 16 and taking the result modulo 32. For the Atrain , phase 0 consists of the following sequence of numbers: 24, 25, 24, 25, 26, 27, 26, 27 · · · 6, 7, 6, 7. For the Btrain , phase 0 consists of the following sequence of numbers: 8, 9, 8, 9, 10, 11, 10, 11 · · · 22, 23, 22, 23. Every train must be repeated Ninquiry = 2561 times (Npage = 128) and takes a time interval of 0.3125 ms/freq · 32 freq = 10 ms to be transmitted. In total, there is a period of 256 · 10 ms = 2.56 s for each type of train for the inquiry procedure and 128 · 10 ms = 1.28 s for each type of train for the page procedure. Consequently, only two complete phases or partly three phases are used before changing to another train, and this depends on the starting point.

1 When validating the selection box against the specification, one should always use Ninquiry = 128.


31

Table 2.2: Sequence from the Atrain . Phase

0

···

7

8

···

14

15

0

24

1 .. .

8 .. . .. . .. . .. . .. . .. .

··· .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .

31 .. . .. .

0 .. . .. . .. .

··· .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .

6 .. . .. . .. . .. . .. .

7 .. . .. . .. . .. . .. . .. .

8 9 .. . 15 16 17 .. . 24 25 .. . 31

24 .. . .. . .. . .. . .. .

15 .. . .. . .. . .. . .. . .. . 31 .. . .. . .. .

16 .. . .. . .. . .. . .. . .. . 0 .. . .. .

22 .. . .. . .. . .. . .. . .. . 6

23 .. . .. . .. . .. . .. . .. .

32

Chapter 2

Equation 2.1 is valid for the inquiry (i) mode, while Equation 2.2 addresses the page (p) mode (Figure 2.4). Equation 2.4 is valid for both inquiry scan and inquiry response (ir) modes. Equation 2.5 addresses the page response master (prm) mode. Equation 2.6 addresses the page response slave (prs) mode (Figure 2.4). In some conditions the values must be kept constant even though the internal clock is ticking, which is indicated with an asterisk (∗), in Equations 2.5 and 2.6. The counter N is increased by one each time a FHS packet is sent (Equation 2.4) and each time CLKN1 or CLKE1 is set to zero (Equations 2.5 and 2.6). (79)

Xi4−0 = [CLKN16−12 + koffset + (CLKN4−2,0 − CLKN16−12 ) mod 16] mod 32 (79)

Xp4−0 = [CLKE16−12 + koffset +

(2.1)

(2.2)

(CLKE4−2,0 − CLKE16−12 ) mod 16] mod 32 koffset =

24 8

for Atrain for Btrain

(79)

Xir4−0 = [CLKN16−12 + N] mod 32 (79)

∗ + Xprm4−0 = [CLKE∗16−12 + koffset ∗ ∗ (CLKE4−2,0 − CLKE16−12 ) mod 16 + N] mod 32

(79)

Xprs4−0 = [CLKN∗16−12 + N] mod 32

(2.3)

(2.4)

(2.5)

(2.6)

Inquiry, inquiry scan, and inquiry response substates (Figure 2.1) use different algorithms to generate the frequency. In particular, for the inquiry scan and inquiry response algorithms, the input Y 1 is toggled between 0x00000 for receiving mode (Inquiry scan substate) and 0x11111 for sending mode (Inquiry response substate). So, the sequence 24, 25, 24, 25, · · · becomes 48, 50, 09, 13 when using CLKE = 0x0000000 and ULAP = 0x00000000 (UAP3−0 and LAP23−0 put together).


33

Table 2.3: Sequence from the Btrain . Phase

0

···

7

8

···

14

15

0

8

1 .. .

24 .. . .. . .. . .. . .. . .. .

··· .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .

15 .. . .. .

16 .. . .. . .. .

··· .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .

22 .. . .. . .. . .. . .. .

23 .. . .. . .. . .. . .. . .. .

8 9 .. . 15 16 17 .. . 24 25 .. . 31

8 .. . .. . .. . .. . .. .

31 .. . .. . .. . .. . .. . .. . 15 .. . .. . .. .

0 .. . .. . .. . .. . .. . .. . 16 .. . .. .

6 .. . .. . .. . .. . .. . .. . 22

7 .. . .. . .. . .. . .. . .. .

34

Chapter 2

Figure 2.4: Selection box, 79-frequency system [1]. Finally, after having performed several steps in the selection box, a subfrequency-to-frequency conversion is made. The proper way is to convert the derived frequency according to the algorithms presented in [1] (Figure 2.4). The subfrequency-to-frequency vector is created by first listing all even numbers starting with frequency 0 and ending with frequency 78. Finally, all odd numbers are added to the vector starting with frequency 1 and ending with frequency 77. All seven substates inquiry, inquiry scan, inquiry response, page, page scan, page response slave and page response master and connection state (five tables of data) have been validated and verified against the specification, see Section 2 in the specification [1]. For the inquiry response substate, a table in the specification is missing. This should match the inquiry and inquiry response submode. One way to validate and verify the proper frequency and channel is to look at the inquiry table. The slot for receive is matched towards the one for inquiry response and the slot for transmit is matched towards the one for inquiry scan, respectively.

2.5

Piconet

The smallest ad-hoc network possible is a piconet with only one master and one slave (Figure 2.5 (a)). The largest piconet consists of maximum of seven active slaves (Figure 2.5 (b)). The reason for this is the Active Member Address (AM ADDR) is restricted to 3 bits (1 broadcast address and 7 slaves). In a piconet with an established connection, different constellations of packets are possible. Each master and slave is paired, and they can use con-


(a) Piconet 1

(b) Piconet 2

35

(c) Piconet 3

Figure 2.5: Piconets.

figurations of 2, 4, 6, 8, or 10 slots to send packets to each other (Figure 2.6 (a–i)).

2.6

Scatternet

Supporting more than seven slaves in a piconet is possible only if the rest of the slaves are in parked mode. This is done by using the Parked Member Address (PM ADDR). This address is restricted to 8 bits (1 broadcast address and 255 slaves). So, when a device, in parked mode, wants to communicate with the master, a slave in active mode has to step down from active mode (if there are already seven actives slaves) to change place with the device in parked mode. An ad-hoc network is useful for establishing a wireless network where a wired infrastructure does not exist. A Bluetooth wireless network is based upon several piconets to form a scatternet (Figure 2.7). There are no limitations on how large a scatternet can be in theory. Practically this is not entirely true. A problem arises when data is sent through the nodes in a scatternet, because different piconets have different time bases. The reason for this is that each piconet has a different time base. A Bluetooth device must then maintain more than one time base. To assure collision-free data transfer

36

Chapter 2

(a)

(b)

(e)

(c)

(d)

(f)

(h)

(g)

(i)

Figure 2.6: Bluetooth packet pairs (M=Master, S=Slave).


37

through a scatternet, some guard slots have to be excluded to eliminate the possibility that data passing through the scatternet interfered with data within the respective piconet. There is also another problem. The slave/slave bridge in a scatternet is not implemented by the hardware manufacturer according to our findings.

Figure 2.7: Scatternet.

2.7

Adapted Frequency Hopping

The latest version of the specification 1.2 [2] includes an extended version of the frequency hopping. In this Section the Adapted Frequency Hopping (AFH) is presented. The difference between the two versions of the specifications 1.1 and 1.2, regarding input parameters, is that the 23- and 79-frequency switch is removed. This is not needed any longer because of the Channel Map (CM). With the channel map there is a possibility to choose all combinations of channels between Nmin ≤ N ≤ 79 instead of only two. The minimum number of channels is Nmin = 20.

38

Chapter 2

Basically, the selection box is extended to handle two situations (Figure 2.8). If the derived frequencies match the AFH channel map, which is based on the allowed frequencies used in the selection box, the frequency is derived as before and becomes fk (Equations 2.7, 2.8 and 2.9). F = k =

MODULO(16 · CLKN27−7 , 79) ADD mod79(PERM5out , E, F, Y2)

(2.7) (2.8)

fk

RegisterBank79[k]

(2.9)

=

Figure 2.8: Block diagram of Basic and Adapted Frequency Hopping Scheme [2]. If not, a remapping of the frequencies must be done. This involves a recalculation of the last step in the selection box with a Mapping Table (MT) with allowed frequencies, and the frequency becomes fk . Equations 2.10, 2.11 and 2.12 are used to derive the proper frequency if recalculation is needed. The parameters P ERM 5out , E, and Y 2 are the same as before. The parameter N is the number of channels. A histogram of the frequencies used are plotted together with 50 channels (632 samples) to illustrate the AFH (Figure 2.9). As one can see from the figure, the frequencies are not uniformly distributed.


39

Adapted Frequency Hopping 70

Number of samples

60 50 40 30 20 10 0

0

10

20

30

40 Channels

50

60

70

Figure 2.9: Adapted Frequency Hopping Scheme histogram, 50 channels.

F

k fk

2.8

=

MODULO(16 · CLKN27−7 , N)

(2.10)

=

ADD Mod N(PERM5out , E, F , Y2, N)

(2.11)

=

Mapping Table[k ]

(2.12)

Bluetooth Versions

Version 1.1. An article in [10] stated the significant change from the version 1.0b to 1.1 to be the authentication. With the version 1.0b this didn’t work properly. During an initial link negotiation the two devices could be out of sync with the results of no connection. The key problem is that both devices must generate exactly the same encryption key, but in this case they didn’t. This is corrected in version 1.1. The Gaussian Frequency Shift Keying (GFSK) modulation is used and its throughput is 1 Mbps on the physical layer which gives a transmition rate of 721 Kbps. Version 1.2. The main three improvements in version 1.2 are the AFH, faster connections and extended synchronous connection-oriented technology

40

Chapter 2

(voice) [11]. A small adjustment inside the state connection is also carried out. The change of the channel/frequency is carried out every second slot instead of every slot. Version 1.2 Enhanced Data Rate. According to [12] the transmition rate will increase up to 2.1 Mbps. The new technique is called Enhanced Data Rate (EDR). The increased data rate reduces the amount of time spent in the air. The Differential Quadrature Phase-Shift Keying (DQPSK) and EightDifferential Quadrature Phase-Shift Keying (8DQPSK) modulation makes the 3 Mbps on the physical layer possible compared to the current GFSK modulation yielding 1 Mbps.

Chapter 3

State-of-the-Art of Bluetooth-related Research This chapter gives an overview of the concurrent topics in Bluetooth-related research and relevant results of today. It also compares the Bluetooth technology to the competitive Wireless Local Area Networks (WLAN) standard IEEE 802.11b.

3.1

Scatternet Formation

Zhang et al. [13] presents a scatternet formation algorithms, called Loop Scatternet Formation (LSF). The LSF is divided into two phases. First, all devices are connected together into a piconet with at most k − 1 (k ≤ 7) slaves. These piconets are then connected into a ring formation. Second, one node from each piconet is selected to connect to each other via a slave/slave bridge. All piconets are then acting as a scatternet. Law et al. [14, 15] presented a two layer approach to a scatternet formation algorithm. First, they conducted a simulation to see the behaviour of the adhoc network formation in a scatternet. Secondly a subroutine was developed to efficiently discover other nodes. One constraint using this algorithm is that all devices must be in range. Two types of complexity are considered, time and message. The proposed algorithm produces a small number of piconets which minimizes the piconet interference. 41

42

Chapter 3

There are several research papers in ad-hoc networking; a summary is found in Persson et al. [3]. A classification is done regarding different topologies (Figure 3.1). Subfigure 3.1 (a) lists different rolls a Bluetooth device could adopt. Subfigure 3.1 (b) describes the basic piconet, which consist of one master and up to seven slaves. Subfigure 3.1 (c) describes a scatternet based on two piconets using a Slave/Slave Bridge between them. Another approach is using a Master/Slave Bridge, Subfigure 3.1 (d). This could be extended using a tree topology or a torus for a master/slave bridge, see Subfigures 3.1 (e–f). Finally a torus with a slave/slave bridges is also possible, see Subfigure 3.1 (g). Creating a scatternet using three stages is described by Tadashi et al. [16]. First a neighbour discovery protocol is used. The reason is to create small piconets before one can create a scatternet. Second, a scatternet formation protocol to maintain the scatternet itself. Now, the entire ad-hoc network is up and running. Finally, to maintain the scatternet created, a scatternet adjustment protocol is used in order to take care of new nodes or old ones leaving the range. All these stages are simulated and different performance results are presented. However, the software used is not mentioned, which questions the trustworthiness of the results. A similar paper describes a three-phase ad-hoc network formation Bluestars and Bluestars* by JiHyuck et al. [17]. The first phase is the same as the previous paper, namely neighbour discovery. Secondly, neighbour grouping (scatternet formation) is performed. Finally, a role assignment takes place. This differs as compared to the previous paper. The last phase concentrates on the role between the devices. Bluestars and Bluestars* are compared to a tree topology proposed in [18]. A topology visualization tool was created to examine the behaviours. The proposed topology use shorter average distance instead of the tree topology with a reasonable number of links. Another approach used is a distributed scatternet formation protocol as described by. Salonidis et al. [19]. The Bluetooth Topology Contruction Protocol (BTCP) consists of two phases. The first phase is used to select a single global leader within its range. The leader have knowledge about other devices. In the next phase, the leader tells other devices to form the scatternet. Law et al. [14, 15] reduce the steps to only one phase. A vote between two or several devices is used for electing a leader. This is recursively done until the entire scatternet is created. Juha et al. [20] describe an Improvement Bluetooth Network Formation (IBNF). This overcomes the restriction regarding the transmission range required.

State-of-the-Art of Bluetooth-related Research

(a) Definition

(b) Single Piconet

(d) Master/Slave Bridge

(f) Master/Slave Torus

(c) Slave/Slave Bridge

(e) Tree Structure

(g) Slave/Slave Bridge Torus

Figure 3.1: Piconet and Scatternet Topology Models [3].

43

44

3.2

Chapter 3

Analysis and Simulation

Pollard et al. [21] simulated a Bluetooth radio channel. The simulation was based on the physical layer which consists of both the baseband and the radio part. The model included basic retransmission techniques like Forward Error Correction (FEC) and Acknowledgement/Request (ARQ). They calculated the Bit Error Rate (BER) based on the input and output stream. Their simulation results were validated against other theoretical results to ensure credibility. Their conclusion based on simulations was that the data channel needs FEC and ARQ even if the noise level is low1 , and the voice channel does not need FEC even in a noisy environment. Záruba et al. [22] derived a theoretical and a simulation model. Both models were based on the discovery phase from the state machine of Bluetooth, also known as the inquiry procedure. Their analytical model is validated against their own discrete model together with a confidence interval of 95 %. However, their own discrete model itself is not validated against other simulation models or the Bluetooth specification. The result presented is a mathematical analysis of the discovery time for the Bluetooth inquiry procedure. Welsh et al. [23] carried out an empirical analysis of the connection time between one to four Bluetooth devices. Further, they suggested three possible changes to the Bluetooth specification and how to decrease the connection time by simulating the connection in the simulation program ns-2 [24] with the optional BlueHoc package [25]. This work was done to see whether Bluetooth units where suitable as moving objects with respect to the time necessary to connect two Bluetooth units. Murphy et al. [26] focused on short-term ad-hoc connections between moving vehicles. Other areas included are range and throughput capacity between two Bluetooth devices. When investigating some variables in the baseband layer, they had to emulate its behaviour. They used a simulation program, Rice Bluetooth Baseband Inquiry Tester (RIBBIT) [4], based on the open source code from International Business Machines (IBM) BlueHoc for simulating connection times. Tae-Jin Lee et al. [27] conducted a performance evaluation with point-tomultipoint connections, including Asynchronous Connection-Less (ACL) and Synchronous Connection Oriented (SCO) connections in a piconet. When 1 low

noise level ∼ = high Signal-to-Noise Ratio (SNR)


45

using the simulation they adopted a different set of parameters as compared to our simulations, cf. Chapter 4.

3.3

Coexistence with IEEE 802.11b

Why is coexistence an issue? Because both the IEEE 802.11 and IEEE 802.15.1 standards are using the same Industrial, Scientific and Medical (ISM)band. The spread spectrum technique used is classified into two groups, Frequency Hopping (FH) and Direct Sequence (DS). Several papers have used both techniques when deriving analytical models and empirical analysis. For wireless LAN (IEEE 802.11) and DS they refer to specifications [28, 29], and for Bluetooth (IEEE 802.15.1) and FH to specifications [1, 2] respectively. They are not using the FH from the IEEE 802.11 specification which is based on another algorithm but instead all FH simulations are based on the IEEE 802.15.1 specification. The two groups, FH and DS, together with theirs channels are shown in Figure 3.2. The IEEE 802.15 FH channels are not overlapping each other while IEEE 802.11 DS channels do. A DS channel is statically chosen compared to a FH channel which uses all available channels in a pseudo-random order.

Figure 3.2: IEEE 802.15.1 (FHSS) vs. IEEE 802.11b (DSSS). Howitt et al. [30, 31] presented performance tests regarding coexistence issues for Bluetooth FH and WLAN (802.11b) DS. An analytical model was created and tested against empirical test results. Three types of scenarios

46

Chapter 3

were used; static conditions, a single signal source, and an arbitrary network environment. The conclusions were divided into two parts. First, an 802.11b network with small activity has an insignificant impact on the Bluetooth performance. Second, a higher activity in a 802.11b network makes a Bluetooth network experience a limited performance loss. Chiasserini et al. [32] used a WLAN and Bluetooth coexistence mechanisms OverLap Avoidance (OLA) in the 2.4 GHz ISM band. Two scheduling techniques were proposed: Voice OverLap Avoidance (V-OLA) and Data OverLap Avoidance (D-OLA). Results indicated significant improvements of voice connections in terms of 20 % for 802.11b and Bluetooth. For data traffic the improvement was in terms of 50 %. Matheus et al. [33] used a radio network testbed to investigate the behaviour between IEEE 802.11b and Bluetooth. The performance depended on the length of each Bluetooth link. It also depended on the distance to the WLAN source. Another interesting aspect is the orientation of the Bluetooth antenna; this however indicated a somewhat smaller impact on the performance than expected. The ACL-links did not suffer much performance as compared to the SCO-links which indicated some audio performance loss. From the IEEE 802.11b point of view, the performance degradation was moderate with fully loaded Bluetooth data transmissions. Feng et al. [34] classified the interference from IEEE 802.11b into two categories. The first category is the FH and the second is the DS. H is the duration of a Bluetooth packet. L is the duration of an IEEE 802.11b packet. The probability of a Bluetooth packet of duration H with no collisions to IEEE 802.11b FH of duration L is P s = (78/79)H/L (H/L − H/L) + (78/79)H/L+1 (1 − H/L + H/L) The probability of a Bluetooth packet of duration H with no collisions to IEEE 802.11 DS is P s = (57/79)H/L (H/L − H/L) + (57/79)H/L+1 (1 − H/L + H/L) Golmie et al. [35] evaluated the performance between Bluetooth and IEEE 802.11b. They investigated the impact of the transmission power, load, and traffic type (different size on the packets). First, increased power for the WLAN did not reduce packet loss for the WLAN itself. However, for Bluetooth a reduced power of WLAN reduced the packet loss. Second, a bigger


47

Table 3.1: Hopping rate in IEEE 802.11 FHSS. Mbps

Packet length (bytes)

Hz

1

4096

30

2

4096

60

1

1500

81

2

1500

156

packet size reduces the interference with WLAN. Third, the worst case of interference occurs when using a voice channel (SCO). Finally, using a correction code like FEC or similar does not improve the performance. If an error occurred, there are too many bits to correct. Stranné et al. [36] used an analytical model based on IEEE 802.11b FHSS and Bluetooth FHSS. The conclusion is that 802.11b FHSS suffer more in performance compared to Bluetooth FHSS due to its slower frequency hopping rate. Bluetooth is using a hopping rate of 1600 Hz in the connection state. During an establishing of a connection the frequency rate is twice as high, 3200 Hz. The inquiry, page and the connection procedure has not been considered which uses 1600 hops per second. The analytical model used the parameters shown in Table 3.1. Golmie and Mouveaux [37] did an investigation regarding performance analysis of IEEE 802.11b and Bluetooth. They performed a probability and a simulative analysis towards packet loss and access delays. Their analysis was based on uniformly distributed frequencies. This can be considered true if one considers all versions up to Bluetooth version 1.1 (cf. Chapter 2). The Bluetooth version 1.2 do not behaves uniformly any longer (cf. Chapter 5). Still, the results provide a hint on the level of performance. In this case the results indicated a packet loss of 13 % for the data channel and 3 % for the voice channel.

3.4

Discussion

Regarding scatternet formation many suggestions have been presented. One issue that is not mentioned in these papers is that the slave/slave bridge is not

48

Chapter 3

Table 3.2: Packet type size vs. slot size. Packet Type

Size (bits)

Number of slots n

Per cent of a slot(s)

ID

68

1

10.9

NULL

126

1

20.1

POLL

126

1

20.1

FHS

270

1

43.2

AUX1

134 – 366

1

21.4 – 58.5

DV

234 – 306

1

37.4 – 48.9

DM1

230 – 366

1

36.8 – 58.5

DH1

150 – 366

1

24.0 – 58.5

DM3

238 – 1206

3

12.7 – 64.3

DH3

158 – 1622

3

8.4 – 86.5

DM5

238 – 2030

5

7.6 – 64.9

DH5

158 – 2870

5

5.0 – 91.8

yet implemented in hardware. So, the only possible way to conduct research is to simulate the behaviour. One fundamental basis missing in most papers is a validated simulation models, which in turn makes the simulation results for the models used questionable. Generally, in most papers simulation results are based on software packages that are not validated. The proposed algorithms are very interesting, but still they are based on doubtful simulation models. All papers presenting research regarding coexistence with IEEE 802.11b are using the size of a slot when comparing its calculations in performance analysis. This gives us an idea of the magnitude of the disturbance they do to each other. If one is looking for a more accurate answer one should consider the size of each packet produced and not only the size of a slot. Table 3.2 illustrates the ratio of a slot consumed by different packet types, which gives an even better idea of the degree of interference between both methodologies.

Chapter 4

Validation of Simulations of Bluetooth’s FHSS Technique In this chapter a verification of Bluetooth’s selection box together with a validation of its state machine are given. This work has been carried out in order to establish a trustworthy simulation model used throughout this thesis. Software corrections to existing simulation software are also described. Finally, an example of how verification against the Bluetooth state machine could be accomplished is presented.

4.1

Introduction

BluetoothTM was designed for cable replacements and ad-hoc networking in form of wireless transmission with comparably low bit rates over short distances. In order to properly design Bluetooth networks and investigate the effects of new ideas, we need to carry out performance studies. However, using hardware in a real-life simulation is in general more costly and time-consuming than using a simulation model. In some cases, a simulation is the only way to verify and test certain situations or the only way to investigate the question of interest. But then, the question arises whether such a model is trustworthy, i.e. whether its behaviour coincides with the corresponding standards. 49

50

Chapter 4

“If a model is not valid, then any conclusions derived from the model will be of doubtful value.” [6], p. 298. Thus, one issue of concern arises when evaluating performance data derived from a simulation model: Can the results from the simulation be trusted? Are they fairly accurate? One way to find out is to validate results from the simulation model with empirical measurements. Another way is to validate the code of open-source simulation against the specification. When comparing measurement results with those generated by well established simulation software, we got indications that something is not as it should be. Different shapes of histograms of Bluetooth-specific durations gave us a hint that we should investigate even deeper how the Frequency Hopping Spread Spectrum (FHSS) technique is implemented in Bluetooth simulation models. This technique gives Bluetooth the potential of creating hardly disturbed ad-hoc networks in an industrial environment. The FHSS technique avoids disturbance using a pseudo-random jump between frequencies over a wide bandwidth spectrum of 2.402–2.480 GHz or 79 frequencies (23 in some countries). The FHSS is based on two steps. First, the selection box derives how to calculate the next frequency depending on the current substate. Second, the state machine derives which sequence to use between the substate. The first step is easily validated because of the sample data from the specification. The second step is a lot harder to validate, as the specification does not provide any tools for validating this in any way. In this case, one is pointed to [1, 38] to interpret the text into a state machine. The state machine plays an important role in the process of creating an ad-hoc network. A connection process always follows a predetermined pattern: standby, inquiry, page and connected, see Figures 2.1 and 2.2. The inquiry procedure, initiated by the master device, could be explained with the question: Is anybody out there? This question is to be answered by any slave device in inquiry scan substate. The page procedure, also initiated by the master device, could be explained with the question: Are you there? This question is dedicated towards a particular slave device being in page scan substate. Also, the slave takes over the master’s clock in order to yield a common timebase within the piconet. Finally, a connection is made between the master and that slave device. In this chapter the following issues for the Bluetooth FHSS are considered: The algorithm of the selection box are validated against the specifica-

Validation of Simulations of Bluetooth’s FHSS Technique

51

tion p. 962–974 [1], and the state machines of the inquiry, page and connection procedures are compared through different simulations.

4.2

Simulation

Simulation is a substitute for empirical measurements. In some cases it’s the only option to assess the behaviour of a system avoiding days, the impact of a volcano eruption or a collision between cars. Still simulation programs do not have the ability to exactly simulate the correct results. In some cases it’s still necessary to carry out collision tests between cars by crashing the cars. The reason is the importance of the correctness of the results mainly due to the limited degree of modelling accuracy. Another reason of building a simulation model is to test all possible combinations of events for both normal and abnormal behaviour.

4.2.1

The simulation process

A description of the simulation process follows with explanation and discussion of the subparts (Figure 4.1).

Figure 4.1: Verification and validation scheme.

52

Chapter 4

System. The system itself is divided into two parts software and hardware. The software in this case is a program which is executed on a computer of some kind and the hardware is a hardware device from a vendor. Specification. Through different documentations, e.g. specifications and books, the system and how it is supposed to work is described in detail. Many authors have different views on special aspects and describe the related behaviour accordingly. These aspects are later put together into a final specification describing the overall functionality of the system. The conclusions of the specification can then be described as pseudo-code. Model. The specification has to be transformed into executable code. Now some constraints could arise. Not everything can be transformed to code suitable for simulations. The precision of the model is one aspect. The simulation model perhaps needs a precision of a degree that could take the actual simulation to long to execute. Also, the precision of a state variable can be an obstacle. Choosing a proper level of precision for the simulation model is a matter of experience. In some cases a test of the model before translating it into code could be necessary. Program and Verification. The next step is rather straight ahead: The model is to be translated to a known program language like C/C++ or Perl. In some cases it’s possible to use already created functions which makes codewriting faster and usually even less buggy. Another way is to develop and write a program in different languages and side by side compare the data in different levels during the creation. In this case, different behaviours of the compilers and executions on the hardware could be discovered. Different programming languages have solved their implementations differently and could deviate in some cases. This is minimised by using more than one programming language during the programming phase. If a program already existed, verification should take place to make sure that it correctly implements the model of interest. One way is to look into the program code and compare it with verified code for a validated model program code. The first step is to create a flow chart of the program. It’s not only the actual program code, it could also be the initialization of the parameters that matters. Data. Through numerous simulations the output data should be investigated. Is the data correct enough with regards to the goal of the study? Both short and long simulations may be necessary to get clearness of the behaviour of the implementation for instance as compared.


53

Results. Finally, results of interest are to be extracted from the data created by the program. The results could be mean, median, variance, minimum or maximum of a variable of interest. One way to make the results credible is to construct confidence intervals. Another interesting result is the type of distribution of a variable. In some cases the results could be validated towards the specification. Validation. If the results are created from software and hardware, they should also be validated against each other. In some cases, it might not be possible to compare the exact behaviour, which is mostly depending on the ”black box” character of some software and hardware. One way is to compare each others histograms, mean, minimum and maximum values, respectively, to see if a resemblance is to be found.

4.2.2

Implementation of the process

The simulation program that we produced was a work conducted concurrently in the form of two theses [39, 40]. The first group of students was concentrating on the algorithms used between the 802.15.1 specification and the actual source code to Rice Bluetooth Baseband Inquiry Tester (RIBBIT) [4] and BlueHoc [25]. Each state transition was derived and compared with each other. The RIBBIT does only simulate the inquiry phase. The BlueHoc simulates the complete state transition of a time-to-connect. The second group of students developed a simulation program in C concurrently with the author who developed correspondingly code in Perl. The benefit of using different program languages are many, i.e. the code written in Perl was not able to borrow any code from previous work (which was all written in C). Thus, the influence of ”borrowed code” was eliminated. The creation of the simulation model was then carried out concurrently step by step. Each step was compared between the two simulation models. If the sub-results were equal to each other the models were considered correct, and the next step was developed. Finally, the inner core or the selection box of the FHSS technique was easily checked and verified because of the samples data available from the Bluetooth specification [1]. Our simulation model is capable of handling collision detection. This is important because it has an impact on the simulation results if more than one master and one slave are used. This is not implemented in the BlueHoc [25] package. Our simulation model is also capable of handling the 23-frequency system.

54

4.3

Chapter 4

Empirical Analysis of the Inquiry Procedure

In this Section, a presentation of the measurement setup is given (Figure 4.2). The empirical results are based on real-time measurement of inquiry and connection activity for the inquiring device. The Bluetooth devices were located closely together (0.1 m) during all measurements and any other Bluetooth and IEEE 802.11b equipment nearby the measurement was turned off.

4.3.1

Measurement Setup

One program was implemented to handle two types of modes, master and slave. Each command and event packet from the Bluetooth device was logged with a time stamp resolution of 1 ms, see the example in Table 4.1, command packet (01 . . . ) and event packet (04 . . . ). Two Bluetooth devices of type Ericsson Bluetooth Starter Kit (LPY 111 243) [41] were connected to a computer.

Figure 4.2: Bluetooth setup for empirical data measurements. In master mode, the program starts with a uniformly distributed random time between 0 and 10.24 s to minimize correlation between subsequent samples. First, the master device was initialized with the Host Controller Interface (HCI) command Reset before making any attempts to find any Bluetooth devices. Second, the HCI command Inquiry was used. In slave mode, the program starts with a HCI command Reset, Set Event Filter with Inquiry Scan enabled, and stays in this mode during the measurements. Second, the master device waits for an Inquiry Result event. Third,


55

the HCI command Create Connection is issued. Fourth, the master device waits for a Connection Complete event. Fifth, the HCI command Disconnect is performed. Finally, the master device waits for a Disconnection Complete event. This sequence of commands and events is conducted over a period of 500 samples each time. Table 4.1: Command packets sent and event packets received from master device. Time

Command / Event

(hh:mm:ss.ms) 12:40:42.902

3092-Delay

12:40:42.922

01030C00-Reset

12:40:46.037

01010405338B9E3000-Inquiry

12:40:50.333

04020F011F8C163780000100000000003351

12:40:50.353

0105040D1F8C163780000800000033D100-Con

12:40:54.328

04030B0001001F8C163780000100

12:40:54.579

01060403010013-Disconnect

12:40:54.789

04050400010016

Every time stamp between the Inquiry command and the successive commands and events is saved. Looking at an example (Table 4.1), the command for inquiry at time 12:40:46.037 and the Inquiry Result event at time 12:40:50.333 have a time difference of 4.296 s. A possible pitfall is related to the fact that looking for the same device without any time delay between two samples could endanger the measurements, because both can still know each other which might imply a short inquiry time. Another potential problem is that other Bluetooth devices may happen to be located close to the measurement equipment. The program is also taking care of this problem. In this situation the ”alien” Bluetooth address is displayed in an alert window.

56

4.3.2

Chapter 4

Bluetooth Commands

Several Bluetooth commands were used during the measurements. Inquiry. The HCI command Inquiry has been initialized with the following parameters, GIAC (0x9E8B33), inquiry length (N = 30) and Num Responses (unlimited number of responses). Create Connection. The HCI command Create Connection has been initialized with the following parameters: BD ADDR, Packet Type (0x0008), Page Scan Repetition Mode (0x00), Page Scan Mode (0x00), Clock Offset (extracted from the Inquiry Result event with bit 15 set to 1, valid clock offset) and Allow Role Switch (0x00). Disconnect. The HCI command Disconnect has been initialized with the following parameters, Connection Handle (0x0001) and Reason, other end terminated connection: User ended connection (0x13). Read Inquiry Scan Activity. The empirical tests were partly based on the two default values from the command Read Inquiry Scan Activity with the subcommand Inquiry Scan Interval (Default: N = 0x0800, i.e. a time of 1.28 s) and Inquiry Scan Window (Default: N = 0x0012, i.e. a time of 11.25 ms).

4.3.3

Limitations

The use of 500 batches was a compromise due to limitations imposed by the hardware: After about 1,000 samples (i.e. four hours of operation), the device ceased to work. For sake of better comparability, the mean inquiry times of 2,500 measurements from five independent batches are given.

4.4

Confidence Analysis

In order to get an idea of the statistical quality of the mean inquiry times Xi obtained from 250 measurements per simulation run, confidence intervals are constructed (Equation 4.1). As the lag-1 correlation estimation of Xi is slightly negative (correlation coefficient of −0.0056), we use standard confidence analysis. The confidence interval is given by S2 ¯ X ± tα (n − 1) n

(4.1)


57

Inquiry time, 500 samples 15

Time (s)

10

5

0

0

50

100

150

200

250 Samples

300

Histogram

450

500

120

20 15

0.03 5.238 1.9837 1.772 1.2836

min: max: mean: median: std:

100 Number of samples



400

Histogram, 5*500 samples

30

10 5 0

350

80 60

0.03 5.287 1.8676 1.632 1.2201

40 20

0

10

20 Time (s)

30

0

0

10

20

30

Time (s)

Figure 4.3: Inquiry times obtained from the Ericsson Bluetooth Starter Kit.

58

Chapter 4


Time (s)

10

5

0

0

50

100

150

200

250 Samples

300

Histogram

450

500

120

20 15

0.047813 5.5062 2.152 1.9141 1.2763





400

Histogram, 2500 samples

30

10 5 0

350

80 60

0.038437 5.6766 2.1661 2.0102 1.2971

40 20

0

5

10 15 Time (s)

20

25

0

0

5

10 15 Time (s)

20

Figure 4.4: Inquiry times obtained from our own simulator model.

25


59


Time (s)

10

5

0

0

50

100

150

200

250 Samples

300

Histogram

450

500

120

20 15

0.12844 9.0847 2.3363 1.7561 1.5709





400

Histogram, 5*500 samples

30

10 5 0

350

80 60

0.0575 8.3078 2.3711 2.7669 1.4931

40 20

0

10

20 Time (s)

30

0

0

10

20

30

Time (s)

Figure 4.5: Inquiry times obtained from the simulator RIBBIT version 1.0 [4].

60

Chapter 4

√ ¯ = 2.1579 is the average of n = 60 mean inquiry times Xi , S 2 = where X 0.0810 is the standard deviation and tα (n − 1) 2.00 for a confidence level of 1 − α = 95 %. This results in a half size of the confidence interval of 0.0209, which is less than 1 % of the mean. Another approach is using an already establish statistical program like Minitab [42]. Four different types of data sets were used. Our data samples are collected and saved for further analysis and connected to respective variable; hardware device (C1), RIBBIT (C2), Simulation 1 (C3), Simulation 2 (C4). A 95 % confidence interval was created for each of them (Figure 4.6 (a) and Table 4.2).

(a) Interval Plot

(b) Box Plot

Figure 4.6: Interval and Box Plot for C1, C2, C3, and C4. A box plot was also derived to see wherever the results are consistent (Figure 4.6 (b)). The samples data from RIBBIT (C2) show a number of abnormal samples. This is one out of several indications that this model does not behave correctly.

4.5

Individual Distribution Identification

Is there a way to check if the system behaves as it should in terms of inquiry times? The answer is yes. The shape of the histogram is like a fingerprint. It can show if the specification is implemented correctly or not. Comparing Figures 4.3 and 4.4 we observe similar shapes of the histograms based


61

Table 4.2: 1-sample t. Scenario

N

¯ X

√ S2

95 % Conf. Int.

C1

2500

1.867

1.22010

[1.81970 – 1.91540]

C2

2500

2.333

1.52968

[2.27348 – 2.39346]

C3

2500

2.166

1.29708

[2.11521 – 2.21695]

C4

2500

2.079

1.16047

[2.03399 – 2.12502]

on measurements and our own, validated simulator. The simulation software RIBBIT [4], however, produced different shapes representing a bimodal distribution (Figure 4.5). If one uses simulations programs like BlueHoc [25] and RIBBIT [4] in an unmodified way one must be aware of the fact that the result tends to be misleading (Figure 4.5). This could result in doubtful inquiry, page and connection times.

4.6

Time Measurement for Inquiry, Page and Connection

In this section we present a complete measurement of the inquiry, page and connection time. The parameters used for the simulations are shown in Section 2, Table 2.1. Table 4.3: Mean value of times for inquiry, page and connection procedures based on 50,000 samples. Standby → Inquiry

Inquiry → Page

Page → Connection

2.0779 s 56%

1.6012 s 43%

0.0012 s 1%

Finally, a larger number of sample data from our simulation model has been extracted to reveal the impact of all three steps inquiry, page and connection towards a complete connection of a Bluetooth device with one master

62

Chapter 4 Inquiry

2000

Number of samples

Page

min: 0.017 max: 5.653 mean: 2.078 median:1.931 std: 1.175

Connection


2000

2000

1500

1500

1500

1000

1000

1000

500

500

500

0

0

5 Time (s)

10

0

0

5 Time (s)


10

0

0

5 Time (s)

10

Figure 4.7: Histogram for the time elapsed from Standby to the end of inquiry, page and connection procedure (validated simulations). and one slave. Table 4.3 shows the mean values obtained for each phase, while Figure 4.7 presents the distribution of the following observations. • Standby → Inquiry (left) • Standby → Page (middle) • Standby → Connection (right) Obviously, the time-to-connect is dominated by the inquiry time, followed by the page time. The very connection procedure, however takes an insignificant time after page procedure has been finished successfully.


4.7

63

Software Analysis

In this section a number of bugs in popular simulation tools are shown together with proposed work-arounds. Two programs were considered during the analysis, RIBBIT version 1.0 [23] based on BlueHoc version 2.0 [25], and our validated simulation program. At first glance, BlueHoc implementation seems to be executed correctly. This implementation is used both in BlueHoc version 2.0 [25] and RIBBIT version 1.0 [23]. However the result of the modulus operator is not equal to the remainder operator in case of negative x value (Equation 4.2). x mod y

=

=

x % y, x

≥