a strategy for improving bluetooth performancescholar.cu.edu.eg/?q=shkhalifa/files/a_strategy... ·...

Cairo University

Faculty of Computers and Information

Information Technology Department

A Strategy for Improving BlueTooth

Performance

By

Shady Samir Mohammad Khalifa

A Thesis Submitted to the


Cairo University

in Partial Fulfilment of the

Requirement for the Degree of

Master of Science

in

Information Technology

Under the Supervision of

Cairo

June 2011

Prof. Sanaa El Ola Hanafi Ahmed



Cairo University

Assoc. Prof. Hesham Nabeh El Mahdy



Cairo University

Prof. Imane Aly Saroit Ismail

Vice Dean for Educational and Student Affairs


Cairo University

ii

ADMISSION

I certify that this work has not been accepted in substance for any academic

degree and is not being concurrently submitted in candidature for any other degree.

Any portions of this thesis for which I am indebted to other sources are

mentioned and explicit references are given.

Student Name : Shady Samir Mohamed Khalifa

Signature : _ _ _ _ _ _ _ _ _ _ _ _ _ _

iii

Cairo University



A Strategy for Improving BlueTooth

Performance

By

Shady Samir Mohamed Khalifa

A Thesis Submitted to the


Cairo University

in Partial Fulfilment of the

Requirement for the Degree of

Master of Science

in

Information Technology

Approved by the Examining Committee

Signature


Cairo University-Egypt

June 2011

iv

Table of Contents

List of Tables ........................................................................... vii

List of Figures ........................................................................ viii

List of Abbreviations ................................................................ x

Dedication .............................................................................. xiii

Acknowledgment .................................................................... xiv

Abstract .................................................................................... xv

Chapter 1: Introduction ........................................................... 2

1.1 Problem Statement ........................................................................... 4

1.2 Thesis Contribution .......................................................................... 5

1.3 Thesis Organization ......................................................................... 5

Chapter 2: Bluetooth Technology ........................................... 8

2.1 Development Timeline ..................................................................... 8

2.2 Protocol Stack ................................................................................ 10

2.2.1 Basic Rate / Enhanced Data Rate Controller ............................................. 11

2.2.2 Alternate MAC/PHY Controller ................................................................ 24

2.2.3 Host Protocols.... ........................................................................................ 25

2.3 Profiles ........................................................................................... 34

2.4 Security .......................................................................................... 35

2.5 Interference Analysis ..................................................................... 36

2.6 Summary ........................................................................................ 37

Chapter 3: Candidate Technologies for the Alternative

Controller ................................................................................. 39

3.1 IEEE 802.11 Family ....................................................................... 39

3.1.1 Standardization Efforts .............................................................................. 40

v

3.1.2 IEEE 802.11 Physical layer ....................................................................... 40

3.1.3 IEEE 802.11 Medium Access Control Schemas ....................................... 42

3.1.4 IEEE802.11 Updates .................................................................................. 43

3.2 Ultra Wide Band ............................................................................ 46

3.2.1 Standardization Efforts .............................................................................. 47

3.2.2 Physical Layer.... ....................................................................................... 47

3.2.3 Medium Access Control Schemas ............................................................. 50

3.2.4 Interference Analysis ................................................................................. 52

3.3 Technologies Comparison .............................................................. 53

3.4 Previous Work ............................................................................... 53

3.4.1 Bluetooth V3.0 over WiMedia UWB Linux Driver .................................. 54

3.4.2 Video Transmission using Bluetooth V3.0 over WiMedia UWB ............. 54

3.4.3 Bluetooth V3.0 over WiMedia UWB Verse Certified Wireless USB ....... 55

3.4.4 Comments…………. ................................................................................. 55

3.5 Summary ........................................................................................ 56

Chapter 4: A Proposed Alternative Controller ................... 58

4.1 Physical Layer ................................................................................ 59

4.1.1 Technology Selection Criteria ................................................................... 59

4.1.2 Technical Details ....................................................................................... 60

4.2 Medium Access Control Protocol .................................................. 67

4.2.1 Protocol Selection Criteria ......................................................................... 67

4.2.2 Technical Details ....................................................................................... 67

4.2.3 Frame Format...... ....................................................................................... 71

4.3 Protocol Adaptation Layer ............................................................. 73

4.3.1 Protocol State Machine .............................................................................. 74

4.3.2 Data Encapsulation .................................................................................... 74

4.3.3 Data Structures...... ..................................................................................... 75

4.4 Summary ........................................................................................ 77

vi

Chapter 5: Proposed Controller Evaluation ........................ 79

5.1 Simulation Environment ................................................................ 79

5.1.1 Scenarios Setup. ......................................................................................... 80

5.1.2 Simulation Parameters ............................................................................... 81

5.1.3 Evaluation Criteria ..................................................................................... 82

5.2 Evaluation Methodology ................................................................ 85

5.2.1 Available Bluetooth Simulation Models ................................................... 85

5.2.2 High Speed Bluetooth Simulation Model .................................................. 87

5.3 Results and Analysis ...................................................................... 92

5.3.1 Throughput............. ................................................................................... 92

5.3.2 Transfer Time..... ....................................................................................... 94

5.3.3 Energy Consumption per Bit ..................................................................... 95

5.3.4 Average End-to-End Delay ........................................................................ 99

5.4 Comments on the Simulation Results .......................................... 100

5.5 Conclusion ................................................................................... 103

Chapter 6: Conclusions and Future Work ......................... 105

6.1 Conclusions .................................................................................. 105

6.2 Future Work ................................................................................. 106

Thesis Outcomes .................................................................... 108

References .............................................................................. 110

Appendix A: NS2 Experiments TCL Script ....................... 117

Appendix B: Trace Files Format ......................................... 128

Appendix C: Propagation Models ....................................... 134

vii

List of Tables

Table ‎2.1‎Bluetooth‎Transmitter’s‎Power‎Classes ..................................................... 12

Table ‎2.2 Bluetooth Address Types ........................................................................... 15

Table ‎2.3 Bluetooth States ......................................................................................... 16

Table ‎2.4 Baseband Packet Fields ............................................................................. 21

Table ‎2.5 Bluetooth Packet Types ............................................................................. 22

Table ‎2.6 A2MP Packet Fields .................................................................................. 27

Table ‎2.7 BNEP_GENERAL_ETHERNET Packet Type Header Fields .................. 33

Table ‎2.8 Bluetooth Profiles ...................................................................................... 35

Table ‎3.1 Candidate Technologies Comparison ........................................................ 53

Table ‎5.1 Current and Power Consumption. .............................................................. 81

Table ‎5.2 Simulation Parameters ............................................................................... 82

Table ‎5.3 Two Way ANOVA for Throughput of BToWiFi and BToUWB .............. 92

Table ‎5.4 Comparison between BToUWB with BToWiFi and Bluetooth .............. 102

viii

List of Figures

Figure ‎2.1 Bluetooth Development Timeline ............................................................ 10

Figure ‎2.2 BluetoothV3.0+HS Protocol Stack ........................................................... 11

Figure ‎2.3 Bluetooth Scatternet ................................................................................. 13

Figure ‎2.4 Physical Link ............................................................................................ 14

Figure ‎2.5 Bluetooth State Machine .......................................................................... 17

Figure ‎2.6 Basic Rate Packet Format ......................................................................... 20

Figure ‎2.7 Enhanced Data Rate packet Format ......................................................... 20

Figure ‎2.8 L2CAP PDU (B-frame) format on connection-oriented channels ........... 25

Figure ‎2.9 L2CAP PDU (G-frame) format on the Connectionless channel .............. 25

Figure ‎2.10 L2CAP PDU formats in Flow Control and Retransmission Modes. ...... 26

Figure ‎2.11 A2MP Packet Format ............................................................................. 27

Figure ‎2.12 AMP Physical Link Creation Step 1 ...................................................... 28




Figure ‎2.16 AMP Physical Link Destruction procedure ............................................ 30

Figure ‎2.17 Guaranteed Logical Link Creation Procedure ....................................... 31

Figure ‎2.18 Logical Link Destruction Procedure ...................................................... 31

Figure ‎2.19 BNEP with an Ethernet Packet payload sent using L2CAP ................... 32

Figure ‎2.20 BNEP_GENERAL_ETHERNET Packet Type Header ......................... 33

Figure ‎2.21 BNEP_ CONTROL Packet Type Header ............................................... 33

Figure ‎3.1 IEEE802.11 DSSS channels ..................................................................... 41

Figure ‎3.2 UWB bands for different regions. ............................................................ 47

Figure ‎3.3 MB-OFDM Bands defined by ECMA-368. ............................................. 48

Figure ‎3.4 IR UWB pulse (Left: Time domain and Right: Frequency domain). ...... 49

Figure ‎4.1 TH IR-UWB with PPM. ........................................................................... 61

Figure ‎4.2 Convolutional Encoder ............................................................................ 62

Figure ‎4.3 Punctured Codes ....................................................................................... 63

Figure ‎4.4 A sequence consisting of a solo 1 bit as it goes through the encoder. The

single bit produces 8 bit of output .............................................................................. 64

Figure ‎4.5 Trellis diagrams for (2, 1, 4) code ............................................................ 66

Figure ‎4.8 Dynamic Channel Coding ........................................................................ 70

ix

Figure ‎4.7 UWB Frame Format ................................................................................. 71

Figure ‎4.8 UWB MAC Header .................................................................................. 72

Figure ‎4.10 LLC Header from UWB PAL Encapsulation ......................................... 75

Figure ‎4.9 UWB PAL State Machine ........................................................................ 74

Figure ‎5.1 Simulation topology 10 nodes and 5 connections .................................... 80

Figure ‎5.2 Suitetooth Bluetooth master node model architecture .............................. 86

Figure ‎5.3 UCBT Bluetooth node model architecture ............................................... 87

Figure ‎5.4 HSBT BluetoothV3.0 node ...................................................................... 90

Figure ‎5.5 HSBT site visits per country ..................................................................... 91

Figure ‎5.6 Throughput of BluetoothV2.1+EDR, BToWiFi and BToUWB .............. 93

Figure ‎5.7 Transfer time of BluetoothV2.1+EDR, BToWiFi and BToUWB ............ 95

Figure ‎5.8 Energy consumption per bit of BluetoothV3.0, IEEE802.11g and TH IR-

UWB at 1Mbps .......................................................................................................... 96

Figure ‎5.9 Energy consumption per bit of BluetoothV2.1+EDR, BToWiFi and

BToUWB for high data rates ..................................................................................... 97

Figure ‎5.10 Energy Consumption Percentage per node of BluetoothV2.1+EDR,

BToWiFi and BToUWB for high data rates .............................................................. 98

Figure ‎5.12 End-to-End packet delayof BluetoothV2.1+EDR, BToWiFi and

BToUWB ................................................................................................................... 99

Figure ‎5.11 IEEE802.11g VS TH IR-UWB (a) Transmitter ON time, (b) Receiver

ON time ...................................................................................................................... 99

x

List of Abbreviations

A2MP Alternate MAC/PHY Manager Protocol

ACL Asynchronous Connection-Less

AFH Adaptive Frequency Hopping

AMP Alternative MAC/PHY

ASB Active Slave Broadcast

BR/EDR Basic Rate / Enhanced Data Rate

BPM Bi-Phase Modulation

BNEP Bluetooth Network Encapsulation Protocol

BP Beacon Period

BT Bluetooth

BToUWB Bluetooth over Ultra Wide Band

CAP Contention Access Period

CSMA/CA Carrier Sense Multiple Access with Collision Avoidance

CTAP Channel Time Allocation Period

DCC Dynamic Channel Coding

DCF Distributed Coordination Function

DPSK Differential Phase Shift Keying

DQPSK Differential Quaternary Phase Shift Keying

DRP Distributed Reservation

DS-CDMA Direct Sequence Code Division Multiple Access

DSSS Direct-Sequence Spread Spectrum

DS-UWB Direct Sequence UWB

DTP Data Transfer Period

ECMA European Computer Manufacturers’ Association Institute

EDCA Enhanced Distributed Channel Access

EDR Enhanced Data Rate

EIR Extended Inquiry Response

EIRP Effective Isotropic Radiated Power

eSCO Extended Synchronous Connection-Oriented

ETSI European Telecommunications Standards

xi

FCC Federal Communication Commission

FCS Frame Check Sequence

FEC Forward Error Correction

FH Frequency Hopping

FHSS Frequency Hopping Spread Spectrum

GFSK Gaussian Frequency Shift Keying

HDTV High Definition TV

HCCA HCF Controlled Channel Access

HCF Hybrid Coordination Function

HCI Host Controller Interface

HCS Header Check Sequence

IFM Interference Mitigation

IFS Inter Frame Spacing

IR Impulse Radio

ISM Industrial, Scientific and Medical radio band

ISO International Organization for Standardization

L2CAP Logical Link Control and Adaptation protocol

LLC Logical Link Control

LMP Link Manager Protocol

MAC Medium Access Control sub layer

MAS Medium Access Slots

MB - OFDM Multiband Orthogonal Frequency Division Modulation

MIFS Minimum Inter Frame Spacing

MIMO Multiple-Input Multiple-Output

MPDU MAC Protocol Data Unit

MSDU MAC Service Data Unit

PAL Protocol Adaptation Layer

PAN Personal Area Network

PC Personal Computer

PCA Prioritized Contention Access

PCF Point Coordination Function

PHY Physical layer

xii

PLCP Physical Layer Convergence Procedure

PNC PicoNet Controller

PPDM Pulse Position De-Modulator

PPM Pulse Position Modulator

PRNG Pseudo-Random Number Generator

PRP Pulse Repetition Period

PSB Parked Slave Broadcast

PSD Power Spectral Density

PSK Phase Shift Keying

QoS Quality of Service

RCPC Rate Compatible Punctured Convolutional code

RF Radio Frequency

RIFS Retransmit Inter Frame Spacing

SAR Segmentation and Reassembly

SCO Synchronous connection-oriented

SDM Space Division Multiplexing

SDP Service Discovery Protocol

SFD Start Frame Delimiter

SIFS Short Inter Frame Spacing

SIG Special Interest Group

SNR Signal to Noise Ratio

SS Spread Spectrum

TDMA Time Division Multiple Access

TH Time Hopping

THS Time Hopping Sequence

TLV Type-Length-Value

UWB Ultra Wide Band

WiFi IEEE 802.11g

WPAN Wireless Personal Area Network

xiii

Dedication

To my beloved family

xiv

Acknowledgment

First and foremost I would like to thank God. You have given me the power to

believe in myself and pursue my dreams. I could never have done this without the

faith I have in you, the Almighty.

This thesis would not have been possible without the guidance and the help of

several individuals who in one way or another contributed and extended their

valuable assistance in the preparation and completion of this work.

I take immense pleasure to express my sincere and deep sense of gratitude to

my supervisors: Prof. Sanaa El Ola Hanafi Ahmed, Prof. Imane Aly Saroit and Dr.

Hesham Nabeh El Mahdy for their constant help, support and guidance throughout

this entire process.

I would like to thank my family for their unconditional love and unfailing

support. I will remain eternally indebted to them for allowing me to realize my own

potential and for having faith in me always.

I am also very grateful to my friends for their help, motivation, encouragement

and support. I would like to show my gratitude to Israa Islam for her constructive

comments on this thesis. I am thankful that in the midst of all her activity, she

volunteered to provide me with a feedback on this thesis. I would like to thank Amir

Ibrahim for covering for me during deadlines and hope to return the favour one day.

I would like to show my gratitude to Centrivision for their continuous support

and understanding. Also, for exposing me to the excellent real world software

engineering practices and various code analysis tools, which helped in improving our

simulation model.

I am also indebted to the worldwide HSBT users who used our tool, reported

bugs and/or sent comments and bug fixes, which dramatically improved the code

quality of our Bluetooth simulator.

Lastly, I offer my regards to all of those who supported me in any respect

during the completion of this thesis.

xv

Abstract

Bluetooth is a low-cost, low-power wireless technology initially designed for

cable replacement. With the new mobile lifestyle based on battery powered devices,

Bluetooth came short in satisfying the needs of the high-rate‎applications‎due‎to‎its’‎

limited data rate. Introducing BluetoothV3.0+HS specification in 2009, Bluetooth

can now meet those demands by switching to an alternative controller based on

IEEE802.11g radio. As far as we know, to this date there is no published work on the

performance of IEEE802.11g as an alternative Bluetooth controller. Also, there has

been no work related to the simulation of BluetoothV3.0 using the popular NS2

simulator.

In this thesis, we present an implementation of BluetoothV3.0 model for the

NS2 simulator. The new model simulates multiple controllers as specified in the

Bluetooth V3.0 specification. The implementation was contributed to the NS2

community and made available for all researchers. We then discuss the shortcomings

of IEEE802.11g as an alternative Bluetooth controller and propose a new alternative

Bluetooth controller based on Time Hopping Impulse Radio Ultra Wide Band (TH

IR-UWB) technology.

The results of this thesis showed that though IEEE802.11g provides higher

throughput than Bluetooth, it fails to do so in an energy efficient manner and is

highly affected by interference. Ultra Wide Band (UWB) succeeded to meet the

goals of providing multiple high data-rate, low-power and immunity to interference.

Meeting those goals makes UWB a better choice for high-rate applications running

on battery powered devices. It was also found that Bluetooth over UWB would

provide the same performance of a standalone UWB at high-rates and a better

performance in term of energy consumption at low-rates.

Chapter

1 Introduction

2

Chapter 1

Introduction

Wireless connectivity has enabled a new mobile lifestyle filled with

conveniences for mobile computing users. Consumers will soon demand the same

conveniences throughout their digital home, connecting their computers, personal

digital recorders, MP3 recorders and players, digital camcorders and digital cameras,

high-definition TVs (HDTVs), gaming systems, Personal Digital Assistants (PDAs)

and cell phones, to connect to each other in a Wireless Personal Area Network

(WPAN) in their homes.

The wireless networking technologies developed for wirelessly connecting

devices, such as Wi-Fi and Bluetooth, are not optimized for multiple high-bandwidth

usage models of the digital home. Although data rates can reach 54 Mbps for Wi-Fi,

the technology has limitations in terms of power consumption and bandwidth. When

it comes to connecting multiple devices in a short-range network, a wireless

technology needs to support multiple high data rate streams, consume very little

power and maintain low cost, while sometimes fitting into a very small physical

package, such as PDA or cell phone.


simple point-to-multipoint cable replacement applications; Bluetooth was then used

to form ad-hoc connections between mobile nodes and even for building multi-hop

ad-hoc networks [1]. Bluetooth is also used for some types of sensor networks with

high bandwidth demands [2].

Applications with high bandwidth demands such as high-quality video

streaming have long found difficulties while using Bluetooth. Due to the Bluetooth

low transmission rate only disappointingly low quality streaming can be made. A

number of attempts were made as in [3] to allow compressed high quality video

streaming over BluetoothV2.0. BluetoothV2.0 failed to support high-definition video

streaming.

BluetoothV3.0 [4] specification was released by the Special Interest Group

(SIG) in 2009 to incorporate an Alternative MAC/PHY (AMP) feature. The AMP

feature enables the use of alternative controllers beside the Basic Rate / Enhanced

3

Data Rate (BR/EDR) controller for transporting Bluetooth profile data at higher

rates. The new specification uses the Bluetooth high level software and profiles and

two different radio paths: BluetoothV2.1 [5] which offers low power and low data

rate communications and IEEE 802.11g radio [6] that provides data rates up to 54

Mbps.

The use of multiple radios allowed benefiting from the diversity between

different radio-technologies. Bluetooth is used for connecting devices, service

discovery, exchanging control message and even for data transfer at low rates. While

the alternative controller offers high efficiency for large transfer of data providing a

wide range of data rates for multimedia and mobile applications. The idea of using

two radios to benefit from the diversity between them is not new; the idea was

studied in [7-9] but BluetoothV3.0 specification was the first documented standard to

be released.

The utility of mobile nodes is directly impacted by their operating lifetime and

since they are battery-operated, energy becomes a critical resource where the

wireless communication sub-system represents a major source of power consumption

leading to a faster depletion of the battery [2]. This is why the wireless

communication subsystem power consumption must be carefully managed to ensure

the longest running time.

Ultra-wideband (UWB) technology offers a solution for the bandwidth, cost,

power consumption and physical size requirements of next-generation consumer

electronic devices. UWB enables wireless connectivity with consistent high data

rates across multiple devices within the digital home. This emerging technology

provides the high bandwidth that multiple digital video and audio streams require

throughout the home.

UWB is an emerging technology, though the basic idea can be traced back to

the spark gap transmission design of Marconi and Hertz in the late 1890s [10]. In

other words the first wireless communications system was based on UWB but due to

technical limitations then, narrowband communications were preferred to UWB.

UWB technology was firstly used in military covert radar and communications. It

has only seen an accelerating development since 1994 when some of the research

activities were unclassified. UWB was introduced in the commercial market only

after the Federal Communications Commission (FCC) has issued a Report and Order

4

in February 2002 with a given spectral mask requirements for indoor and outdoor

applications.

UWB systems signal is transmitted with a bandwidth much larger than the

modulated signal bandwidth spreading the power over large range of frequencies

leading to a reduction in the power spectral density. UWB signals can support high

data rates due to the large bandwidth available and low power due to the use of

narrow pulses in time. This method produces a signal with high immunity to

interference, low probability of detection or jamming, ability to penetrate materials

and high immunity to multipath fading [10]. These capabilities make UWB very

attractive to be an alternative Bluetooth controller.

1.1 Problem Statement

Bluetooth is a widely-used short-range wireless communications system

intended to replace the cables connecting portable and/or fixed devices. The key

features of Bluetooth are robustness, low power and low cost. Bluetooth simplifies

the discovery and setup of services between devices. Bluetooth devices advertise all

of the services they provide. This makes using services easier because there is no

longer a need to setup network addresses or permissions as in many other networks.

The current Bluetooth radio technology only allows low transmission rates

making it inefficient to transfer large bulks of data or allowing high-quality video

streaming. To be able to use Bluetooth for all kinds of applications, an alternate

controller is needed. The alternate controller must provide:

Consistent high data rates across multiple devices

Low power consumption

Fair medium access

Minimum interference with the existing Bluetooth nodes and other ISM band

technologies

Backward compatibility with the previous versions of Bluetooth.

5

1.2 Thesis Contribution

In this thesis, we present an implementation of BluetoothV3.0 in the NS2

simulator, discuss the shortcomings of IEEE802.11g as an alternative Bluetooth

controller for battery powered devices and propose a new alternative Bluetooth

controller based on Time Hopping Impulse Radio Ultra Wide Band (TH IR-UWB)

technology. We then compare the performance of the proposed controller with that of

BluetoothV3.0 specification over IEEE802.11g in terms of throughput, transfer time,

end-to-end delay and energy efficiency.

1.3 Thesis Organization

This thesis is divided into six chapters organized as follows:

Chapter 2: Bluetooth Technology

This chapter provides the relevant background on the Bluetooth

technology. It covers the Bluetooth development phases, protocol stack,

profiles, security and interference effect.

Chapter 3: Candidate Technologies for the Alternative Controller

This chapter provides a study of the different possible candidates to

support high speed transmission. IEEE802.11 family and the UWB family are

introduced and compared in terms of data rate, energy consumption and

interference effect.

Chapter 4: Proposed Alternative Controller

This chapter provides a detailed presentation of the proposed alternative

controller. It starts with a detailed description of the proposed alternative

physical layer. It then goes to the proposed alternative MAC layer and ends

with the protocol adaptation layer description.

Chapter 5: Proposed Controller Evaluations

In this chapter a comparison is made between the proposed alternative

controller and the one proposed by the Bluetooth SIG. The used evaluation

methodology is represented and the developed BluetoothV3.0 NS-2 extension

is described. Finally an evaluation and discussion of the results is made.

6

Chapter 6: Conclusion and Future Work

This chapter illustrates the main conclusions drawn from this thesis and

points out future research directions.

Chapter

2 Bluetooth Technology

8

Chapter 2

Bluetooth Technology

Bluetooth is an open wireless technology standard for exchanging data over

short distances. Created by telecoms vendor Ericsson in 1994 and currently managed

by the Bluetooth Special Interest Group (SIG). This chapter navigates through the

Bluetooth development timeline and its technical specifications.

This chapter is organized into six sections. Section 2.1 provides a walkthrough

the improvements made to the Bluetooth technology over time. Section 2.2 illustrates

the BluetoothV3.0+HS protocol stack and highlights the major protocols. Section 2.3

presents some of the most used Bluetooth profiles. Section 2.4 represents the security

features implemented in the Bluetooth protocol. Section 2.5 discusses the

interference effect of Bluetooth on other ISM band technologies. Section 2.6

summarizes the chapter.

2.1 Development Timeline

In 1994, Ericsson Mobile Communications, the global telecommunications

company based in Sweden, initiated a study to investigate the feasibility of a low-

power, low-cost radio interface between mobile phones and their accessories. The

aim of the study was to find a way to eliminate cables. As the project progressed, it

became clear that the applications for a short-range radio link were virtually

unlimited. Ericsson's work in this area caught the attention of IBM, Intel, Nokia and

Toshiba. The companies formed the Bluetooth Special Interest Group (SIG) in May

1998. From that date Bluetooth has been rapidly updated to enhance its performance

and to make it suitable for more applications [11].

The Bluetooth SIG companies jointly developed the BluetoothV1.0

specification, which was released in 1999. The specification consisted of two

documents: the foundation core, which provides design specifications; and the

foundation profile, which provides interoperability guidelines. The core document

specifies components such as the radio, baseband, link manager, service discovery

protocol, transport layer and interoperability with different communication protocols.

9

The profile document specifies the protocols and procedures required for different

types of Bluetooth applications [11].

Versions 1.0 and 1.0B had many problems and manufacturers had difficulty

making their products. At the end of 2001 BluetoothV1.1 was released ratified as

IEEE Standard 802.15.1-2002, many errors found in the 1.0B core specifications

were fixed, non-encrypted channels support was added and Received Signal Strength

Indicator (RSSI) was used to determine when the amount of radio energy in the

channel is below a certain threshold at which point the network card is clear to send

[11].

BluetoothV1.2 adopted by the Bluetooth SIG in 2003 ratified as IEEE Standard

802.15.1-2005. Version 1.2 designed to be backward-compatible with version 1.1

and added major enhancements including: faster connection and discovery, adaptive

frequency-hopping spread spectrum (AFH) improving resistance to radio frequency

interference, higher practical transmission speeds up to 721kbps and introducing

flow control and retransmissions of corrupted packets. Following the publication of

802.15.1-2005, the IEEE Study Group voted to discontinue their relationship with

the Bluetooth SIG, effectively meaning that the later versions of Bluetooth will not

become future IEEE standards [11].

In 2004 BluetoothV2.0 core specification was released. The main enhancement

is the introduction of an Enhanced Data Rate (EDR) of 3.4Mbps with practical rate

up to 2.1Mbps [11]. This is three times faster than the previous version and provides

lower power consumption through a reduced duty cycle. As the previous version,

version 2.0 is backward-compatible with version 1.2. Improvements were made to

version 2.0 and in 2007 BluetoothV2.1 core specification [5] was released. Version

2.1 added a Secure Simple Pairing (SSP) mechanism increasing the use and strength

of security. Version 2.1 also provides more information during the inquiry procedure

to allow better filtering of devices before connection in what is known as the

Extended Inquiry Response (EIR) and introduced sniff sub-rating, which reduces the

power consumption in low-power mode.

BluetoothV3.0+HS core specification [4], also known as High Speed Bluetooth

was adopted by the Bluetooth SIG in 2009. High speed Bluetooth builds on the

BluetoothV2.1 architecture by adding an Alternative MAC/PHY (AMP) Manager, an

IEEE802.11 Protocol Adaptation Layer (PAL) Manager, as well as the IEEE802.11

01

alternative MAC/PHY, while adding no changes at the top-level application interface

to the Bluetooth protocol stack/profiles [4]. Supporting backward compatibility and

theoretical data transfer speeds of up to 24Mbps. BluetoothV2.1 link is used for

negotiation, establishment and low date rate traffic and the high data rate traffic is

carried over a collocated 802.11 link.

The latest core specification version 4.0 [12] was release in 2010. Version 4.0

includes Classic Bluetooth BR/EDR, High Speed Bluetooth and Low Energy

Bluetooth protocols. High Speed Bluetooth is based on Wi-Fi and Classic Bluetooth

consists of BluetoothV2.1 protocols, while the Low Energy Bluetooth provides

maximum throughput of 200kbps while consuming only a fraction of the power of

other Bluetooth enabled products. In many cases, products will be able to operate

more than a year on a button cell battery without recharging.

The Bluetooth development time line is summarized in Figure 2.1.

The next section describes the Bluetooth protocol stack based on the

BluetoothV3.0+HS core specification which is used in this study.

2.2 Protocol Stack

BluetoothV3.0+HS core system [4] consists of a Host and zero or more

Controllers. A Host is defined as all of the layers below the application and above the

Host Controller Interface (HCI). The core specification defines a set of core Host

protocols as the Logical Link Control and Adaptation protocol (L2CAP), Alternate

Figure ‎2.1 Bluetooth Development Timeline

00

MAC/PHY Manager Protocol (A2MP), in addition to the Service Discovery Protocol

(SDP).

A Controller is defined as all of the layers below HCI. Two types of Controllers

are defined in the Core Specification V3.0: a Basic Rate / Enhanced Data Rate

(BR/EDR) and an Alternate MAC/PHY (AMP) Controller.

Figure 2.2 shows an overview of the BluetoothV3.0 protocol stack [4]. The

following‎sections‎will‎give‎a‎brief‎description‎of‎the‎relevant‎layers’‎functionalities.

2.2.1 Basic Rate / Enhanced Data Rate Controller

The Basic Rate / Enhanced Data Rate (BR/EDR) Controller includes the

BluetoothV2.1+EDR Radio, Baseband and Link Manager Protocol (LMP).

2.2.1.1 Radio

The BR/EDR radio [5] operates in the Industrial Scientific and Medical (ISM)

frequency band starting at 2.4000 GHz and ending at 2.4835GHz. The bandwidth is

Figure ‎2.2 BluetoothV3.0+HS Protocol Stack

AMP PHY

AMP MAC

AMP PAL

AMP Controller

BluetoothV2.1+EDR

Radio

Baseband

BR/EDR

Controller

Controller

LMP

Host

HCI

Controller

s

Au

dio

BNEP

IP

TCP/UDP

SDP RFCOMM …

L2CAP

Dat

a

Dat

a

Dat

a

Co

ntr

ol

A2MP Control

Co

ntr

ol

Co

ntr

ol

Application

Co

ntr

ol

02

divided into an upper guard band of 2MHz, a lower guard band of 3.5MHz and 79

channels each of 1MHz width. The guard bands ensure that there will be no

interference with radios operating in the adjacent frequency bands.

The signal can be modulated using Gaussian Frequency Shift Keying (GFSK)

for the basic rate of 1Mbps or Phase Shift Keying modulation (PSK) with two

variants, π/4-DQPSK and 8DPSK for the enhanced data rate with a maximum over

the- air data rate up to 3.4Mbps and real throughput around 2.1Mbps.

The Bluetooth radio hops among the 79 channels at up to 1600 hops per second

using the unique physical 48-bit address of the master to determine the hop sequence.

Each packet is transmitted in a different frequency. To avoid interference with other

ISM band signals Adaptive Frequency Hopping (AFH) is used. With AFH, the

hopping sequence may be adapted to exclude a portion of the frequencies that are

used by interfering devices. The AFH improves Bluetooth technology co-existence

with co-located, non-hopping ISM band systems.

Bluetooth transmitters are classified into three power classes, shown in Table

2.1 and on the receiver side the sensitivity level must be above -70 dBm, which

means a Bit Error Rate (BER) of 0.1% is met. Throughout this thesis the term

Bluetooth refers to Class 2 of the Bluetooth transmitters.

Table ‎2.1 Bluetooth Transmitter’s Power Classes

Class Maximum Permitted Power (dBm) Maximum Range (meter)

1 20 100

2 4 10

3 0 1

2.2.1.2 Baseband

The baseband physical layer implements the Bluetooth Link Controller (LC)

which manages physical channels and links whilst providing services like error

correction, hop selection and security. The baseband also manages asynchronous and

synchronous links, handles packets and performs inquiry and paging to discover and

access Bluetooth devices in the area.

03

1. Physical channel

During typical operation, Bluetooth communication occurs between a master

device and several slave devices. The device that provides the synchronization

reference is known as the master. All other devices are known as slaves. Bluetooth

radios are symmetric in that the same device may operate as a master and also as a

slave. Two or more of Bluetooth devices synchronized in this fashion form an ad-hoc

network called piconet.

All units within a piconet share the same channel. Each active device within a

piconet is identifiable by a 3-bit Active Member ADDRess (AM_ADDR) thus there

may be up to seven active slaves at a time within a piconet. Inactive slaves may

continue to reside within the piconet.

Each piconet devices follow the same unique hopping sequence based on a

pseudo-random sequence derived from the piconet master’s‎ Bluetooth‎ Device‎

ADDRess (BD_ADDR). The phase of the hopping sequence is determined by the

Bluetooth clock of the master. Slaves within a piconet must synchronize their

internal clocks and frequency hops with that of the master.

Multiple piconets with overlapping coverage areas form a scatternet. Each

piconet may have only one master, but slaves may participate in different piconets on

a time-division multiplex basis. A device may be a master in one piconet and a slave

in another or a slave in more than one piconet as illustrated in Figure 2.3. Using a

separate frequency hopping sequence per piconet allows the coexistence between

piconets [4].

Figure ‎2.3 Bluetooth Scatternet

Piconet 1

Piconet 2

Active Connection

Parked Connection

Master

Slave/Master

Active Slave

Parked Slave

Stand By node

04

For full duplex transmission, a Time-Division Duplex (TDD) scheme is used.

The physical channel is sub-divided into time slots each‎of‎ 625μs‎where each slot

corresponds to a radio frequency hop. Slots are numbered according to the Bluetooth

clock of the master. Data is transmitted in packets that are positioned in these slots

where a packet start is aligned with a slot start. A master shall only start its

transmission in even-numbered time slots and a slave in odd- numbered time slots.

When circumstances permit, up to five consecutive slots may be allocated to a single

packet.

A master is the only one that may initiate a bluetooth communication link.

However, once a link is established, the slave may request a master/slave switch to

become the master. Slaves are not allowed to talk to each other directly [4]. All

communication occurs within the slave and the master as illustrated in Figure 2.4.

Figure ‎2.4 Physical Link

2. Addressing

There are four types of addresses that can be assigned to a Bluetooth node [4].

Table 2.2 illustrates the allocation of those different types of addresses and the

functionality of each. Bluetooth uses those four types of addresses in order to

maintain 8 connected devices and up to 256 synchronized devices.

fk fk+2 fk fk+2 fk+6

Ma

ster

S

lav

e

Sla

ve

Sla

ve

K+1 k K+13 K+12 K+2 K+3 K+4 K+5 K+6 K+7 K+8 K+9 K+10 K+11

Fre

q.

fk+6

CL

K

05

Table ‎2.2 Bluetooth Address Types

Short name Full

name

Size

(bits) Description

BD_ADDR

Bluetooth

Device

Address

48

Allocated to each transceiver at the manufacturing

time. Constructed from 3 fields:

Lower Address Part (LAP) : 24bit,

BR_ADDR[0:23] Used for SYNC word generation

and FH

Upper Address Part (UAP): 8bit,

BR_ADDR[24:31]. Used to initialize the HEC,

CRC and for FH.

Non-significant Address Part (NAP): 16bit,

BD_ADDR[32:47]. Used to initialize the

encryption.

AM_ADDR

Active

Member

Address

3

Assigned to each active slave in a piconet. Also

considered as the MAC address, where 0 is a broadcast

transmission.

PM_ADDR

Parked

Member

Address

8 Allocated to the device when it enters the PARK state

AR_ADDR

Access

Request

Address

8

Allocated to the device when it enters the PARK state.

Used by parked slave to determine the slave-to-master

half slot to send access request messages to return to

the active mode

3. States

A Bluetooth controller operates in two major states [4]: Stand By and

Connection, with a number of sub-states required to make a connection Inquiry,

Inquiry Scan, Inquiry Response, Page, Page Scan and Page Response. Table 2.3

provides a brief description of the different states.

06

Table ‎2.3 Bluetooth States

State Description

Stand By This is the default state where only the native clock is running and

the device is not connected to other devices.

Inquiry A source device enters this state to discover the devices in range.

Inquiry Scan A destination device enters this state to listen for inquiry packets.

Inquiry Response A destination device enters this state when it receives an inquiry

packet to send an inquiry reply to the source.

Page A source device enters this state to initiate a connection.

Page Scan A destination device enters this state to listen for page packets.

Page Response A destination device enters this state when it receives a page packet

to send a page reply to the source.

Connection This state involves the master and slave exchanging data packets.

In the Connection state the device can enter one of the following connection

modes: Active, Sniff, Hold or Park.

Active: The device actively participates on the channel. The master regularly

sends a polling packets to the slaves to enable them to send a packet to the master

in the master-to-slave slot and re-synchronize themselves.

Sniff: A slave device in sniff mode does not need to be present to receive a

packet from master at every slot. Instead, sniff slots are defined at periodic time

intervals and the slave needs to be present at those slots only. The time between

the sniff slots can be used to save power in the slave unit. Using this mode, it is

possible to drop the power consumption of Bluetooth to very low levels with an

idle connection, while still being able to quickly go to a fully-active

communication. In this state the device keeps the AM_ADDR.

Hold: A slave device in hold mode loses its AM_ADDR and exit the piconet for

a known amount of time. Units get into hold mode by themselves or by master

demands. Hold mode is defined only for ACL connection; SCO packets still can

be received.

07

Park: A slave device does not participate in piconet traffic, but is still

synchronised although it has given up its AM_ADDR address. Occasionally it

will re-synchronise and check on broadcast messages. The slave loses its

AM_ADDR but receives two new addresses PM_ADDR, AR_ADDR, used to

return from park state to active state. A smart use of this state can increase the

number of slaves in a piconet up to 255.

Figure 2.5 illustrates the different Bluetooth states and the transitions between

them [4].

4. Procedures

Bluetooth has the advantage of discovering devices and establishing an actual

connection of new nodes in an ad-hoc fashion by using the Inquiry and Page

procedures respectively. This enables interconnection without a priori knowledge

about other units within range requiring minimum user intervention to establish the

network.

Inquiry (Discovering) Procedure

Bluetooth devices use the inquiry procedure [4] to discover nearby devices, or

to be discovered by devices in their locality. The inquiry procedure is asymmetrical.

A Bluetooth device that tries to find other nearby devices is known as an inquiring

Stand By

Inquiry Page

Connection

Sniff Hold Park

Unconnected State

Connecting States

Active State

Low Power States

Figure ‎2.5 Bluetooth State Machine

08

device and actively sends inquiry requests. Bluetooth devices that are available to be

found are known as discoverable devices and listen for these inquiry requests and

send responses containing their addresses and clocks. The inquiry procedure uses a

special physical channel for the inquiry requests and responses.

An Extended Inquiry Response can be used to provide miscellaneous

information during the inquiry response procedure. Data types are defined for such

things as local name and supported services, information that otherwise would have

to be obtained during a connection using SDP service search.

Paging (Connecting) Procedure

The procedure for forming connections is asymmetrical. The procedure

requires that one Bluetooth device carries out the page (connection) procedure while

the other Bluetooth device is connectable (page scanning). The procedure is targeted,

so that the page procedure is only responded to by one specified Bluetooth device.

The connectable device uses a special physical channel to listen for connection

request packets from the paging (connecting) device. This physical channel has

attributes that are specific to the connectable device, hence only a paging device with

knowledge of the connectable device is able to communicate on this channel. After

the connection establishment the paging (connecting) device becomes automatically

the master of this connection [4].

5. Physical Links

A physical link represents a baseband connection between devices. A physical

link is always associated with exactly one physical channel. There are five types of

physical links that can be established between a master and a slave [4]:

Synchronous Connection-Oriented (SCO) link: is a symmetric, point-to-point

transport between the master and a specific slave. The SCO link reserves slots

and can therefore be considered as a circuit-switched connection between the

master and the slave. The master may support up to three SCO links to the same

slave or to different slaves. A slave may support up to three SCO links from the

same master or two SCO links if the links originate from different masters. SCO

packets are defined to carry 64 Kbps of voice traffic and are never retransmitted

in case of packet loss or error.

09

Extended Synchronous Connection-Oriented (eSCO) link: is a point-to-point

link between the master and a specific slave. eSCO logical transports may be

symmetric or asymmetric. Similar to SCO, eSCO reserves slots and can therefore

be considered a circuit-switched connection between the master and the slave. In

addition to the reserved slots, eSCO supports a retransmission window

immediately following the reserved slots. Together, the reserved slots and the

retransmission window form the complete eSCO window.

Asynchronous Connection-Less (ACL) link: is an asymmetric point-to-point

packet-switched connection between a master and active slaves in the piconet.

ACL links use slots that are not reserved for synchronous links. ACL packets are

retransmitted in case of loss until a positive acknowledgement (ACK) is received

at the source. Bluetooth device can support a single ACL data link. It can also

simultaneously support an ACL data and SCO voice link.

Active Slave Broadcast (ASB) link: is used by a master to communicate with

active slaves.

Parked Slave Broadcast (PSB) link: is used by a master to communicate with

parked slaves.

6. Logical Links

Five logical links are defined [4]: Link Control (LC), ACL Control (ACL-C),

User Asynchronous/Isochronous (ACL-U), User Synchronous (SCO-S) and User

Extended Synchronous (eSCO-S).

The control logical links LC and ACL-C are used at the link control level and

link manager level, respectively. The ACL-U logical link is used to carry either

asynchronous or isochronous user information. The SCO-S and eSCO-S logical links

are used to carry synchronous user information. The LC logical link is carried in the

packet header; all other logical links are carried in the packet payload.

The SCO-S and eSCO-S logical links are carried by the synchronous links

only; the ACL-U link is normally carried by the ACL links; however, it may also be

carried by the data in the DV packet on the SCO link. The ACL-C link may be

carried either by the SCO or the ACL link.

21

7. Packets

Forward Error Correction (FEC) is used on the data payload to reduce the

number of retransmissions. FEC adds unnecessary overhead that reduces the

throughput. Therefore, the packet definitions have been kept flexible to use FEC in

the payload or not. The packet header is always protected by a 1/3 rate FEC since it

contains valuable link information.

The general Basic Rate packet format is shown in Figure 2.6. Each packet

consists of three entities: the access code, the header and the payload.

Figure ‎2.6 Basic Rate Packet Format

The general Enhanced Data Rate packet format [4] is shown in Figure 2.7.

Each packet consists of six entities: the access code, the header, the guard period, the

synchronization sequence, the Enhanced Data Rate payload and the trailer. Different

packet fields are then described in Table 2.4.

In the Enhanced Data Rate packet, the access code and header use the GFSK

modulation mode as for Basic Rate packets while the synchronization sequence, the

Enhanced Data Rate payload and the trailer use the Enhanced Data Rate DPSK

modulation mode. The guard time allows for the transition between the two

modulation modes.

Figure ‎2.7 Enhanced Data Rate packet Format

Access Code

(68/72 bits)

Header

(54 bits)

Payload

(0 – 2745 bits)

Access

Code

Header Enhanced Data Payload

Guard SYNC Trailer

GFSK DPSK

20

Table ‎2.4 Baseband Packet Fields

Field Description

Access Code

Used for timing synchronization, offset compensation, paging and

inquiry.

There are three different types of access codes:

Channel Access Code (CAC) : Unique piconet identifier

Device Access Code (DAC) : Used for paging and paging responses

Inquiry Access Code (IAC): Used for inquiry and inquiry responses

All packets sent in the same physical channel are preceded by the same

access code.

Header

The header contains link control (LC) information and consists of 6

fields:

LT_ADDR: 3-bit physical link address. This field indicates the

destination slave for a packet in a master-to-slave transmission slot and

indicates the source slave for a slave-to-master transmission slot.

TYPE: 4-bit type code which is used to determine how many slots the

current packet will occupy.

FLOW: 1-bit flow control.

ARQN: 1-bit acknowledge indication.

SEQN: 1-bit sequence number

HEC: 8-bit header error check. Checks the header integrity.

The total header, including the HEC, consists of 18 bits and is encoded

with a rate 1/3 FEC resulting in a 54-bit header.

Guard

Only in the Enhanced Data Rate packets.

The‎length‎of‎the‎guard‎time‎shall‎be‎between‎4.75‎μsec‎and‎5.25‎μsec.

The guard time allows for the transition between the two modulation

modes.

SYNC Only in the Enhanced Data Rate packets.

The‎length‎of‎the‎synchronization‎sequence‎is‎11‎μsec

Payload Used Information

Trailer

Only in the Enhanced Data Rate packets.

Two trailer symbols shall be added to the end of the payload. The trailer

bits shall be all zero.

22

Table 2.5 summarize the different packet types used by the Bluetooth baseband

layer.

Table ‎2.5 Bluetooth Packet Types

Packet Description Applicati

on Link

Size

in

bytes

sl

o

ts

CRC

in

bits

F

E

C

ID Carries device access code (DAC)

or inquiry access code (IAC)

Inquiry &

Paging

ACL &

SCO 8.5 1 - -

NULL

Has no payload. Used to get link

information and flow control.

Doesn’t‎require‎Ack.

Flow

Control

ACL &

SCO 15.75 1 - -

POLL Same as NULL but requires Ack. Flow

Control

ACL &

SCO 15.75 1 - -

FHS

Special control packet for revealing

device address and sender clock.

Used in page response, inquiry

response and frequency hop

synchronization.

Setup &

Sync

ACL &

SCO 30 1 - 2/3

DM1 Data Medium-rate Data ACL &

SCO 18 1 16 2/3

DM3 Data Medium-rate Data ACL 123 3 16 2/3

DM5 Data Medium-rate Data ACL 226 5 16 2/3

DH1 Data High-rate Data ACL 28 1 16 -

2-DH1 Similar to DH1 packet but payload

is modulated using‎π/4-DQPSK. Data ACL 56 1 16 -


is modulated using 8DPSK. Data ACL 85 1 16 -



is‎modulated‎using‎π/4-DQPSK. Data ACL 369 3 16 -

23

Packet Description Applicati

on Link

Size

in

bytes

sl

o

ts

CRC

in

bits

F

E

C





is‎modulated‎using‎π/4-DQPSK. Data ACL 681 5 16 -



AUX1 Same as DH1 with no CRC Data ACL 30 1 - -

HV1 High-quality Voice Voice SCO 10 1 - 1/3

HV2 High-quality Voice Voice SCO 20 1 - 2/3

HV3 High-quality Voice Voice SCO 30 1 - -

DV Data Voice Combined packet Voice :

Data SCO

10 :

18.75 1 -

- :

2/3

EV3 eSCO Voice packet Voice &

Data eSCO 30 1 16 -

2-EV3 Similar to EV3 packet but payload

is modulated using‎π/4-DQPSK.

Voice &

Data eSCO 60 1 16 -


is modulated using 8DPSK.

Voice &

Data eSCO 90 1 16 -


Data eSCO 120 3 16 2/3


Data eSCO 180 3 16 -


is‎modulated‎using‎π/4-DQPSK.

Voice &



is modulated using 8DPSK.

Voice &


24

For transmitting voice HV or DV packets can be used. High quality Voice

(HV) packets do not have a CRC or payload header and are not retransmitted on

error, while DV is a data packet divided into a voice field of 80 bits and a data field

of 150 bits. The voice field is never retransmitted, while the data field is checked for

errors and is retransmitted if necessary.

2.2.1.3 Link Manager Protocol

The link manager protocol [4] is responsible for the creation, modification and

release of logical links. This protocol layer handles the issues of security like

authentication, encryption by generating, exchanging and checking the link and

encryption keys. It also deals with control and negotiations of the baseband packet

sizes, the adapting of the transmit power on the physical link and the adjustment of

the QoS settings.

2.2.2 Alternate MAC/PHY Controller

The Alternate MAC/PHY (AMP) Controller includes the Protocol Adaptation

Layer (PAL), AMP MAC and AMP PHY.

2.2.2.1 Protocol Adaptation layer

Protocol Adaptation Layer (PAL) Manager was added in the core specification

of version 3.0 as a special layer interfacing the AMP MAC with the Host. It

translates commands from the Host into the specific MAC service primitives and

primitives into commands and it translates primitives from the AMP MAC into

understandable event(s) for the Host. The AMP PAL provides support for AMP

channel management, data traffic and power efficiency. An independent PAL

Manager must exist for each alternative MAC/PHY.

2.2.2.2 AMP MAC

The AMP MAC is the alternative MAC layer. It provides services such as

addressing and mechanisms to control and access channels.

25

2.2.2.3 AMP PHY

The AMP PHY is the alternative physical layer.

2.2.3 Host Protocols

A number of host protocols exits in the Bluetooth protocol stack. In the

following sections a number of the most important protocols are described.

2.2.3.1 Logical Link Control and Adaptation protocol

Logical Link Control and Adaptation Protocol (L2CAP) [4] provides either

connection-oriented or connectionless service to the upper layers. It provides

protocol multiplexing, Quality of Service (QoS) communication and handles the

Segmentation and Reassembly (SAR) function. L2CAP permits higher level

protocols and applications to transmit and receive L2CAP data packets up to 64

kilobytes in length, with the default Maximum Transmission Unit (MTU) set to 672

bytes. Only ACL links providing best effort traffic are supported by the L2CAP

specification. L2CAP has no support for SCO links providing real-time voice traffic.

L2CAP was modified in the core specification version 3.0 to allow AMP

Manager Communication as well as the support of logical links over an alternative

MAC/PHY. Figure 2.8 illustrates the L2CAP PDU format on connection-oriented

channel while Figure 2.9 illustrates the L2CAP PDU format on connectionless

channel.

Figure ‎2.8 L2CAP PDU (B-frame) format on connection-oriented channels

Figure ‎2.9 L2CAP PDU (G-frame) format on the Connectionless channel

To support flow control, retransmissions and streaming, two more L2CAP PDU

types are defined. The information frames (I-frames) are used for information

transfer between L2CAP entities. The supervisory frames (S-frames) are used to

Length

(2 bytes)

Channel ID

(2 bytes)

Payload

(0 – 65535 bytes)

Length

(2 bytes)

Channel ID

(2 bytes)

Payload

(0 – 65533 bytes)

PSM

(2 bytes)

26

acknowledge I-frames. Figure 2.10 illustrates both frame formats (fields size are

represented in bits).

Figure ‎2.10 L2CAP PDU formats in Flow Control and Retransmission

Modes.

L2CAP does not provide any reliability and uses the baseband Automatic

Repeat Request (ARQ) to ensure reliability. Also, L2CAP is strictly link oriented and

cannot forward packets beyond one link since there is no concept of network wide

addressing within L2CAP. The Bluetooth Network Encapsulation Protocol (BNEP)

adds the networking functionality by utilizing the unique MAC address of each

Bluetooth interface.

2.2.3.2 Alternate MAC/PHY Manager Protocol

AMP Manager [4] was added in the core specification version 3.0. The

Alternative MAC/PHY Manager Protocol (A2MP) is used to communicate with a

peer AMP Manager on a remote device. The AMP manager is responsible for

discovering remote AMP(s) and determining their availability. It collects relevant

remote AMP(s) information. This information is used to set up and manage AMP

physical links. It also interfaces directly to the local AMP PAL for AMP control

purposes.

1. Packet Format

The AMP manager uses a dedicated L2CAP signalling channel to communicate

with remote AMP manager(s). Figure 2.11 illustrates the A2MP packet format and

Table 2.6 describes the different fields [4].

Length

(2 bytes)

Channel ID

(2 bytes)

FCS

(0 – 2 bytes)

Control

(2 or 4 bytes)

Supervisory frame (S-frame)

Length

(2 bytes)

Channel

ID

(2 bytes)

FCS

(0 – 2 bytes)

Control

(2 or 4 bytes)

Information frame (I-frame)

L2CAP SDU

Length

(0 or 2 bytes)

Payload

27

Figure ‎2.11 A2MP Packet Format

Table ‎2.6 A2MP Packet Fields

Field Size Description

Code 1 byte

The code identifies the type of packet. Packet code can be:

( AMP Command Reject, AMP Discover request, AMP

Discover response, AMP Change notify, AMP Change

response, AMP Get Info request, AMP Get Info response, AMP

Get AMP Assoc request, AMP Create Physical Link request,

AMP Create Physical Link response, AMP Disconnect Physical

Link request)

Identifier 1 byte

The Identifier field matches responses with requests. For each

A2MP channel an AMP manger shall use different identifiers

for each request sent.

Length 2 bytes The Length field indicates the size in bytes of only the data

field.

AMP Manager Protocol uses the AMP_Info and AMP_Assoc structures to

exchange the capabilities of the PAL and the underlying MAC/PHY. The AMP_Info

contains generic capabilities of the PAL such as bandwidth availability, maximum

PDU size, PAL capabilities, length of the AMP_Assoc and flush timeout

information. The contents of the AMP_Assoc are dependent on the PAL and are

related to the underlying MAC/PHY.

2. Procedures

The AMP manager defines a set of procedures [4] for discovering the remote

AMP(s) capabilities, collecting information and setting up connections.

AMP Discovery Procedures

The AMP Manager is responsible for discovering local AMP Controller(s) and

maintaining that list over time as AMPs may be added or removed dynamically from

Code

(1 byte)

Identifier

(1 byte)

Length

(2 bytes)

Data

28

the system. The local AMP Manager may request a list of AMPs from the remote

AMP Manager. After the list of AMPs has been requested by the remote device,

when an AMP is added or removed from the system, the local AMP Manager will

notify that remote AMP Manager of the change. Each AMP Is identified with an ID

and a type. Once the list of AMPs has been received, the AMP Manager may request

information (AMP_Info) for each AMP. AMP manager uses a dedicated L2CAP

channel to communicate with remote AMP manager(s).

Physical Link Creation Procedure

The AMP Manager provides the remote AMP information that it collected

about the remote AMP to the local AMP PAL. The local AMP PAL then uses this

information to create the AMP physical link. The physical link creation procedure [4]

is summarized in 4 steps as follows:

1) Host A uses the BR/EDR Controller to request AMP_Info data from Host B in

order to create an AMP connection. Host B gets this information from PAL B

using HCI Read Local AMP Info. Host B returns the information to Host A over

the BR/EDR radio. Step 1 is illustrated in Figure 2.12.

Figure ‎2.12 AMP Physical Link Creation Step 1

2) Host A sends an HCI Create Physical Link command to its AMP Controller.

AMP Controller A determines which channel will be used and provides channel

information to its Host. AMP Controller A joins or creates that channel. Step 2 is

illustrated in Figure 2.13.

Read Local AMP

ASSOC Command Complete

Command Complete Read Local AMP

Info

Host A PAL A PAL B Host B

Step 1: Host A starts Physical Link Creation

Host A uses the BR/EDR Controller to request AMP data from Host B

Host B uses the BR/EDR Controller to return the AMP data to Host A

29


3) Host A uses the BR/EDR radio to request a physical link to B. Host B tells its

AMP Controller to accept a physical link from Device A. Step 3 is illustrated in

Figure 2.14.


4) The AMP Controllers perform security operations. When the handshake is

complete, both devices inform their Hosts that the link is ready for use. Step 4 is

illustrated in Figure 2.15.

Command Complete

Write Remote AMP ASSOC

Command Status

Create Physical Link

Command Complete

Channel Selected

Read Local AMP ASSOC


Step 2: Host A tells its Controller to create a physical link to Device B

Controller A joins the selected

channel

Write Remote AMP ASSOC Command Complete

Command Status

Accept Physical Link


Step 3: Host A tells device B to accept an incoming physical link

Host A uses the BR/EDR Controller to tell Device B to accept a physical link

Controller B joins the selected channel

31


Physical Link Destruction Procedure

Host A sends a Physical Link Disconnect command to its AMP Controller.

AMP Controllers A and B sends the Physical Link Disconnect Complete event to its

host. Both devices can now leave the AMP channel.

Figure ‎2.16 AMP Physical Link Destruction procedure

Logical Link Creation Procedure

Once a physical link exists, L2CAP creates an AMP logical link with the

desired QoS. An L2CAP channel is then created over the logical link, at which point

the channel is ready for data communication.

Two types of logical links can be created: Guaranteed and Best Effort. For

creating a logical link Host A sends a Logical Link Create command to its AMP

Controller. AMP Controllers A and B send the Logical Link Creation Complete

PAL A

Physical Link Complete

Host A PAL B Host B

Step 4: A and B establish security

Establish handshake transport mechanism

A and B perform authentication handshake and

encryption key generation installation

Physical Link Complete

PAL A Host A PAL B Host B

Command Status

Physical Link Disconnect

Host A disconnect the physical link

A and B leave the channel

AMP Controllers perform AMP specific actions

Physical Link Disconnect Complete Physical Link Disconnect Complete

30

event to its host. Both devices can now pass data traffic over the AMP channel. The

procedure is illustrated in Figure 2.17.

Figure ‎2.17 Guaranteed Logical Link Creation Procedure

Logical Link Destruction Procedure

Host A sends a Logical Link Disconnect command to its AMP Controller.

AMP Controllers A and B do whatever AMP specific action is required to meet the

request. Each AMP Controller sends the Logical Link Disconnect Complete event to

its host. The procedure is illustrated in Figure 2.18.

Figure ‎2.18 Logical Link Destruction Procedure


Command Status

Logical Link Create

Command Status

Host A Create logical link to Host B

Logical link created between A and B

AMP Controllers A and B allocate bandwidth to the

new logical link

AMP Controllers use the BR/EDR controller to exchange connection

information Logical Link Accept

Logical Link Complete Logical Link Complete


Command Status

Logical Link Disconnect

Host A disconnect the logical link

No logical link between A and B

AMP Controllers perform AMP specific actions

Logical Link Disconnect Complete Logical Link Disconnect Complete

32

2.2.3.3 Bluetooth Network Encapsulation Protocol

Bluetooth Network Encapsulation Protocol (BNEP) [13] is used for

transporting both control and data packet over Bluetooth to provide networking

capabilities for Bluetooth devices similar to that of Ethernet. BNEP encapsulates

packets from various networking protocols using a common packet format, which are

then transported directly over the Bluetooth L2CAP link. BNEP packets can use

either the BR/EDR or the AMP controller.

1. BNEP Packet Format

BNEP replaces the Ethernet Header with the BNEP Header as shown in Figure

2.19. Then, both the BNEP Header and the Ethernet Payload are encapsulated by the

L2CAP and sent to the BR/EDR or the AMP controller.

The maximum payload that BNEP accepts from the higher layer is equal to the

negotiated L2CAP MTU (minimum value: 1691), minus 191 bytes reserved for

BNEP headers. BNEP is not required to pad payloads to the Ethernet minimum size

(46 bytes) as the minimum payload accepted by BNEP from the higher layer is zero.

Figure ‎2.19 BNEP with an Ethernet Packet payload sent using L2CAP

BNEP uses two types of headers BNEP_GENERAL_ETHERNET and

BNEP_CONTROL. The BNEP_GENERAL_ETHERNET packet type header is used

to carry Ethernet packets to and from Bluetooth networks. Figure 2.20 show the

BNEP_GENERAL_ETHERNET packet type header format and the fields are

described in Table 2.7.

Ethernet Header

(14 bytes)

Ethernet payload

(46 - 1500 bytes)

Ethernet Frame

L2CAP Header

(4 bytes)

Ethernet payload

(0 - 1500 bytes)

BNEP Header

(1 byte least)

BNEP Frame

33

0 4 8 12 16 20 24 28 31

BNEP Type =

0x00 E Destination Address (bytes 0-2)

Destination Address (bytes 3-5) Source Address (byte 0)

Source Address (bytes 1-4)

Source Address

(byte 5) Network Protocol Type

Extension Header or

Payload

Figure ‎2.20 BNEP_GENERAL_ETHERNET Packet Type Header

Table ‎2.7 BNEP_GENERAL_ETHERNET Packet Type Header Fields

Field Size in

bits Description

BNEP Type 7 Identifies the type of BNEP header contained in this packet.

Extension Flag (E) 1 Indicates if one or more extension headers follow the BNEP

Header before the data payload if the data payload exists.

Destination Address 48

48 bit Bluetooth BD_ADDR/IEEE address of the

destination of the BNEP packet/Ethernet frame contained in

the payload.

Source Address 48 48 bit Bluetooth BD_ADDR/IEEE address of the source of

the BNEP packet/Ethernet frame contained in the payload.

Networking Protocol

Type 16

Identifies the type of networking protocol contained in the

payload.

The BNEP_CONTROL packet type header is used to exchange control

information. Figure 2.21 show the BNEP_GENERAL_ETHERNET packet type

header format.

0 4 8 12 16 20 24 28 31

BNEP Type =

0x01 E BNEP Control Type Control Packet based on Control Type

Figure ‎2.21 BNEP_ CONTROL Packet Type Header

2.2.3.4 Service Discovery Protocol

Service Discovery Protocol (SDP) [4] is the basis for discovery of services on

all bluetooth devices. This is essential for all bluetooth models. Using the SDP

34

device information, services and the characteristics of the services can be queried and

after that a connection between two or more bluetooth devices may be established.

SDP uses a request/response model where each transaction consists of one

request PDU and one response PDU. Only one SDP request per L2CAP connection

to a given SDP server is allowed at a given instant until a response is received. Some

requests may however require responses that are larger than what can fit in a single

response PDU. To extend the response to more than a single response PDU, the SDP

server generates a partial response along with a continuation state parameter. All

SDP communications use only the BR/EDR controller.

2.2.3.5 Host Controller Interface

The Host Controller Interface (HCI) [4] provides a command interface to the

controllers and access to the hardware status and control registers. The Host control

transport layer abstracts away transport dependencies and provides a common device

driver interface to various interfaces. Three interfaces are defined in the core

specification: USB, RS-232 and UART.

2.3 Profiles

Profiles represent the default usage models. They may be thought of as a

vertical slice through the protocol stack. Each bluetooth device supports one or more

profiles.

There are four generic profiles [11] that are used by the different usage model

based profiles. These are serial port profile, generic access profile, service discovery

application profile and generic object exchange profile. While the profile may use

certain features of the core specification, specific versions of profiles are rarely tied

to specific versions of the core specification. Table 2.8 shows a brief overview of the

most common Bluetooth profiles.

35

Table ‎2.8 Bluetooth Profiles

Profile Name Description

Serial Port Profile (SSP) For setting up emulated serial cable connections using

RFCOMM between two peer devices.

Generic Access Profile (GAP)

Core on which all other profiles are based

Defines the generic procedures related to Bluetooth

device discovery and link management.

Service Discovery Application

Profile (SDAP)

Describes how an application should use SDP to discover

services on a remote device.

Generic Object Exchange Profile

(GOEP)

Works as a generic profile document for all application

profiles using the OBEX protocol.

Personal Area Networking profile

(PAN)

Allows the use of the BNEP as a layer 3 protocol for

sending Ethernet packets over a Bluetooth link.

File Transfer Profile (FTP)

Provides the capability to browse, manipulate and

transfer objects (files and folders) in an object store (file

system) of another system using OBEX.

Basic Imaging Profile (BIP)

Used for sending images between devices and includes

the ability to resize and convert images to make them

suitable for the receiving device.

Basic Printing Profile (BPP) Allows devices to send text, e-mails, or other items

to printers based on print jobs.

Video Distribution Profile (VDP) Allows the transport of a video stream.

2.4 Security

The security [11] is controlled by the lower layers of the Bluetooth protocol. A

first security level is assured by the fact that each Bluetooth module has a unique

BD_ADDR address (48-bits).

To achieve a real level of security, the Bluetooth system necessitates two secret

keys (authentication key and encryption key) as well as a random number generated

regularly.

36

In case of having device (A) wants to pair with device (B). For authentication,

device (A) sends a challenge to device (B) with which it wishes to connect itself.

Device (B) has to reply to the challenge by returning a response known for both

devices. After the authentication the link can be encrypted.

The piconet unique frequency hopping sequence also provides a built-in

security feature. Only those devices knowing the hopping sequence can decode the

data.

AMP security starts during the Secure Simple Pairing process. A 256-bit

Generic AMP Link Key is generated from the BR/EDR Link Key. The Generic AMP

Link Key is stored in the security database alongside the BR/EDR Link Key once

pairing has completed.

When an AMP is used for the first time, a dedicated AMP key is created by the

AMP Manager for that AMP type. The Dedicated AMP Link Key is sent to the PAL

during the Physical Link creation process. Each PAL is responsible for using the

Dedicated AMP Link Key during the security phase of the physical link

establishment process.

This is a simple introduction to securing the AMP channels though studying the

Bluetooth security features is beyond the scope of this research. The Bluetooth V3.0

specifications [4] volume 2 provides further details on the AMP security.

2.5 Interference Analysis

Coexistence between Wi-Fi and Bluetooth was studied in [14-16]. As Wi-Fi

uses a fixed frequency band of 22 MHz while Bluetooth hops between 79 bands each

of 1 MHz, there is a probability of 22/79 that a Bluetooth packet hops in the Wi-Fi

fixed frequency band leading to a collision. Using Adaptive Frequency Hopping

(AFH) helps reducing the collision probability where the Bluetooth devices avoid the

frequency bands used by the Wi-Fi devices.

In [14], It has been proved that Wi-Fi packets suffer most from the 1-slot

Bluetooth packets then 3 and 5 slots packets, so 5-slot packets are recommended

when Bluetooth coexist with Wi-Fi as this would lead to a reduction in the Bluetooth

hop rate, thus increasing the chances for a successful Wi-Fi packet reception.

37

Though, if Bluetooth hops to the Wi-Fi channel during back-off period, there is no

effect on Bluetooth packets.

Regarding the Wi-Fi data rates, it was found in [14] that with a small number of

Bluetooth nodes Wi-Fi high data rates can be used, but when Bluetooth piconets

increase, Wi-Fi high data rate modes have to be abandoned.

In [15], it was proved that using Bluetooth voice traffic may be the worst of all

interference cases causing a 65% packet loss for the Wi-Fi with a severe impact on

the Bluetooth voice leading to a packet loss of 8%. In [16], it was proved that the

minimum safe distance is 4 meters to minimize the interference effects on both

systems.

2.6 Summary

Bluetooth is a remarkable technology that has a wide market and a lot of

application. This chapter has navigated through the development phases of

Bluetooth, described the modifications and enhancements added to increase the

usability, the security and the supported applications.

Several points have been covered in this chapter. BluetoothV3.0 protocol stack,

radio characteristics and the Bluetooth network structure. Different protocols at the

BR/EDR controller, AMP Controller and Host have been represented along side with

the relevant Bluetooth profiles. Bluetooth security features have been also

introduced. A literature based analysis of the interference effect of Bluetooth

technology on other ISM band technologies has been presented as well in this

chapter.

In the next chapter, different AMP candidate technologies are discussed and

compared. Alongside a number of previous researches are presented.

Chapter

3 Candidate Technologies for the

Alternative Controller

39

Chapter 3

Candidate Technologies for the Alternative

Controller

The new digital homes must support the battery power mobile life style which

demands the support of multiple high rate streams while consuming very little power.

BluetoothV3.0+HS core specification introduced the ability to add an alternative

controller to provide higher transmission rates.

In this chapter, two candidate MAC/PHY technologies are introduced including

their various implementations. This chapter is organized into five sections. Section 1

introduces the IEEE802.11 family including IEEE802.11g, IEEE802.11e EDCA and

IEEE802.11n. Section 2 introduces the Ultra Wide Band (UWB) technology with its

different implementations. Section 3 compares the three technologies in term of data

rate, support of multiple high rate streams, energy consumption and interference

introduced to other ISM band systems. Section 4 goes through previous work done

using different alternative controller. Finally section 5 summaries the chapter.

3.1 IEEE 802.11 Family

IEEE 802.11 [17] is the most mature, widely used wireless protocol in the

unlicensed ISM band for Wireless LAN communications. IEEE 802.11 operates in

the 2.4 and 5 GHz frequency bands. As all IEEE 802 protocols, IEEE 802.11 covers

the lower layers of the OSI model and specifies the Physical and the Medium Access

Control Protocol (MAC).

A number of versions of IEEE802.11 have been release over time to increase

the provided throughput and to provide a better quality of service. The IEEE802.11

family now includes 802.11a/b/g/e/n, in the following sections we are going to go

through the history of IEEE802.11 and the standardization efforts, its technical

details and the different updates made.

41

3.1.1 Standardization Efforts

Definition of the IEEE 802.11 started in 1990 and the first version of the

standard was almost finalized by mid 1996. In 1997, the IEEE validated the initial

802.11 specifications as the standard for Wireless LANs. The first version of 802.11

provided for 1–2 Mbps data rates, fundamental signalling methods and services.

3.1.2 IEEE 802.11 Physical layer

The IEEE 802.11 physical layer [17] is divided into two sub-layers: the

Physical Layer Convergence Procedure (PLCP) and the Physical Medium Dependent

(PMD). The PLCP receives incoming MAC Service Data Units (MSDUs) from the

MAC sub-layer, adds its own designated header and then gives them to the PMD. It

is mandatory for delivered information to have a preamble, which has a pattern that

depends on the modulation technique deployed in the physical layer. The PMD is

responsible for transmitting every bit it receives from the PLCP over the wireless

medium. The operational range of IEEE 802.11 is limited to 100 meters.

The 802.11 standard defines two types of physical layers: Spread Spectrum

(SS) based physical layers and Orthogonal Frequency Division Multiplexing

(OFDM) based physical layers.

3.1.2.1 Spread Spectrum based physical layers

The Spread Spectrum based physical layers include three physical layer

specifications: Direct-Sequence Spread Spectrum (DSSS), Frequency Hopping

Spread Spectrum (FHSS) and infrared (IR). In practice, only the first two, DSSS and

FHSS, are present in the market.

1. Direct-Sequence Spread Spectrum

In the Direct Sequence Spread Spectrum (DSSS) technique, the 2.4-GHz band

is divided into 14 channels of 22 MHz each as illustrated in Figure 3.1. Adjacent

channels partially overlap one another and only three are completely non-

overlapping. Data is sent across one of the channels without hopping to other

channels. The user data are modulated by a single, predefined wideband-spreading

signal. The receiver knows this signal and is able to recover the original data [11].

40

Figure ‎3.1 IEEE802.11 DSSS channels

2. Frequency Hopping Spread Spectrum

In the Frequency Hopping Spread Spectrum (FHSS) technique, the 2.4-GHz

band is divided into a large number of sub-channels. The communication endpoints

agree on the frequency hopping pattern and data is sent over a sequence of the sub-

channels. The transmitter sends data over a sub-channel for a fixed length of time

(dwell time= 0.4 sec), then changes frequency according to the hopping sequence

and continues transmission. Hopping process should take no longer than 224 μsec.‎

As the dwell time is rather long, the transmitter can send multiple symbols at the

same frequency. FHSS techniques allow for a relatively simple radio design, but are

limited to speeds of no higher than 2 Mbps. This limitation driven primarily by FCC

regulations that restrict sub-channel bandwidth to 1 MHz leads to hopping overhead.

3.1.2.2 Orthogonal Frequency Division Multiplexing based physical

layers

Orthogonal Frequency Division Multiplexing (OFDM) is a digital multicarrier

modulation scheme which deploys a large number of closely spaced orthogonal

subcarriers. Each subcarrier is modulated with a conventional modulation scheme. In

practice, OFDM signals are generated by the use of the Fast Fourier transform (FFT)

algorithm.

The most important advantage of OFDM over single-carrier schemes is its

ability to cope with multipath and narrowband interference without complex

equalization filters. Channel equalization is simplified due to the fact that OFDM

may be viewed as using many slowly modulated narrowband signals rather than one

rapidly modulated wideband signal. On the other hand, OFDM necessitates a high

level of accuracy in frequency synchronization between the receiver and transmitter.

Channel

Center frequency

(GHz)

1

2.412

2

2.417 6

2.437

11

2.462

13

2.472

22 MHz

42

3.1.3 IEEE 802.11 Medium Access Control Schemas

The 802.11 standard defines two schemas for medium access: Distributed

Coordination Function (DCF) and Point Coordination Function (PCF).

3.1.3.1 Distributed Coordination Function

The primary medium access scheme in IEEE 802.11 MAC is the distributed

coordination function (DCF), a contention-based protocol which is based on the

Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) protocol.

CSMA/CA is used to avoid collisions by using explicit packet acknowledgment

(ACK) and back off timers. Collision Avoidance is used to

improve CSMA performance by not allowing wireless transmission of a node if

another node is transmitting.

In the DCF, mobile terminals should contend for the shared wireless channel

and as a result, the medium access delay for each station cannot be bounded in

heavy-traffic-load circumstances. Thus, the DCF is capable of offering only

asynchronous data transmission on a best effort basis.

3.1.3.2 Point Coordination Function

In order to support real-time traffic such as voice and video, the point

coordination function (PCF) scheme has been advised as a non-compulsory option.

Basically, the PCF is based on a centralized polling scheme for which a point

coordinator residing in an access point provides contention-free services to the

associated stations in a polling list. PCF is only available in the infrastructure mode.

In infrastructure mode, an Access Point (AP) periodically sends beacon, between

these beacon frames, PCF defines two periods: the Contention Free Period (CFP) and

the Contention Period (CP). In the CP, DCF is used. In the CFP, the AP sends

Contention-Free-Poll (CF-Poll) packets to each station, one at a time, to give them

the right to send a packet.

43

3.1.4 IEEE802.11 Updates

IEEE802.11 has undergone a lot of changes and enhancements since the release

of the first version in 1999. Enhancements have been made to the physical layer and

to the medium access layer in order to provide support to QoS applications, reduce

interference and enhance the throughput. In the following subsections a number of

IEEE802.11 updates are introduced.

3.1.4.1 IEEE802.11a

The IEEE802.11a amendment to the original standard was ratified in

September 1999 [18]. IEEE802.11a operates in the 5-GHz band, divides the

bandwidth to 12 non-overlapping 20MHz channels, 8 dedicated to indoor and 4 to

point to point and uses a 52-subcarrier OFDM with a maximum raw data rate of 54

Mbps. Out of the 52 OFDM subcarriers, 48 are for data and 4 are pilot subcarriers.

Each of these subcarriers can be modulated using Binary Phase Shift Keying

(BPSK), Quadratic Phase Shift Keying (QPSK), 16-QAM, or 64-QAM. DCF and

PCF schemas are used for medium access.

Operating in the 5-GHz band gives 802.11a the advantage of less interference.

However, this high carrier frequency restricts the use of 802.11a to almost line of

sight and makes it not compatible with the other IEEE802.11 versions.

3.1.4.2 IEEE802.11b

In 1999, IEEE enhanced the 802.11 to 802.11b [19] standard, which is able to

support transmissions of up to 11 Mbps, comparable to the wired 10 Mbps Ethernet

(10BaseT). IEEE802.11b operates in the 2.4GHz band and is considered as a direct

extension of the DSSS modulation technique. To increase the data rate, 802.11b

specifies an advanced coding technique called Complementary Code Keying (CCK)

instead of the default 11-bit Barker word. CCK consists of a set of 64 code words, 8-

bit long, which can be distinguished by the receiver even in the presence of noise or

interference. The CCK encodes 4 bits per carrier to achieve data rate 5.5 Mbps and 8

bits per carrier to achieve 11 Mbps. Both speeds use QPSK modulation and 1.375

Msps symbol rate. DCF and PCF schemas are used for medium access.

44

3.1.4.3 IEEE802.11g

Ratified in 2003, IEEE802.11g [6] operates in the 2.4-GHz band. OFDM

modulation scheme is used in IEEE802.11g for the data rates of 6, 9, 12, 18, 24, 36,

48 and 54 Mbps. It reverts to CCK to achieve 5.5 and 11 Mbps and switches to

DBPSK/ DQPSK+DSSS for 1 and 2 Mbps. Same as IEEE802.11a/b DCF and PCF

schemas are used for medium access.

IEEE 802.11g is the current alternative controller technology for Bluetooth as

specified in the BluetoothV3.0+HS specifications.

3.1.4.4 IEEE802.11e

IEEE802.11e [20] is a proposed enhancement to the IEEE802.11a/g

specifications. IEEE802.11e can operate at radio frequencies between either of two

ranges: 2.400 GHz to 2.4835 GHz (the same as 802.11b networks), or 5.725 GHz to

5.850 GHz (the same as 802.11a networks). It offers quality of service (QoS)

features, including the prioritization of data, voice and video transmissions.

IEEE802.11e enhances the DCF and the PCF, through a new coordination function:

the hybrid coordination function (HCF). Within the HCF, there are two methods of

channel access, similar to those defined in the legacy IEEE802.11 MAC: HCF

Controlled Channel Access (HCCA) and Enhanced Distributed Channel Access

(EDCA). For achieving QoS, IEEE802.11e uses multiple queues for the prioritized

and separate handling of different traffic categories (TCs), where a separate back-off

parameter is set for each priority queue.

1. Enhanced Distributed Channel Access

With EDCA, high priority traffic has a higher chance of being sent than low

priority traffic: a station with high priority traffic waits a little less before it sends its

packet, than a station with low priority traffic.

In addition, EDCA provides contention-free access to the channel for a period

called a Transmit Opportunity (TXOP). A TXOP is a bounded time interval during

which a station can send as many frames as possible. If a frame is too large to be

transmitted in a single TXOP, it should be fragmented into smaller frames.

45

2. Hybrid Coordination Function Controlled Channel Access

The Hybrid Coordination Function (HCF) Controlled Channel Access (HCCA)

is similar to the PCF. However, in contrast to PCF, in which the interval between two

beacon frames is divided into two periods of CFP and CP, the HCCA allows for

CFPs being initiated at almost any time during a CP. This kind of CFP is called a

Controlled Access Phase (CAP) in 802.11e. A CAP is initiated by the AP whenever

it wants to send a frame to a station or receive a frame from a station in a contention-

free manner.

In addition to the enhanced channel access methods, IEEE802.11e provides two

additional acknowledgment methods: Block Acknowledgments and No

Acknowledgment. Block Acknowledgments which allows an entire TXOP to be

acknowledged in a single frame, this will provide less protocol overhead when longer

TXOPs are specified. No Acknowledgment which avoids retransmission of highly

time-critical data.

3.1.4.5 IEEE802.11n

IEEE802.11n [21] published in 2009 is a recent enhancement for

IEEE802.11a/g to improve the network throughput with a significant increase in the

maximum raw data rate from 54Mbps to 600Mbps. IEEE802.11n introduces the use

of multiple-input multiple-output antennas (MIMO) and the ability to double the

channel width to 40MHz. IEEE802.11n implements the Block Acknowledgment as

in IEEE802.11e.

MIMO antennas support multipath transmission with a technique known as

Space Division Multiplexing (SDM). The wireless terminal basically splits a data

stream into multiple concurrent divisions, called spatial streams and delivers each

one of them through separate antennas to corresponding antennas on the receiving

end providing a higher data rate and a wider coverage. The current 802.11n draft

provides up to four spatial streams. Each spatial stream requires a discrete antenna at

both the transmitter and the receiver. Doubling the number of spatial streams from

one to two effectively doubles the raw data rate. There are trade-offs, however, such

as increased power consumption and cost.

46

3.2 Ultra Wide Band

In February 2002 the FCC issued a Report and Order in which a definition for

UWB transmission is proposed. UWB transmission is defined as any signal with a

fractional bandwidth Bf larger than 0.20 or which occupies a bandwidth greater than

500 MHz, fractional bandwidth is defined as the ratio of channel bandwidth to the

central frequency [22] and is given by

2)( =WB

=B

LfHf

LfHf

cff

(3.1)

where, Bf is the fractional bandwidth

BW is the channel bandwidth

fc is the central frequency

fH and fL are respectively defined as the highest and lowest

frequencies in the transmission band.

To avoid interference with existing communication systems, the FCC has

assigned the Effective Isotropic Radiated Power (EIRP) to –41.3 dBm/MHz (75

nW/MHz) in the unlicensed frequency band between 3.1–10.6 GHz for UWB indoor

communications [22], which is in fact at the unintentional radiation level of

television sets or monitors. In other words, UWB signalling is reusing the noise floor

for communication. The limitation of power limited the UWB range to 10 meters.

The regulations differ from country to another, some of which require detect-and-

avoid strategies in the UWB transmitter. In the Detect-and-Avoid strategy, the UWB

transmitter avoids a channel if it detects that this channel is being occupied by

another wireless technology. Across these regulations only the band from 7.25-8.5

GHz is common [10]. Figure 3.2 from [10] summarizes the bands in which UWB

wireless communication is allowed in different regions.

47

Figure ‎3.2 UWB bands for different regions.

3.2.1 Standardization Efforts

In an attempt to establish standards to provide compliance between different

high-rate WPAN devices, IEEE Standards Committee created the IEEE802.15.3

Task Group which led to the IEEE802.15.3 standard. There were two proposals after

nearly three years of wrangling over which physical layer should form the basis of

the IEEE802.15.3 standard, the Multi Band Orthogonal Frequency Division

Multiplexing (MB-OFDM) standard [23] and Direct Sequence (DS) UWB standard

[24]. On January 19, 2006, the IEEE802.15.3 committee, voted unanimously to

disband and to let the market decide which UWB Physical layer will become the

standard [10]. While the IEEE 802.15.3 Task Group has failed to establish a standard

for UWB, MB-OFDM was adopted by the WiMedia Alliance for certified Wireless-

USB [25] and released ECMA-368 High Rate Ultra Wideband PHY and MAC

Standard [26] and ECMA-369 MAC-PHY Interface for ECMA-368 standard [27].

DS-UWB was supported by the UWB Forum.

3.2.2 Physical Layer

UWB signals can support low-power due to the use of narrow pulses in time

and high-rates‎ due‎ to‎ the‎ large‎ bandwidth‎ available.‎ According‎ to‎ Shannon’s‎

4.75 10.6

4.8 6.0 9.0

7.2 10.2

7.25 10.25

6.0 8.5

6.0 9.0

3.1 10.6

4.2

3.1 4.8

3.4 4.8

4.2 4.8

3.4 4.2 4.8

3.1 3.6 4.6 5.6 6.6 7.6 8.6 9.6 10.6

Year

2009

2009

2006

2005

2004

2003

2002

Frequency (GHz)

Detect and Avoid Unrestricted

Canada

China

S. Korea

Japan

Europe

Singapore

US

48

capacity formula, this large bandwidth provides a very high capacity. Thus, high

processing gains can be achieved that allow the access of a large number of users to

the system. At the physical layer, the implementation of a UWB system can be

achieved by using Multi Band (MB) OFDM or Impulse Radio (IR) [10].

3.2.2.1 Multi Band Orthogonal Frequency Division Multiplexing

In Multi Band Orthogonal Frequency Division Multiplexing (MB-OFDM), the

UWB spectrum is divided into 14 non-over lapping sub-bands with a 528MHz

bandwidth each as illustrated in Figure 3.3 from [10]. Information is transmitted

using OFDM with Quadratic Phase Shift Keying (QPSK) modulation in different

frequency sub-bands according to a specific time-frequency code (TFC). Only 13

bands are used to avoid interference between UWB and the existing IEEE802.11a

signals. The three lower bands are used for standard operation, which is mandatory

and the rest of the bands are allocated for optional use or future expansions [26].

Inverse fast Fourier transformer (IFFT) is used leading to a slightly complex

transmitter. The proposed WiMedia physical layer for UWB [26] supports variable

data rates up to 480Mbps. The desired range is 10 meters for 110 Mbps and 2 meters

for 480 Mbps.

Figure ‎3.3 MB-OFDM Bands defined by ECMA-368.

Linde [28], implemented a Bluetooth over WiMedia OFDM UWB test bed and

reported that the throughput shows a dramatic decay at distances over 2 meters. More

details on this experiment can be found in section 3.4.1.

3.2.2.2 Impulse Radio

In Impulse Radio UWB (IR-UWB), the UWB spectrum is divided into 2 non-

overlapping sub-bands, lower band (3.1 - 4.85GHz) and higher band (6.2 - 9.7 GHz).

Band

#1

Band

#2

Band

#3

Band

#4

Band

#5 Band

#6

Band

#7

Band

#8 Band

#9

Band

#10

Band

#11

Band

#13

Band

#14

Band

#12

Band Group #1

Band Group #6

Band Group #2 Band Group #3 Band Group #4

3.432 3.960 4.488 5.016 5.544 6.072 6.600 7.128 7.656 8.184 8.712 9.240 9.768 10.296

Center Frequency (MHz)

Band Group #5

49

The frequency range (4.85 – 6.2 GHz) is not used to prevent interference with

IEEE802.11a. Information is transmitted by sending narrow time-domain pulses,

typically in the order of a nanosecond as illustrated in Figure 3.4 from [10]. IR-UWB

can support data rates up to 1.3Gbps for 2 meters range [10].

IR-UWB transmits information using Pulse Amplitude Modulation (PAM),

ON–OFF Keying (OOK), or Pulse Position Modulation (PPM). PPM signals are less

sensitive to channel noise compared to PAM signals. However, the main

disadvantage of PPM is its sensitivity to timing synchronization [10].

3.2.2.3 Analysis of the Different Physical Layers

The MB-OFDM approach has been primarily used for applications such as

streaming video and wireless USB with data rates of 480Mb/s. Because of the high-

performance electronics required to operate a MB-OFDM UWB radio, these systems

Figure ‎3.4 IR UWB pulse (Left: Time domain and Right: Frequency

domain).

51

generally‎don’t‎target‎the‎energy‎constrained‎applications.‎IR-UWB radios, however,

can be designed with relatively low-complexity and low-power consumption. They

therefore are very applicable to the energy constrained short-range wireless

applications including WPANs, low-power sensor networks and wireless body-area-

networks [29].

Both MB-OFDM and IR-UWB technologies have pros and cons for

communications in a multipath propagation environment. MB-OFDM offers

robustness to narrowband interference by adaptive selection of the sub-bands, thus

achieving good coexistence properties in an uncoordinated environment, spectral

flexibility and efficiency, but it requires a slightly complex transmitter [30]. IR-UWB

is a carrier-less baseband radio technology and accordingly, no mixer is needed.

Therefore, the implementation of such a system is simple, which means that low cost

transmitters/receivers can be achieved [29]. However, IR-UWB very short pulse

duration poses a significant challenge on synchronization, thus requiring a very long

acquisition time. In addition, to suppress narrowband interference, notch filters need

to be employed which would require additional complexity to compensate the

distortion of the pulses caused by the notch filters. IR-UWB also requires high speed

analog-to-digital converters (ADCs) for signal processing.

3.2.3 Medium Access Control Schemas

For the MB-OFDM UWB, WiMedia ECMA-368 standard [26] states that there

is a super-frame structure, each of which lasts 65,536 milliseconds. The super-frame

is divided into 256 Media Access Slots (MAS), each of which has 256 microseconds.

The first 32 MAS slots are used for Beacon Period (BP) and contractible and the

remaining slots are for Data Transfer Period (DTP), in which two MAC protocols are

supported: contention-based Prioritized Channel Access (PCA) and contention-free

Distributed Reservation Protocol (DRP). DRP can negotiate and reserve MAS slots

for exclusive access in a distributed manner without any centralized controller and

the non-DRP slots are available for PCA, which is similar to IEEE 802.11e EDCA

[31]. Along with the WiMedia MAC standard, any traditional OFDM-based MAC

mechanisms can be smoothly applied to MB-OFDM UWB.

For IR-UWB two different schemas exists, Direct Sequence UWB (DS-UWB)

and Time Hopping UWB (TH-UWB). Both schemas spread the signals over a very

50

wide bandwidth. Because of the spreading, the IR-UWB can combat interference

from other sources. For DS-UWB, the transmission of each link is spread by a

pseudorandom sequence and the receiver de-spreads the received signal and recovers

the original information. The spreading allows several independently coded signals

to be transmitted simultaneously over the same frequency band. In DS-UWB,

simultaneous transmissions always interfere, which requires finding low cross-

correlation spreading sequences. An assignment protocol must be used as the

spreading‎sequences‎can’t‎be‎computed‎on‎the‎fly.‎For‎TH-UWB, each link transmits

one pulse per frame, based on a distinct pulse-shift pattern called a Time Hopping

Sequence (THS). Multiple-access can be achieved if each link uses an independent

pseudorandom THS. By using the node MAC address as a seed, nodes can compute

the spreading sequences on the fly, thus no assignment protocol is needed [32].

A comparison between different UWB medium access schemas in terms of Bit

Error Rate (BER), throughput and energy efficiency for a crowded indoor single-hop

environment is presented in [33]. The comparison results showed that TH-UWB

provides a better overall performance than MB-OFDM which in turn provides a

slightly better performance than DS-UWB.

In literature, a number of attempts were made to port a narrowband MAC

protocol to work over UWB. If we take for example CSMA/CA as being one of the

most popular MAC protocols for WLANs or ad hoc networks. In a neighborhood,

only one transmission is allowed; otherwise, collisions will happen. Such single-

channel protocols are not suitable for UWB WPANs because the inherent spread

spectrum in UWB allows two or more simultaneous transmissions in a neighborhood

as long as different pseudorandom sequences are applied. In such a multichannel

case in UWB WPANs, the transmissions of two nodes only generate interference to

each other.

The design requirements for an efficient IR-UWB MAC that can allow all users

to efficiently share the media spectrum range and to mitigate the induced interference

were studied in [29, 34]. A number of UWB MAC protocols were discussed and

compared. It was concluded that the unique nature of UWB technology requires a

MAC with additional features not observed in the existing MAC protocols for

narrowband wireless communications. The requirement for strict synchronization

between transmitter and receiver, precision timing, long acquisition time [35] and

52

low power operation constraint for coexistence with other narrowband networks

necessitates the development of a MAC optimized to take advantage of these

properties.

3.2.4 Interference Analysis

Coexistence between narrow band technologies and UWB was studied in [36].

In this study, high power IR-UWB transmitters that greatly exceed the FCC radiation

regulations have been used. It was found that both Wi-Fi and Bluetooth networks

will slightly suffer only at high proximity from the UWB signals (<10cm).

Otherwise; there is no effect on their signals. Also it was found that Wi-Fi channels 1

and 5 are less affected by UWB signal than channels 9 and 13.

Different strategies exist for interference mitigation, including rate adaptation,

transmitted power control and mutual exclusion or a combination of them.

3.2.4.1 Rate Adaptation

Often, the transmission rate is adapted as a function of the channel condition

(essentially the attenuation) between the source and the destination. However, the

rate can also be adapted as a function of the interference created by other devices in

the network. The rate is often adapted based on feedback from the destination.

3.2.4.2 Transmitted Power Control

The transmission power can be adjusted to keep the signal-to-interference-and-

noise ratio (SINR) at the destination above a given threshold for reliable decoding. It

is also used to minimize the amount of interference created on the neighbours.

Contrary to rate control, power control requires interaction with other devices in the

network. If a source increases its transmission power, it will create more interference

on concurrent receivers. Hence, a source needs to know not only the minimum power

required by its destination to ensure proper signal detection and decoding but also the

maximum interference that ongoing transmissions in the vicinity of the transmitter

can tolerate.

53

3.2.4.3 Mutual Exclusion

A mutual exclusion protocol prevents nodes from transmitting at the same time.

Most traditional protocols use mutual exclusion to manage interference. It is often

implemented by control packet signalling.

3.3 Technologies Comparison

In Table 3.1, a comparison is made between the different candidates introduced

in the previous sections.

Table ‎3.1 Candidate Technologies Comparison

Family Technology Band

(GHz)

Channel

Bandwidth

(MHz)

Modul-

ation

Through-

put

(Mbps)

Energy

consumption Interference

IEEE

802.11

802.11g [6] 2.4 20 OFDM 54 Moderate Moderate

802.11e[20] 2.4 20 OFDM 54 Moderate Moderate

802.11n[21] 2.4 or 5 40 OFDM 600 High High

UWB

OFDM[10] 3.1 - 10.6 528 QPSK 480 Low Low

IRUWB[10]

3.1 - 4.85

or

6.2–9.7

1750

or

3500

BPM 1320 Low Low

From the table above, we can see that UWB out performs all of the IEEE802.11

versions in terms of raw data throughput, energy consumption and introducing

interference to other ISM band technologies.

3.4 Previous Work

Studies were made in [28, 37, 38] to evaluate the performance of UWB as a

Bluetooth controller to provide high rates to support high-rate applications. In the

three studies, WiMedia MB-OFDM UWB was used though studies in [28, 33]

clearly states that MB-OFDM‎systems‎generally‎don’t‎target‎the‎energy‎constrained‎

applications.

54

3.4.1 Bluetooth V3.0 over WiMedia UWB Linux Driver

In [28], the authors used two IO Gear GUWA100U Wireless USB Host

Adapter dongles containing the Intel Wireless UWB Link 1480 Ultra Wideband

MAC that is supported by the open source Linux UWB driver. Drivers were then

modified to enable UWB communication between them and applied them as a real

UWB physical link for the Bluetooth over UWB system. The open source BlueZ

Linux Bluetooth protocol files were then modified. The HCI commands sent to the

HCI sub-layer by upper layer L2CAP and SCO implementations were hijacked and

routed to a UWB Router implementation for transmission over a UWB sub-system.

Similarly lower level HCI events were spoofed to the L2CAP and SCO layers by the

UWB Router implementation upon receiving packets from the UWB subsystem.

The authors studied the effect of the packet size and distance between nodes for

asynchronous and isochronous data on the throughput using a single connection in

their experiments. UWB showed a 50 fold increase in bandwidth for different packet

sizes than that of the Bluetooth system at distances less than 2.5 meters. The

performance of the developed system then showed a dramatic loss of bandwidth at

transmission distances above 2 meters. The authors justified this loss of bandwidth to

an ineffective or faulty introductory hardware or the inefficient unreleased firmware

obtained from Intel Corporation without any guarantees.

3.4.2 Video Transmission using Bluetooth V3.0 over

WiMedia UWB

In [37], authors propose a dual-mode Bluetooth system which uses both a

legacy Bluetooth module for low-speed communication and an alternative WiMedia

UWB module for high-speed Bluetooth communication. They modified the legacy

Bluetooth profiles for high definition video transmission and developed UWB

system on a chip that can be used for high speed Bluetooth communication.

This system was then evaluated by sending MPEG-2 transport stream high

definition video streams from the source to the sink side over a distance of 1 meter.

An average transmission speed of 19 Mbps was achieved.

55

3.4.3 Bluetooth V3.0 over WiMedia UWB Verse Certified

Wireless USB

In [38], a comparison was made between Bluetooth over WiMedia UWB and

the Certified Wireless USB (CW-USB). The authors studied the effect of the payload

size and application rate on the throughput using a single connection in their

experiments. The authors concluded that BluetoothV3.0 over UWB protocol has a

number of advantages over CW-USB which include higher throughputs, power

efficiency, easier device discovery and pairing, support for user-data broadcast, less

overhead, support for dedicated profiles and scope for better mobile market

penetration.

The analysis shows that the difference between Bluetooth over UWB and CW-

USB in term of attainable throughput increases as data rates increase. The difference

is minimum (1.1916 Mb/s) for a bit-rate of 53.3 Mb/s and maximum (57.3 Mb/s) for

480 Mb/s data rate in the favor of Bluetooth over UWB. The difference in the

attainable throughput is caused by the less overhead introduced by the Bluetooth

over UWB system than that by the CW-USB system.

The study also shows that Bluetooth over UWB suffers from a longer

connection setup time and higher cost. The longer connection time is justified by the

support of a number of device association mechanisms and Secure Simple Pairing

(SSP) to simplify the device pairing procedure and maintain security. The higher cost

is due to that there would be two radio controllers in Bluetooth over UWB which

enhances the performance.

3.4.4 Comments

None of the previous studies evaluated the energy efficiency of using UWB as

a Bluetooth controller, none considered the effect of collision and interference on the

outcome in case of having more than a single connection at a time and none

evaluated the performance at different traffic rates.

In this study, we fill those gaps and provide a full picture of the performance of

UWB as a Bluetooth controller for low and high traffic rates at different distances

and different number of interfering nodes.

56

3.5 Summary

In this chapter, two candidate MAC/PHY technologies are introduced and

analyzed to find out which would fit the best in meeting the demands for supporting

multiple high rate streams while consuming very little power with minimum

interference to other ISM band systems.

It was found that, while IEEE802.11g is the currently used technology in the

BluetoothV3.0+HS core specification, IEEE802.11g can support higher data rates

than that of bluetooth but at the cost of depleting the battery faster. IEEE802.11g/e

also‎can’t‎meet‎the‎need‎for‎supporting‎multiple‎high‎rate‎streams.‎IEEE802.11n‎on‎

the other hand can support multiple high rate streams but at a very high power

consumption and interference cost.

UWB can support high data rates, very small interference to the other ISM

band systems and very low power consumption. WiMedia UWB was considered by

the Bluetooth SIG but was then discarded due to some legal issues regarding the

intellectual property of the WiMedia UWB. Other UWB technology suffers from a

lack of published standards.

In the next chapter, detailed description of the proposed alternative controller is

presented.

Chapter

4 A Proposed Alternative Controller

58

Chapter 4

A Proposed Alternative Controller

Bluetooth is a widely-used short-range wireless communications system

intended to replace the cables connecting portable battery powered devices. The key

features of Bluetooth are robustness, low power and low cost.

The current Bluetooth radio technology only allows low transmission rates

making it inefficient for high rate applications running on battery powered devices.

To be able to use Bluetooth for all kinds of applications, an alternate controller is

needed. The alternate controller must provide consistent high data rates across

multiple devices, low power consumption for high and low rate applications, fair

medium access and minimum interference with the existing Bluetooth nodes and

other ISM band technologies.

An alternate Bluetooth controller consists of physical layer, MAC protocol and

a protocol adaptation layer (PAL). In chapter 3, a survey is illustrated covering two

candidate technologies; IEEE802.11 and Ultra Wide Band (UWB). In this survey the

two technologies are introduced including their various implementations. Those

technologies are then compared and the comparison is summarized in table 3.1.

From the survey done in chapter 3, it was found that UWB technology is

promising in terms of providing high-rates, low-power and mitigation to interference.

This meets the demands of the future digital homes battery powered devices coping

with the new mobile life style. UWB allows connecting multiple devices in a short-

range network, supporting multiple high data rate streams, consume very little power

and maintain low cost, while fitting into a very small physical package (chip size =

40mm × 100mm & thickness: 0.8mm [39]).

UWB lacks the Bluetooth profiles support, Bluetooth easy setup and Bluetooth

energy efficiency at low application data rates. The usage of UWB technology in a

Bluetooth alternative controller would eliminates those shortcomings and provides a

better usage model for UWB. The usage of UWB in a Bluetooth alternative

controller would also allows Bluetooth to transmit at higher rates and higher power

efficiency than that of the current alternative controller based on IEEE802.11g.

59

In this chapter, an alternative controller based on the UWB technology is

proposed and its components are represented. The survey of the different UWB

implementations illustrated in chapter 3 is used in this chapter to select the most

appropriate UWB implementation. which is the one that closely meets the goals

specified in the problem statement.

This chapter is organized into four sections. Section 1 provides a detailed

description of the selected physical layer for the proposed controller and the reasons

behind this selection. Section 2 presents the selected MAC protocol for the proposed

controller and the reasons behind this selection. Section 3 introduces the UWB PAL

parameters and structures created to allow the communication between the Bluetooth

and the proposed controller. Section 4 summarizes the chapter.

4.1 Physical Layer

In section 3.2.2.3, an analysis of the different UWB physical layers was made.

The analysis included the Multi Band Orthogonal Frequency Division Multiplexing

(MB-OFDM) and Impulse Radio (IR) approaches. From the analysis, it was found

that the MB-OFDM approach has been primarily used for high rate applications but

because of the high-performance electronics required to operate a MB-OFDM UWB

radio,‎these‎systems‎generally‎don’t‎target‎the‎energy‎constrained‎applications‎[29].‎

IR-UWB radios, however, can be designed with relatively low-complexity and low-

power consumption. Therefore IR-UWB is very applicable to the energy constrained

devices. It was also found that MB-OFDM can reach raw data rate of 480Mbps while

IR-UWB can reach raw rates up to 1.3Gbps [10].

4.1.1 Technology Selection Criteria

While IR-UWB can provide a higher raw data rate and a less complex with

lower power consumption solution, IR-UWB lacks the existence of published

specification or market products. In studies like [28, 37, 38], MB-OFDM was used

because of the availability of a market product based on an existing specifications by

WiMedia [26, 27]. Though in our study, IR-UWB is selected because of its potential

in meeting the demands of high rate applications running on battery powered devices

regardless the existence of published standards.

61

While IR-UWB specifies the way the signal is being transmitted, two physical

channel schemas exist; which are Direct Sequence UWB (DS-UWB) and Time

Hopping UWB (TH-UWB). Both schemas were introduced in section 3.2.3. While

they both spread the signals over a very wide bandwidth, TH-UWB has an advantage

over DS-UWB which is the ability to compute the spreading sequences on the fly

and thus no assignment protocol is needed [32]. The analysis in [33] also shows that

TH-UWB provides a better overall performance than DS-UWB in terms of Bit Error

Rate, throughput and energy efficiency for a crowded indoor single-hop

environment. From the above, TH-UWB was selected in our study.

4.1.2 Technical Details

In our study, TH IR-UWB [10] in the lower band (3.1-4.85 GHz) of 1.75GHz

bandwidth is used. The lower band was selected to increase the signal penetration

power and also to minimize the free space loss and attenuation. Time is divided into

chips of short duration (Tc = 0.02ns). The chips are organized into frames. The length

of each frame is equal to the Pulse Repetition Period (PRP = 280 chips). This gives a

maximum throughput per source of 180Mbps using the following equation:

cT PRP

1 Throughput

(4.1)

where: PRP is the Pulse Repetition Period

Tc is the chip time

Reaching higher data rates can be achieved by using shorter chip duration (Tc)

or a smaller PRP. While chip duration depends on the pulse duration which is limited

by the transceiver hardware capabilities, a large PRP value is required in order to

minimize the radiated power (Prad) to minimize the interference. Radiated power is

calculated using the following equation:

c

pulserad

TPRP

PP

(4.2)

where: Prad is the radiated power

PRP is the pulse repletion period or the frame size

60

Tc is the chip duration

Ppulse is the Pulse Power

Given the values mentioned above and Ppulse = 100 pico joules [40] the system

can achieve radiated power of 18mW (12.5dBm). Figure 4.1 illustrates the TH IR-

UWB physical layer components. The physical layer consists of a pulse

Modulator/Demodulator (PPM/DPPM), Interference Mitigation (IFM) and

Encoder/Decoder. Physical layer components details are represented in the following

sub-sections.

Figure ‎4.1 TH IR-UWB with PPM.

One source will transmit one pulse per frame in a chip, the index of which is

determined by the Time Hopping Sequence (THS), THS is a periodic sequence [x1,

x2,‎… , xn] where xi is the position of the chip to be used for transmission in the ith

frame. To provide a deterministic but yet independent different THS for each node,

every node has an identical Pseudo-Random Number Generator (PRNG) and uses its

MAC address as a unique identifier.

Communication uses either public THS or private THS. The public THS for

node with MAC address = X is the THS produced by the PRNG with a seed = X.

Public THS is receiver-based; the THS of the destination is used for any peer-to-peer

transmission. Hence, for any intended traffic arrival, each node only monitors its own

THS channel. The private THS for a connection between 2 nodes with MAC

addresses = X and Y is the THS produced by the PRNG with a seed equal to the

number whose binary representation is the concatenation of X and Y. In addition,

there is a predefined broadcast THS for all nodes. Each node reset its own THS to its

seed value after every packet transmission.

Frame = Tc * PRP Tp Tc

δ 1 0

MAC

Encoder

PPM PHY

MAC

Decoder

PHY IFM PPDM

Rate

62

4.1.2.1 Modulation

Binary Pulse Position Modulation (PPM) is used to transmit a block of coded

bits. A coded bit equals to 0 is sent as a pulse of duration Tp transmitted at the

beginning of the chip, whereas for a bit‎of‎1‎the‎pulse‎is‎offset‎by‎a‎fixed‎δ,‎smaller‎

than the chip time Tc as represented in Figure 4.1 ,‎where‎‎δ‎<‎Tp< Tc.

4.1.2.2 Data Encoding

A channel encoder is used before the modulator that selects an encoding rate

and encodes the incoming block of data blocks. The modulator then converts this to

the PPM form to be transmitted over the physical medium. Rate Compatible

Punctured Convolutional Codes (RCPC) [42] is used providing variable encoding

rate as well as incremental redundancy.

1. Encoder Structure

Convolutional codes are specified by three parameters; (n,k,m). Where n is the

number of output bits and number of the mod2 adders (XORs), k is the number of

input bits and m is the number of memory shift registers. The quantity k/n called the

code rate which is a measure of the efficiency of the code.

Commonly k and n parameters range from 1 to 8, m from 2 to 10 and the code rate

from 1/8 to 7/8 except for deep space applications where code rates as low as 1/100

or even longer have been employed [43]. Often the manufacturers of convolutional

code chips specify the code by parameters (n, k, L), The quantity L is called the

constraint length of the code and is defined by L = k (m-1). Figure 4.2 represents a

generic convolutional encoder.

1

1

2 … k 1

1

2 … k 1

1

2 … k …..

+ + + …..

1 2 m

n 2 1

Input

Sequence

Figure ‎4.2 Convolutional Encoder

63

A convolutional encoder can be described using a set n generator vectors (one

for each output). Each vector has m*k dimensions and contains the connections of

the register bits to the mod2 adder. A 1 in the ith

position of the vector indicates that

the corresponding bit in the register is connected to the mod2 adder while a 0

indicates no connection.

2. Punctured Codes

For the special case of k = 1, the codes of rates 1/2, 1/3, 1/4, 1/5, 1/7 are

sometimes called mother codes. Single input bit codes can be combined to produce

punctured codes which give us code rates other than 1/n.

By using two (2, 1, 3) 1/2 rate codes together as shown in Figure 4.3 and then

just not transmitting one of the output bits a (3, 2, 3) 2/3 rate code can be

generated. This concept is called puncturing. On the receive side, dummy bits that

do not affect the decoding metric are inserted in the appropriate places before

decoding.

This technique allows producing codes of many different rates using just a

single hardware. Although we can also directly construct a code of rate 2/3, the

advantage of a punctured code is that the rates can be changed dynamically (through

software) depending on the channel condition. A fixed implementation, although

easier, does not allow this flexibility.

m1

1

m2 m

3

+ +

n1

K1

n2

m1

1

m2 m

3

+ +

K2

n3 n

4

Figure ‎4.3 Punctured Codes

64

3. Encoding Incoming sequence

The output sequence v, can be computed by convolving the input sequence u

with the encoder impulse response g. For example to encode input sequence of

“1011” with the (2, 1, 4) code and generator vectors n1 = [1010] and n

2 = [0111]. We

need first to get the system impulse response given an all zero register as illustrated

in Figure 4.4.

From Figure 4.4 we get the system impulse response of “10‎01‎11‎01”.‎Now‎we‎

can encode the input sequence by mod2 adding the system response for each bit as

follows:

Figure ‎4.4 A sequence consisting of a solo 1 bit as it goes through the

encoder. The single bit produces 8 bit of output

e) T=0

0 0

0

+ +

n1 n2

0

1 0

0

+ +

1 0

0

a) Initial

state

d) T=1

0 1

0

+ +

0 1

0

c) T=2

0 0

1

+ +

1 1

0

b) T=3

0 0

0

+ +

0 1

1

Input

Sequence

d

65

Input sequence Encoded sequence

1 10 01 11 01

0 00 00 00 00

1 10 01 11 01

1 10 01 11 01

1011 10 01 01 10 10 10 01

4. Encoder Representation

Graphically, there are three ways in which we can look at the encoder. These

are State Diagram, Tree Diagram and Trellis Diagram [44]. We are only interested in

the Trellis diagrams as they represent linear time sequencing of events.

In Trellis diagrams, the x-axis is discrete time and all possible (2L) states for the

(L) code constraint length are shown on the y-axis. We move horizontally through

the trellis with the passage of time. Each transition means new bits have

arrived. Then we connect each state to the next state by the allowable code words for

that state. There are only two choices possible at each state determined by the arrival

of either a 0 or a 1 bit. The arrows show the input bit and the output bits are shown in

parentheses. The output bits are calculated by concatenating the input bit to the

current state and getting the system response to this value. The arrows going upwards

represent a 0 bit and going downwards represent a 1 bit. The Trellis diagram is

unique to each code. We always begin and end at state 000. The transitions then

repeat from this point on. Figure 4.5 represents a (2, 1, 4) code with generator vectors

n1 = [1010] and n

2 = [0111].

For example to‎encode‎“1011”,‎we‎start‎at‎ the‎state‎000.‎As‎ the‎ first‎ input‎ is‎

“1”,‎we‎ traverse‎ the‎ arrow‎going‎ down‎ to‎ the‎ next‎ state‎ “1”‎ ->‎ ”00”‎=‎ “100”‎ and‎

have “1”->”000”‎=‎“1000”‎in‎the‎registers‎so‎the first output is “10”.‎The‎next‎input‎

is‎“0”,‎so‎we‎traverse‎the‎arrow‎going‎up‎to‎the‎next‎state‎“0”‎->‎“10”‎=‎“010”‎and‎

have‎“0”->”100”‎=‎“0100”‎in‎the‎registers‎so‎the second output is “01”.‎For‎the‎third‎

input‎“1”,‎we‎traverse‎the‎arrow‎going‎down‎to‎the‎next‎state‎“1”‎ ->‎“01”‎=‎“101”‎

and‎have‎“1”->”010”‎=‎“1010”‎ in‎ the‎ registers‎ so‎ the third output is “01”.‎For‎ the‎

fourth‎input‎“1”, we traverse the arrow going down to the next state “1”‎->‎“10”‎=‎

“110”‎and‎have‎“1”->”101”‎=‎“1101”‎ in‎ the‎ registers‎ so‎ the‎ fourth output is “10”.‎

The encoding only finishes when we reach the 000 state again, so the next input is

66

“0”.‎So‎we‎traverse‎the‎up‎arrow‎to‎the‎next‎state‎“0”‎->‎“11‎=‎“011”‎and we have in

the‎registers‎“0”->”110”‎=‎“0110”‎so‎the fifth output is “10”.‎Again‎with‎input‎“0”,‎

we‎ traverse‎ the‎ up‎ arrow‎ to‎ the‎ next‎ state‎ “0”‎ ->‎ “01”‎=‎ “001”‎ and‎we‎have‎ “0”-

>”011”‎=‎“0011”‎in‎the‎registers‎so‎the sixth‎output‎“10”. Finally‎with‎another‎“0”,‎

we traverse the up arrow to the next‎state‎“0”‎->‎“00”‎=‎“000”‎and‎have‎“0”->”001”‎

=‎ “0001”‎ in‎ the‎ registers‎ so‎ the seventh output is “01”.‎ The‎ input‎ “1011”‎ is‎ now‎

encoded‎to‎“10‎01‎01‎10‎10‎10‎01”.

4.1.2.3 Data Decoding

The basic idea behind decoding convolutional codes is: assume that 3 bits were

sent via a rate ½ code. We receive 6 bits; these six bits may or may not have errors.

We know from the encoding process that these bits map uniquely. So a 3 bit

sequence will have a unique 6 bit output. But due to errors, we can receive any and

all possible combinations of the 6 bits.

The permutation of 3 input bits results in eight possible input sequences. Each

of these has a unique mapping to a six bit output sequence by the code. These form

the‎ set‎ of‎ permissible‎ sequences‎ and‎ the‎ decoder’s‎ task‎ is‎ to‎ determine‎which‎ one‎

was sent based on the maximum bit agreement or the minimum Hamming distance.

Having the Hamming distance defined as the dot product between the received

sequence and the possible input sequence.

Viterbi decoding [43] is the best known implementation of the maximum

likely-hood decoding. The Viterbi decoder traverses the encoder trellis diagram by

examining the entire received sequence. The decoder computes a metric for each

Figure ‎4.5 Trellis diagrams for (2, 1, 4) code

000

010

100

101

110

111

011

0(11)

0(01)

1(10)

0 (00)

1(10)

1(10)

1(01)

1(11)

1(00)

1(11)

0(10)

0(01)

0 (00) 0 (00)

001

67

path and makes a decision based on this metric. All paths are followed until two

paths converge on one node. Then the path with the higher metric is kept and the one

with lower metric is discarded. The paths selected are called the survivors.

For an N bit sequence, total numbers of possible received sequences are 2N. Of

these only 2kL

are valid. The Viterbi algorithm applies the maximum-likelihood

principles to limit the comparison to 2 to the power of kL surviving paths instead of

checking all paths.

4.2 Medium Access Control Protocol

In [29, 34], a number of MAC protocols for the IR-UWB were discussed and

compared. Some of those protocols were ported from a narrowband MAC protocol.

Those ported protocols were inefficient because of the unique nature of UWB

technology. The requirement for strict synchronization between transmitter and

receiver, long acquisition time [35] and low power operation constraint for

coexistence with other narrowband networks necessitates the development of an

UWB MAC optimized to take advantage of these properties.

4.2.1 Protocol Selection Criteria

In [32], Dynamic Channel Coding (DCC) with Interference Mitigation MAC

protocol is presented. DCC MAC is an UWB tailored MAC protocol used for

802.15.4a-like UWB ad-hoc networks. The DCC MAC protocol was designed to

maximize the benefit from the special UWB properties to achieve maximum flow

control within the constraint of very low power emissions. As DCC MAC meets our

needs of providing multiple connections while preserving energy, DCC MAC was

selected in our study.

4.2.2 Technical Details

DCC‎MAC‎protocol‎is‎made‎of‎two‎components:‎“Dynamic‎Channel‎Coding”‎

and‎“Private‎MAC”.‎‎By‎the‎use‎of‎“Dynamic‎Channel‎Coding”,‎competing‎sources‎

are able to send simultaneously at the maximum power permitted by hardware and

regulation constraints, sources then adapt to interference by dynamically adjusting

68

their channel codes, thus their bit rates, causing rate reductions instead of collisions.

By that DCC MAC allows interference to occur and adapt to it, in contrasts with the

traditional interference management methods based on transmission power

management and mutual exclusion.

DCC MAC supports 31 rates (R) : {1, 8/9, 8/10, 8/11, 8/12, 8/13, 8/14, 8/15,

8/16, 8/17, 8/18, 8/19, 8/20, 8/21, 8/22, 8/23, 8/24, 8/25, 8/26, 8/27, 8/28, 8/29, 8/30,

8/31, 8/32, 1/5, 1/6, 1/7, 1/8, 1/9, 1/10}, so if a source is having L data bits to send,

then the block will be coded using rate Ri and a block of L/Ri coded bits will be

transmitted.

DCC MAC uses Rate Compatible Punctured Convolutional Codes (RCPC)

providing variable encoding rate as well as incremental redundancy. Assume the

source uses a high rate (Rhigh) to send the data. Also assume that the destination is not

able to decode at rate Rhigh because the quality of the channel required a lower rate

Rlow. Thus the source has to send more information to the destination. It is sufficient

for the source to only send (L/RLow – L/RHigh) additional bits to repair the error as the

system of codes offers incremental redundancy. So none of the already transmitted

coded bits are thrown away but are used to improve decoding. Channel coding is

constantly adapted to the highest achievable rate code that permits accurate decoding

of the packet at the destination. A safety margin is used to mitigate retransmissions in

case channel conditions deteriorate.

The‎use‎ of‎ “private‎MAC”‎ solves‎ the‎ contention‎ between‎ sources‎ competing‎

for the same destination; it is required because nodes are assumed to be able to

receive from only one source at a time. This is done by using a combination of

receiver based and invitation dependent selection of time hopping sequences where

no common channel is used; thus issues of hidden and exposed terminals are avoided

altogether.

Given a number of supported rates R0= 1>R1>R2> ... > RN. The protocol

process is summarized as follows for two sources S1 and S2 and destination D and

illustrated in Figure 4.6:

Every node listens to its own THS.

If a source (S1) wants to communicate with the destination (D). It sends a

transmission‎ request‎ on‎ the‎ destination’s‎ THS‎ using‎ the‎ channel‎ code‎ for‎ the‎

lowest rate (code index (D) = N so the rate is RN).

69

D sends a reply using a THS private to S1 and D.

If S1 receives a reply, it indicates that D is idle and S1 starts transmission of the

data packet using the THS private to S1 and D.

The source adds a Cyclic Redundancy Check (CRC) to the packet content and

encodes it with the lowest rate code.

The source then punctures the encoded data (i.e., removes specific bits from it) to

obtain the desired code rate and sends the packet. The punctured bits are stored in

case the decoding at the destination fails.

Upon packet reception, the destination decodes the data and checks the CRC. If

decoding is successful, an acknowledgement is sent back to the source. In

addition, the packet contains a short header with the packet length, encoded at the

lowest rate code. This ensures that the destination is able to detect that a packet

transmission attempt did take place even when decoding of the entire packet fails.

In such a case, the destination sends a negative acknowledgement (NACK).

As long as the source receives NACKs, further packets with punctured bits (each

time up to the size of the original packet) are sent, until transmission succeeds or

no more punctured bits are available. In the latter case, the source retransmits the

packet after a back-off period. As soon as D can decode, it computes the smallest

index j such that rate Rj would allow successful decode. D returns index j + 2 in

the ACK to S1. When a source with code index (D) = i receives an ACK with

code index (D) = j + 2, if j + 2 < i then it sets the code index (D) = i - 1, else

code index (D) = j + 2.

After a transmission both source and destination nodes issue an idle signal on

their THS respectively in order to inform other nodes that they are idle.

If S2 tries to communicate with the destination D while S1 still sending data, it

sends‎a‎transmission‎request‎on‎the‎destination’s‎THS‎using‎the‎channel code for

the lowest rate, but D is busy receiving from S1and will not send a reply, then S2

will have to wait to hear the idle signal from D and then waits for another random

back-off time before retransmitting.

Even‎ with‎ “Private‎MAC”‎ a‎ collision‎ can‎ occur at the destination only if the

synchronization preambles requests of two competing sources overlap.

Otherwise, the destination synchronizes to one of the requests and the other

71

request is considered interference. Thus the vulnerable period is bounded by the

synchronization‎ time‎ (10μs‎ [24]).‎When‎ a‎ collision‎ occurs, a back-off timer is

used after the reception of an idle signal from the destination.

Figure ‎4.6 Dynamic Channel Coding

The DCC MAC uses interference mitigation (IFM) scheme based on the

concept of erasures in order to reduce the effect of an interfering close to the

destination node, which will significantly lower the transmission rate.

For a given chip, the amplitude of a noisy coded bit depends roughly on the

total energy present in the chip. If no collision occurs, the noisy coded bits

correspond to a slightly distorted version of their respective coded bits. The same

happens if a collision occurs with a distant interferer. In this case, the decoder is

powerful enough to recover the transmitted bits. However, a collision with a very

strong interferer will result in a highly distorted version of the coded bit. When the

received signal energy in a chip is larger than some threshold B, the IFM scheme

cancels the coded bit resulting from a collision with pulses of a strong interferer and

REQ

CodeIndex: i

Data 1

CodeIndex: 2i

Increment

redundancy

CodeIndex: j+2

Data 2

CodeIndex: j+1

Idle

S1 D S2

RESP

NACK

ACK

CodeIndex: j+2

ACK

CodeIndex: j+1

Idle

Failed REQ

REQ

THS(D), RN

THS(S1,D),RN

THS(S1,D),Ri

THS(S1,D),RN

THS(S1,D),RiΔR2i

THS(S1,D),RN

THS(S1,D),Rj+2

THS(S1,D),RN

THS(S1),RN THS(D),RN

THS(D),RN

THS(D),RN

70

replaces them by erasures (skips them in the decoding process and triggering

retransmission) instead of polluting the decoding process causing several subsequent

decoding errors.

Broadcast is supported by means of well known unique THS and

synchronization sequence dedicated to broadcast. The code is the lowest rate. There

is never a collision between broadcast packets and unicast packets, since they use

different THSs. However, broadcast packets will not be received by nodes that

happen to be sending or receiving at the time of transmission.

4.2.3 Frame Format

The UWB physical layer adds the physical layer (PHY) header to the MAC

header, calculates the Header Check Sequence (HCS) and appends this to the MAC

header. The PHY preamble is sent first in the packet, followed by the PHY and MAC

header, followed by the MPDU and finally the tail symbols. Figure 4.7 [24]

illustrates the frame format.

4.2.3.1 Preamble

Preamble [24] consists of 3 fields:

Acquisition sequence: The preamble starts with the acquisition sequence,

which is used primarily by the receiver to set gains and achieve clock

synchronization.

Training frame: Used for the sender to estimate the channel unknown

parameters. The length of the training frame varies depending upon the

preamble length.

Start Frame Delimiter (SFD): The SFD consists of the 16-bit binary pattern

0000 1100 1011 1101 (transmitted leftmost bit first) as modulation on the

selected BPSK code. The SFD defines the frame timing in anticipation of

the PHY header.

Figure ‎4.7 UWB Frame Format

Preamble PHY Header MAC Header HCS Data FCS Tail

72

4.2.3.2 Physical Layer Header

The physical layer header [24] consists of three octets that contain the number

of octets in the frame body (including the FCS), the data rate of the frame body and

seed identifier for the data scrambler.

4.2.3.3 Medium Access Control Header

The medium access control header [41] consists of 6 fields as illustrated in

Figure 4.8.

Figure 4.8 UWB MAC Header

Stream index: unique value for each isochronous stream

Fragmentation Control field: used to aid in the fragmentation and a

reassembly of MAC Service Data Units (MSDUs) and command frames.

It consists of:

o MSDU Number field indicates the sequence number of the current

MSDU or command frame

o Fragment Number field indicates the order of the current fragment

within the current MSDU. The Fragment Number field shall be set

to zero in all unfragmented frames.

o Last Fragment Number field indicates the total number of

fragments within the current MSDU.

SrcID: MAC address of the source

DestID : MAC address of the destination

PNID : contains the unique identifier for the piconet.

Frame Control: This field consists of:

o Protocol Version

Stream

index

Fragmentation

control

SrcID DestID PNID Frame

control

73

o Frame Type: which can be one of the following (Beacon frame,

Immediate ACK frame, Delayed ACK frame, Command frame or

Data frame)

o SEC: The SEC bit shall be set to one when the frame body is

protected using the key specified by the security ID (SECID).

o ACK Policy: used to indicate the type of acknowledgement

procedure that the addressed recipient is required to perform.

Three ACK policies are supported:

No ACK: The recipient(s) does not acknowledge the

transmission and the sender treats the transmission as

successful regardless the actual result.

Immediate ACK: The addressed recipient returns an ACK

frame after successful reception of each packet.

Delayed ACK: The addressed recipient keeps track of the

frames received with this policy until requested to respond

with an ACK frame.

o Retry bit: set to one in any data or command frame that is a

retransmission of an earlier frame. It shall be set to zero in all

other frames.

4.3 Protocol Adaptation Layer

A new Protocol Adaptation Layer (PAL) is created to handle the

communication between the Bluetooth profiles and the UWB MAC. The UWB PAL

defines the protocol state machines, data encapsulation methods and data structures

to support the use of an UWB alternate controller. The UWB PAL state machine,

data encapsulation and data structures are based on those of 802.11 PAL defined in

BluetoothV3.0+HS core specification [4].

74

4.3.1 Protocol State Machine

UWB PAL defines six states; the states apply to an individual physical link. At

power-up or reset, no physical links exist and the state is the Disconnected state.

Figure 4.9 illustrates the states and the transitions between them.

Disconnected: The physical link is not active and this is the initial state.

Starting: MAC is initializing.

Connecting: The initiating device waits for messages from the peer device; the

responding device commences network connection operations.

Authenticating: The devices perform the security association process.

Connected: A secure physical link has been established with the remote device.

Disconnecting: The PAL waits for the MAC to complete disconnection and

return to the initial state.

4.3.2 Data Encapsulation

Each Logical Link and Control Adaptation Protocol (L2CAP) Protocol Data

Unit (PDU) is transmitted by the MAC as a single MAC Service Data Unit (MSDU)

limited by the UWB MaxUWBPALPDUSize of 1492 bytes. Before transmission, the

Disconnected

Connected

Disconnecting

Authenticating

Connecting

Starting

Create/Accept PHY

Link & MAC not

Started

MAC Started

Create/Accept PHY

Link & MAC

Started

Connect Completed

Disconnect PHY Link request

Connect failed or

Disconnect PHY Link

request

Authentication failed or

Disconnect PHY Link

request

Cancel MAC connection

Authentication succeeded

Medium disconnect or

Disconnect PHY Link

request

Figure ‎4.9 UWB PAL State Machine

75

PAL removes the HCI header, add Logical Link Control (LLC) and Sub-Network

Access protocol (SNAP) headers and insert an UWB MAC header. The LLC/SNAP

header is illustrated in Figure 4.10.

Figure ‎4.10 LLC Header from UWB PAL Encapsulation

DSAP: is a 1 byte field that specifies the Destination Service Access Point

SSAP: is a 1 byte field that specifies the Source Service Access Point

Control: is a 1 byte field specifies the type of LLC frame. These include Type1

(connection-less link protocol), Type2 (connection-oriented protocol) and Type3

(connection-less acknowledged protocol).

OUI : is a 3 bytes field stands for the Organizationally Unique Identifier.

Protocol: is a 2 bytes field with the following possible values:

o 0x0001 : L2CAP ACL data

o 0x0003: Security frames

o 0x0004: Link supervision request

o 0x0005: Link supervision reply

4.3.3 Data Structures

Two important data structures are defined in the PAL: AMP_INFO and

AMP_ASSOC. AMP_INFO is used to exchange the alternate controller capabilities

and parameters between peer devices. AMP_ASSOC is used to exchange alternate

MAC information.

4.3.3.1 Alternate Controller Capabilities (AMP_INFO)

The UWB PAL defines nine return parameters for the Read Local AMP Info

command. These parameters are:

Total bandwidth: is a 4 bytes value represents the upper bound on the total data

rate that can be achieved by the UWB alternate controller for applications. This

DSAP SSAP Control Protocol OUI

76

may be used to help in alternate controller selection and admission control. If

more than one alternate controller exits at both end points, the one with the

largest total bandwidth is selected for communication. Set to 180Mbps.

Expressed in kbps.

Maximum Guaranteed Bandwidth: is a 4 bytes value represents the upper

bound on the total data rate that can be achieved by the UWB alternate controller

given the sum of the bandwidths of all active flows. Any request made by an

application above this level would be rejected. Expressed in kbps.

Minimum Latency: is a 4 bytes value represents the practical lower bound on

the service latency that can be provided by the UWB alternate controller. The

lower bound of the service latency is the time from when a frame is issued from

the L2CAP until the MAC starts transmitting the frame.

Maximum PDU Size: is a 4 bytes value represents the upper bound on the size

of L2CAP PDU which may be provided for transmission or reception on this

alternate controller. The Host shall not require the AMP to transport L2CAP

PDUs larger than this value. Expressed in bytes.

Controller Type: is a 1 byte field hold value 0x02 representing the UWB

controller.

PAL Capabilities: is a 2 bytes value, bit 0 is used to indicate the service type

while other bits are reserved. Available service types are:

o Guaranteed : Bit0 is set to 1 (Not currently supported)

o Best Effort: Bit0 is set to 0

AMP ASSOC Length: is a 2 bytes value represents the maximum

AMP_ASSOC structure length which is 9 bytes.

Maximum Flush Timeout: is a 4 bytes value represents maximum time period,

in microseconds, which the alternate controller device may use to attempt to

transmit a frame on a guaranteed logical link.

Best Effort Flush Timeout: is a 4 bytes values represents the typical time

period, in microseconds, which the alternate controller device may use to attempt

to transmit a frame on a best effort logical link. In the current implementation,

this field is set to infinity (0xFFFFFFFF)

77

4.3.3.2 Alternative MAC Information (AMP_ASSOC)

The AMP_ASSOC has a maximum length of 9 bytes. The AMP_ASSOC

structure used by the UWB PAL is composed of Type-Length-Value (TLV) triplets.

The general format of such a TLV is one-byte TypeID field, a two-bytes Length field

and a variable length Value field. The length of the Value field in bytes is

represented by the Length field.

The UWB AMP_ASSOC structure consists of:

MAC Address: The PAL uses this field to report the UWB MAC address of its

local UWB MAC. TypeID = 0x01 and length = 6 bytes

PAL Version: An alternate controller endpoint may need to discover the version

of the remote PAL. The information in the PAL Version is composed of the

PAL_Version, the Bluetooth SIG Company Identifier for the provider of the PAL

and the PAL_Sub-version. TypeID = 0x05 and length = 5 bytes.

4.4 Summary

In this chapter, an AMP controller has been proposed based on TH IR-UWB.

The proposed AMP controller uses Dynamic Channel Coding (DCC) with

interference mitigation MAC protocol. The DCC uses convolutional codes to adapt

the data rates to the interference level instead of using a traditional power control or

mutual exclusion. The system of codes used allows incremental redundancy which

minimize the required number of bits to be transmitted in case of decoding failure.

Erasures are used on interference to prevent further decoding errors. Finally, data

structures for the UWB PAL were defined.

In the next chapter, performance evaluation of the proposed UWB AMP

controller will be conducted and compared with that of the AMP controller based on

IEEE802.11g proposed by the Bluetooth SIG in the BuetoothV3.0+HS core

specification.

Chapter

5 Proposed Controller Evaluation

79

Chapter 5

Proposed Controller Evaluation

As previously mentioned in chapter 4, this work proposes using UWB

technology as an alternative controller for Bluetooth in order to meet the demands of

supporting multiple high rate streams, low power consumption and minimum

interference.

This chapter presents our investigation into the performance of the

BluetoothV3.0 over TH IR-UWB (BToUWB) in terms of throughput, transfer time,

energy efficiency and packet end-to-end delay verse number of connections and

application data rate. In order to make such evaluation the NS-2 simulator was

extended and several simulation experiments have been conducted.

This chapter is organized into five sections. Section 1 presents the simulation

environment; including assumptions made, applied simulation parameters,

quantitative metrics and simulation experiments. Section 2 highlights the evaluation

methodology and presents the modifications made to the NS2 simulator. Section 3

demonstrates, analyzes and discusses the simulation results obtained. Section 4

provides a results summary and some comments on the results. Finally section 5

presents the reached general conclusion.

5.1 Simulation Environment

A number of simulation scenarios were built to compare the performance of

BluetoothV3.0 over IEEE 802.11g (BToWiFi) and BluetoothV3.0 over TH IR-UWB

(BToUWB) in terms of throughput, transfer time, energy efficiency and end-to-end

delay versus number of connections and application data rate. In this analysis the

BluetoothV2.1+EDR performance was used as a benchmark. Each scenario was run

ten times. We calculated the 95% confidence intervals for the median for each set of

the runs. The data obtained with the 10 replications for each of the two factor

combinations was then examined using the analysis of two way variance routine to

find the significance of each factor on the performance of the controller.

81

5.1.1 Scenarios Setup

The simulation environment used in those scenarios represents the general

operational indoor environment for Bluetooth. Simulation topology consists of a

number of high-speed Bluetooth nodes with the same alternative controller in 8

meter by 8 meter area.

Nodes are placed at random positions and due to the limited range of Bluetooth

(10 meters), the distance between any two nodes ranges from 0 to 8 meters. A

connection is established between each 2 nodes, even nodes send while odd nodes

receive as illustrated in Figure 5.1. Nodes only send or receive to be able to do

separate analysis on the transmitters and receivers.

Connections between nodes are established within the first 2 seconds with a

delay of 0.2 second between each connection establishment to prevent collision

during connection establishment, while applications start transmitting data after 7

seconds and stops after 22 seconds from starting the simulation.

All applications run a constant bit rate (CBR) traffic generator. Simulation ends

only when there are no more packets to receive. By that we insure that the same

amount of data has been generated and transferred in all scenarios with the same

number of nodes and application data rate but different controllers.

Figure ‎5.1 Simulation topology 10 nodes and 5 connections

80

Bluetooth 3DH5 packets (which can carry up to 341 info bytes and covers 5

time slots) are used for connections over the BluetoothV2.1+EDR interface to reduce

the hop rate, thereby increases the chances of successful reception of the packets in

case of IEEE 802.11g coexistence which is the case while using IEEE 802.11g as an

alternative interface as proved in [14].

5.1.2 Simulation Parameters

ITU indoor propagation model [45] and Tarokh Propagation Model [46] were

used to simulate the propagation path loss in an indoor environment for WiFi and

UWB respectively. An implementation of the ITU indoor propagation model was

developed and added to our simulation model.

In order to practically compare the power consumption, two wireless products

for which detailed characteristics are publicly available are briefly presented as an

example, including BlueCore 6 ROM Transceiver IC [47] from Cambridge Silicon

Radio (CSR) and BGW211 Low-power WLAN 802.11g SiP [48] from NXP. For

UWB, power consumption details are based on the 0.18mm CMOS presented in [40].

The current and power consumptions of the transmit (TX) and receive (RX)

conditions for each interface are shown in Table 5.1. The data shown are for

particular products, although are broadly representative for examples of the same

type.

Different values are applied to study the effects of the number of connections

and the application data rate on the throughput, transfer time, energy efficiency and

end-to-end packet delay. A detailed set of the simulation parameters used for

different scenarios is represented in Table 5.2.

Table ‎5.1 Current and Power Consumption.

BluetoothV2.1 [47] IEEE 802.11g [48] IR-UWB [40]

VDD (volt) 1.8 3.3 1.8

TX(mA/ mW) 45/81 179/591 60/108

RX (mA/mW) 45/81 114/376 54/97

82

5.1.3 Evaluation Criteria

Four evaluation criteria are used to evaluate the performance of the proposed

controller versus the controller introduced by the Bluetooth SIG. These four criteria

are average network throughout, average network transfer time, average network

energy consumption per bit and the average network end to end delay. In the

following subsection the calculation method of those criteria is presented.

5.1.3.1 Throughput

Average network throughput is one of the key quantitative metrics considered

in the evaluation process. This metric gives an indication of the capability of a

technology in handling high rate applications and mitigating interfering sources

effects. Higher metric value indicates that a technology is more capable in handling

more traffic. Having a constant or near constant value for this metric with different

number of interfering sources represents a good indication that a technology can

work in a crowded environment. Average network throughput is calculated by

averaging the connections throughput using equation 5.1.

Table ‎5.2 Simulation Parameters

Parameter Values

Initial energy (Wh) 3

Number of connections 1,2,3,4,5,6

Number of nodes Twice the number of connections

Alternative controllers IEEE802.11g , DCC TH IR-UWB

Application Constant Bit Rate (CBR)

Application data rate (Mbps) 1, 5, 10, 30

Application packet size (Bytes) 1400

Transport layer agent UDP

Data size generated and transferred 15 × Application data rate

83

Average Network Throughput = (5.1)

where: Ri is the total number of bits received at connection i destination node.

T(Last)i is the arrival time of the last data bit for connection i.

T(First)i is the arrival time of the first data bit for connection i.

5.1.3.2 Transfer Time

Average network transfer time is the second quantitative metric considered in

the evaluation process. This metric is used to see a technology form the

customer/user point of view in which he/she is interested in knowing how much time

it would take to finish the transmission. Lower metric value indicates a better

product. Average network transfer time is calculated by averaging the connections

transfer time using equation 5.2.

Average network transfer time = (5.2)

where: T(Last)i is the arrival time of the last data bit for connection i.

T(First)i is the arrival time of the first data bit for connection i.

5.1.3.3 Energy Consumption per Bit

Average network energy consumption per bit is calculated by dividing the total

amount of energy consumed to send and receive the data by the amount of data

received. Having lower metric value for a certain technology indicates that this

technology would cause the device battery to live longer. The speed of depleting the

battery is one of the most crucial issues in the field of mobile devices. Average

network energy consumption per bit is obtained using equation 5.3.

sConnectionNumber_of_

)T(First)(T(Last)R

sConnectionNumber_of_

0i

iii

sConnectionofNumber

FirstTLastT

sConnectionofNumber

i

ii

__

))()((

__

0

84

Average network energy consumption per bit = (5.3)

where: Ej is the energy consumed at node j.

Ri is the total number of bits received at connection i destination node.

In the evaluation of the node energy consumption, the energy consumed by

both the Bluetooth and the alternative controller in all of their states were considered.

Node energy consumption is calculated using equation 5.4.

Node energy consumption = (5.4)

where: TBT is the time in seconds the Bluetooth radio was active.

EBT is the Bluetooth radio energy consumption per second in the active

state.

Tidle is the time in seconds the alternative radio was ON but idle.

Eidle is the alternative radio energy consumption per second in the idle

state.

TTX is the time in seconds the alternative radio was transmitting.

ETX is the alternative radio energy consumption per second in the

transmit state.

TRX is the time in seconds the alternative radio was receiving.

ERX is the alternative radio energy consumption per second in the

receive state.

5.1.3.4 End to End Delay

The average end-to-end delay is yet another quantitative metric considered in

the evaluation process. Having a constant or near constant metric value indicates that

a‎technology‎would‎suites‎applications‎that‎can’t‎tolerate jitter. The average delay is

obtained by computing the sum of the total delay encountered by all the nodes in the

network divided by their number as given in equation 5.5.

sConnectionofNumber

i

i

NodesofNumber

j

j

R

E

__

0

__

0

RXRXTXTXidleidleBTBT ETETETET

85

Average delay = (5.5)

5.2 Evaluation Methodology

Using an alternative controller in BluetoothV3.0+HS adds a lot of potential to

Bluetooth. Finding the best technology for the alternative controller is still an active

research topic and yet to be explored. A good simulation tool is essential to conduct a

fruitful research in comparing different alternatives.

5.2.1 Available Bluetooth Simulation Models

At the early stages of this research two Bluetooth simulation models were

considered: the‎Highland‎ Systems’‎ Bluetooth‎ Simulation‎Model‎ Suite‎ (Suitetooth)‎

[49] for OPNET [50] and the University of Cincinnati Bluetooth (UCBT) [51]

extension introduced in [52] for NS2 [53].

5.2.1.1 OPNET Suitetooth

Suitetooth [49] is an open, modular framework for modelling BluetoothV2.0.

Built for the OPNET simulation environment, Suitetooth includes component models

for Bluetooth radio, Baseband, L2CAP, LMP, ISM-band coexistence and traffic

source modelling. Suitetooth models only the connection state and lacks enhanced

data rate and scatternet modelling. Figure 5.2 illustrates a snapshot of the architecture

of the Suitetooth Bluetooth master node model.

NodesofNumber

PacketsofNumber

onTimeTransmissieArrivalTim

Nodes

Packets

__

__

86

Figure ‎5.2 Suitetooth Bluetooth master node model architecture

5.2.1.2 NS2 UCBT

UCBT [51] is an open source NS2 extension modelling BluetoothV2.0+EDR

core specifications. By default the NS2 node consists of an Entry point, Address

Demux, Port Demux, Application protocol and Routing agent. UCBT adds to the

NS2 node the following Bluetooth protocols introduced in chapter 2: BNEP, SDP,

L2CAP, LMP and Baseband. UCBT models specifications at Baseband and above

like LMP, L2CAP, including frequency hopping scheme, device discovery,

connection set up, Hold, Sniff and Park modes management, role switch and multi-

slot packet type negotiation, SCO voice connection and scatternet formation. BNEP

has been also modelled in UCBT. UCBT also includes the Enhanced Data Rate

(EDR) specification to simulate new devices with 2 or 3 Mbps data rate. Figure 5.3

illustrates the UCBT Bluetooth node model architecture.

87

Figure ‎5.3 UCBT Bluetooth node model architecture

5.2.1.3 Comparison between the two Models

UCBT and Suitetooth both are excellent tools for Bluetooth modelling and

simulations. Using Suitetooth means using OPNET which has packed a more user

friendly interface which helps reduce the learning curve. OPNET also has a set of

modules which mimic the real world devices; therefore it is an excellent tool for IT

planning and diagnosis. On the other hand, using UCBT means using NS2 which is a

research project and mainly community based. Open community support, the

flexibility of dual language spaces and full source code availability are great

advantages. Because of its better availability and community support, we consider

NS2 is a better choice for our simulator so we used the UCBT extension.

5.2.2 High Speed Bluetooth Simulation Model

To gain a deeper understanding about the issues of switching between the

controllers, to compare candidate controllers and contribute to the research

community in general, we have extended the UCBT model to simulate the

Entry

Application

Routing

Agent

NS-2 Node

Port Demux

Address Demux

LL

BNEP

SCO

Agent

SDP

Baseband

LMP

L2CAP

88

BluetoothV3.0+HS core specification in a new model named the High Speed

BlueTooth (HSBT) model [54].

5.2.2.1 High Speed Bluetooth Model Design Goals

While developing the HSBT model we had the following design goals in our

minds:

Accurate modelling of the A2MP protocol and communication channels over the

different controllers.

Backward compatibility for the scenarios written for the UCBT, 802.11 and

UWB models.

Provide an interface to simplify the operation of adding other controllers for

future research.

Provide an easy way to setup the HSBT model on an already existing NS2

environment.

5.2.2.2 HSBT Modifications

HSBT model extends the UCBT model by adding the A2MP introduced in

section 2.2.3.2, 802.11 PAL introduced in section 2.2.2.1 and UWB PAL introduced

in section 4.3. HSBT also modifies the UCBT by adding the capability of having

more than one radio interfaces in a single Bluetooth node. The L2CAP component

was also modified to establish logical links over the 802.11 MAC using the 802.11

PAL and over the UWB MAC using the UWB PAL. Finally, the 802.11 and UWB

models were integrated, creating a simulation model for high speed bluetooth over

IEEE802.11 or UWB.

For the alternative 802.11 MAC/PHY, NS2 802.11 model was used. For the

alternative UWB MAC/PHY, EPFL [55] UWB extension for NS2 was used. EPFL

UWB model simulates the DCC MAC protocol (presented in the previous chapter)

with an IR-UWB physical layer.

89

5.2.2.3 HSBT Capabilities

The HSBT model allows adding an IEEE 802.11b/g or UWB controller to the

Bluetooth node, discovering the remote devices AMP capabilities and establishing

links for data transfer over the alternative controller. Illustration of the HSBT

simulation model components is represented in Figure 5.4 and divided to the

following:

The default NS2 node consists of an Entry point, Address Demux, Port

Demux, Application protocol and Routing agent.

UCBT adds to the NS2 node the following Bluetooth protocols: BNEP, SDP,

L2CAP, LMP and Baseband.

The proposed HSBT adds the capability to simulate Bluetooth V3.0 node,

where code was written to implement the A2MP, 802.11b/g PAL and UWB

PAL. The written code is used to allow establishment of links and data

exchange over the alternative controllers.

NS2 802.11 MAC and physical layers were integrated to support Bluetooth

over WiFi.

EPFL UWB MAC and physical layers were integrated to support Bluetooth

over UWB to model the proposed controller.

In Figure 5.4, boxes with white background and straight line links represent the

NS2 code. Boxes with small number of dots background and dashed line links

represent the UCBT code. Boxes with large number of dots background and dotted

line links represent the EPFL code. Boxes with squares in the background and dash-

dot line links represent the proposed HSBT code.

91

Figure ‎5.4 HSBT BluetoothV3.0 node

5.2.2.4 HSBT Model Validation

HSBT validation was performed using face validation through a cyclic model

review and improvement process. The process starts by a first simple implementation

of the protocol. The next step is logging the exchanged messages between

communicating nodes during various procedures introduced in section 2.2.3.2. Those

procedures include AMP discovery, AMP link setting up and data exchange over the

AMP link. The log is then compared with the Bluetooth specifications V3.0+HS. The

comparison output is then used to make modifications/improvements to the model

code and restart the cycle. The process ended when the logged messages matched the

specifications.

For example, the physical link creation procedure. To validate the correct

modelling of this procedure, all four steps must be modelled with the same sequence

HSBT

UCBT

NS-2

EPFL UWB

Entry

Application

Routing

Agent

NS-2 Node

Port Demux

Address Demux

Logical Link

A2MP

BNEP SCO

Agent

SDP

Baseband

LMP

802.11PAL

802.11PHY

802.11MAC

L2CAP

UWB PAL

IR-UWB

PHY

UWB MAC PPM

Modulation

90

as specified in the specification. In the validation process, the sequence of the

executed commands is logged and compared to the specifications till they matched.

5.2.2.5 HSBT Availability

HSBT has been open sourced since September 2009. The source code is

available at http://code.google.com/p/hsbt/ and can be also reached from the NS2

contributed code page as an update to the UCBT Bluetooth extension model at

http://nsnam.isi.edu/nsnam/index.php/Contributed_Code#Wireless_and_Mobility.

Three major versions were released:

Version 0.7: released on May 2010 and only supports creating a single Bluetooth

high speed connection over the 802.11b alternative controller.

Version 1.0WiFi: released October 2010 to support creating any number of

Bluetooth high speed connections over 802.11b/g alternative controller.

Version 1.0WiFi_UWB: released November 2010 to support creating any

number of Bluetooth high speed connections over 802.11b/g or DCC TH IR

UWB alternative controller.

As of July 1st 2011, we have recorded 95 downloads for the different versions

from different IP addresses and over 1400 visits from 70 different countries. Figure

5.5 represents the number of visits to the HSBT site per country. Visits are

concentrated in India, Portugal, United States, Italy, China, Brazil, United Kingdom,

Taiwan, Indonesia, Germany, France and Japan. This indicates a strong interest in

the research community. We plan to continually improve HSBT and keep it available

for the community use.

Figure ‎5.5 HSBT site visits per country

http://code.google.com/p/hsbt/

http://nsnam.isi.edu/nsnam/index.php/Contributed_Code#Wireless_and_Mobility

92

5.3 Results and Analysis

Performance parameters are measured and calculated for the purpose of

comparing BluetoothV2.1+EDR, BluetoothV3.0+HS over 802.11g (BToWiFi)

introduced in the BluetoothV3.0 core specification and the proposed

BluetoothV3.0+HS over DCC TH IR-UWB (BToUWB).

5.3.1 Throughput

Two-way Analysis of Variance (ANOVA) [56] is used to analyze the network

throughput. ANOVA results are represented in Table 5.3 for both BToWiFi and the

proposed BToUWB. The mean square value represents the effect of a certain

parameter/factor on the network throughput. By comparing the mean squares of

number of connection, application rate and distance for the proposed BToUWB, it

can be seen that there is no significance to the effect of the number of connections,

only the application rate affects the network throughput. For BToWiFi both factors

have nearby significance meaning that BToWiFi is highly affected by increasing the

number of connections. This piece of information indicates that the proposed

BToUWB‎channel‎throughput‎won’t‎degrade as the environment gets more crowded

while the BToWiFi channel throughput will. Regarding the distance, both BToWiFi

and the proposed BToUWB are not affected by a distance within an 8 m2 area.

Table ‎5.3 Two Way ANOVA for Throughput of BToWiFi and BToUWB

Degrees of

Freedom Square Sum Mean Square

BToWiFi

(Bluetooth SIG)

Number of connections 5 1486.7 297.3

Application rate 2 991.7 495.9

Connections*rate 10 1504.3 150.4

Distance 162 0.16 1e-3

BToUWB

(Proposed)

Number of connections 5 3e-12 7e-13

Application rate 2 21604 10802

Connections*rate 10 3e-12 3e-13

Distance 162 3e-28 2e-30

93

As illustrated in Figure 5.6, it is clear that at a low application data rate (less

than or equal the BluetoothV2.1+EDR maximum rate), the three technologies are

equal in terms of network throughput. When the application data rate increases,

BluetoothV3.0 benefit from the alternative controller high data rate to provide a

faster data transmission.

The use of time division multiplexing and a different frequency hopping

sequence per piconet allowed BluetoothV2.1+EDR to minimize the collisions and

competence on the shared medium between connections, leading to maintaining the

same network throughput with different number of connections.

BToWiFi as expected loses those benefits when it turns on the IEEE802.11g

interface. To avoid collisions when IEEE802.11g interface is on, CSMA/CA

prevents the node from transmitting when the channel is not idle, making nodes wait

for each other before transmitting. Thus, increasing the number of connections has a

significant effect on BToWiFi.

Not only that, throughput become even more affected by the number of

connections as the application data rate increases and the throughput drop caused by

adding a single new connection increases. For example, while having one connection

at 10Mbps application data rate, adding a second‎ connection‎ doesn’t‎ affect‎

throughput‎much‎as‎the‎maximum‎capacity‎hasn’t‎yet‎been‎reached. But at 30Mbps

adding a second connection dropped the throughput to almost half due to medium

saturation.

Figure ‎5.6 Throughput of BluetoothV2.1+EDR, BToWiFi and BToUWB

94

With the proposed BToUWB controller, throughput is not affected by the

number of connections nor the application data rate. The reason BToUWB being

unaffected by the number of connections can be traced back to using separate THS

per connection and having much larger raw data rate.

By comparing the throughput performance of the proposed BToUWB and that

of BToWiFi, the proposed BToUWB maintains the same throughput of BToWiFi for

moderate rates and with small number of connections. At high rates and large

number of connections the proposed BToUWB can reach up to 675% the throughput

of BToWiFi and 2140% of that of Bluetooth BR/EDR.

5.3.2 Transfer Time

In Figure 5.7 we show a comparison between the three technologies in terms of

transfer time. From the figure it is clear that at application data rates less than or

equal the BluetoothV2.1+EDR data rate, the three technologies are equal in terms of

the time needed to transfer the same amount of data. By increasing the application

data rate, Bluetooth benefit from the alternative controller high data rates to

minimize the transfer time and save time.

Saving time is important as the Bluetooth only represents a communication

subsystem in a device, so by completing its operation as fast as it can would cause

other communication related device components to turn off saving energy. Also form

the customer perspective; it is less time to wait before being able to reuse the

connection.

UWB raw throughput is much larger than that of IEEE802.11g and that has a

major effect on the transfer time as can be seen in Figure 5.7. The proposed

BToUWB transfer time is neither affected by the number of connections nor the

increase in the application data rate. While BToWiFi transfer time increases as the

number of connections increase and is highly affected by the increase in the

application data rate.

In all cases, the transfer time of the proposed BToUWB is less or equal to that

of BToWiFi and Bluetooth BR/EDR. The proposed BToUWB transfer time can

reach up to 15% of that of BToWiFi and 5% of that of Bluetooth BR/EDR at high

rates and large number of connections.

95

5.3.3 Energy Consumption per Bit

This section is divided to three subsections; the first subsection compares the

energy consumption per bit of BluetoothV3.0, standalone IEEE802.11g and

standalone TH IR-UWB at a 1Mbps application data rate for a different number of

connections. The second subsection compares BluetoothV2.1, BToWiFi and

BToUWB at higher application data rates. The final subsection compares the time

spent by WiFi and UWB to transmit and receive data at different application data

rates.

5.3.3.1 At Low Rates

In Figure 5.8 we compare between TH IR-UWB, WiFi and Bluetooth V3.0.

The reason of doing this comparison is to see which technology can be used for both

low and high rates in an energy efficient manner. If the energy consumption of the

TH IR-UWB is less than that of Bluetooth at low rate, then it might be better to use

UWB instead of Bluetooth V3.0.

The results shows that at low application data rate, high speed BluetoothV3.0

benefits from the BluetoothV2.1+EDR low-rate, low-power radio interface to

transfer‎ the‎ data,‎while‎ IEEE802.11g‎ and‎UWB‎ can’t‎ benefit‎ from‎ their‎ high‎ data‎

rates. As the energy consumption of IEEE802.11g and UWB is higher than that of

Figure ‎5.7 Transfer time of BluetoothV2.1+EDR, BToWiFi and BToUWB

96

Bluetooth and the high rate is of no use at the low application data rates,

BluetoothV3.0 becomes more energy efficient than IEEE802.11g and UWB.

The results can be traced back to having an IEEE 802.11g or UWB node in ad-

hoc mode needs to be able to receive a packet from any node in the ad-hoc network

at any time. This means that it needs to have its receiver active for long periods of

time which consumes energy even if the node is not sending or receiving. While in

BluetoothV3.0, at low rates the alternative controllers are off and the BR/EDR radio

is being used. The Bluetooth BR/EDR radio energy consumption is less than that of

WiFi and UWB. The Bluetooth BR/EDR radio can also enter a low-power state to

save energy when not being used. Making BluetoothV3.0 more energy efficient than

TH IR-UWB and WiFi.

5.3.3.2 At High Rates

At higher application data rates, BluetoothV3.0 switches on the alternative

high-rate controller only to transfer data, then switch it off after the transfer

completion, returning back to the Bluetooth low duty cycle to listen for new

connection requests. This switching policy leads to lowering the total energy

consumption, making BluetoothV3.0 more energy efficient than a standalone

IEEE802.11g or UWB device.

Figure ‎5.8 Energy consumption per bit of BluetoothV3.0, IEEE802.11g

and TH IR-UWB at 1Mbps

97

Figure 5.9 compares between Bluetooth V2.1, BToWiFi and the proposed

BToUWB. It shows that BToWiFi becomes more energy efficient than

BluetoothV2.1+EDR only at high application data rates (30Mbps) and only for a

small number of connections (up to 2 connections). Using IEEE802.11g as the

alternative controller decreases the transfer time but it does so in an energy

inefficient manner.

The BToWiFi results having almost always higher energy consumption than

that of Bluetooth were unexpected. When the Bluetooth SIG selected WiFi as the

bases of their alternative controller, their argument was that the WiFi will need less

transfer time than the Bluetooth radio. So even if the WiFi radio power consumption

is‎higher‎than‎that‎of‎the‎Bluetooth‎radio,‎it‎won’t‎be‎active‎long‎enough‎to‎consume

energy more than what the Bluetooth radio would have consumed over its long

period of transmission. As seen in Figure 5.9, their argument has proven to be wrong

as WiFi is not fast enough leading to a faster depletion of the battery as displayed in

Figure 5.10.

The proposed BToUWB on the other hand is always more energy efficient than

BluetoothV2.1+EDR. BToUWB energy efficiency even increases as the application

data rate increase due to the decrease of the idle time and not being affected by the

number of connections. The proposed BToUWB is fast enough and consumes less

Figure ‎5.9 Energy consumption per bit of BluetoothV2.1+EDR, BToWiFi

and BToUWB for high data rates

98

energy than that of WiFi which makes it satisfy the Bluetooth SIG argument. The

proposed BToUWB would also leads to a longer battery life time compared to

Bluetooth BR/EDR and BToWiFi as represented in Figure 5.10.

From Figure 5.10, at application rate 30 Mbps and with 6 connections, each

BToWiFi node consumes almost 18% of the battery while each BToUWB node

consumes only 1% and each Bluetooth BR/EDR node consumes 7%. These results

indicate that BToWiFi would be a bad choice for battery powered devices.

The proposed BToUWB energy consumption per bit ranges from 26% to 5% of

that of BToWiFi and ranges from 71% to 10% of that of Bluetooth BR/EDR.

BToUWB energy efficiency increases as the data rate and number of connections

increase and is always more energy efficient than both BToWiFi and Bluetooth

BR/EDR at high rates.

5.3.3.3 WiFi and UWB Active Periods

In Figure 5.11 a comparison is made between BToWiFi and BToUWB in terms

of the transmitter ON time and receiver ON time required for applications at 5, 10

and 30 Mbps running for 15 seconds to send data. From this comparison, we can see

that the smaller power consumption of the UWB interface is caused by the use of

short pulses constantly instead of transmitting modulated waves continuously like

IEEE802.11g and most of narrowband systems. The use of short pulses by the UWB

Figure ‎5.10 Energy Consumption Percentage per node of BluetoothV2.1+EDR,

BToWiFi and BToUWB for high data rates

99

has lead to a shorter ON time for both the transmitter and receiver. This is translated

to smaller energy consumption when using UWB.

5.3.4 Average End-to-End Delay

Figure 5.12 shows that BToUWB end-to-end delay is similar to that of

BToWiFi at low data rate. However, at high data rates BToUWB provides a shorter

end-to-end delay than that of BToWiFi.

Figure ‎5.12 End-to-End packet delayof BluetoothV2.1+EDR, BToWiFi

and BToUWB

Figure ‎5.11 IEEE802.11g VS TH IR-UWB (a) Transmitter ON time, (b)

Receiver ON time

011

It also worth noticing that the end-to-end delay while using BToUWB is

slightly affected by the number of connections unlike the BToWiFi which is highly

affected. In BToUWB, the average packet delay almost remains constant which

suites better video streaming applications and‎ other‎ applications‎ that‎ can’t‎ tolerate‎

jitter. BToUWB provides a fair share of the bandwidth where adding a new

connection‎won’t‎affect‎the‎old‎ones. Fair share is provided by using a separate THS

for each connection.

The proposed BToUWB end-to-end delay can reach 20% of that of BToWiFi

and 5% of that of Bluetooth BR/EDR at high rates and large number of connections

making it more suitable for streaming applications.

5.4 Comments on the Simulation Results

This section illustrates the general conclusion drawn from the performance

evaluation of the proposed alternative controller (DCC TH IR-UWB) in comparison

with the BluetoothV3.0+HS core specifications proposed controller (IEEE802.11g).

In this comparison, the average network throughput, the average network transfer

time, the network energy efficiency and the packet average end-to-end delay, have

been used as quantitative metrics.

In terms of throughput and transfer time, IEEE802.11g as an alternative

controller met the goal of the BluetoothV3.0+HS specifications to provide Bluetooth

with higher data rates to meet the requirements of the high rate applications. But in

terms of energy efficiency measured here in terms of energy consumption per data

bit, IEEE802.11g provides a higher data rate but it does so in an energy inefficient

manner. IEEE802.11g energy efficiency is highly affected by the number of

connections. From the above we conclude that IEEE802.11g as an alternative

controller represents a bad choice for a battery powered device.

On the other hand, the proposed BToUWB alternative controller provides

higher data rates than that of IEEE802.11g. In contrast to IEEE802.11g, BToUWB

provides high data rates in an energy efficient manner‎and‎ its’‎energy‎efficiency‎ is‎

not affected by the number of connections. BToUWB high data rate and energy

efficiency make BToUWB more suitable for meeting the needs of the high rate

applications running on battery powered devices.

010

BToUWB combines the benefits of both Bluetooth and UWB. From Bluetooth,

BToUWB takes the energy efficiency at low data rates, paring mechanism, security

and the list of all available profiles. From UWB, BToUWB takes the energy efficient

high rate transmission capability. By combining those benefits BToUWB becomes

more energy efficient than the stand alone UWB.

Table 5.4 compares BToUWB with BToWiFi and Bluetooth BR/EDR. The

values in this table are calculated by dividing the BToUWB metrics by that of the

BToWiFi and by that of the Bluetooth BR/EDR.

For the throughput, BToUWB maintains the same throughput as BToWiFi at

low rates then increases to reach 675% of that of BToWiFi at high rate. BToUWB

throughput ranges from 280% to 2143% of that of Bluetooth BR/EDR.

For the transfer time, BToUWB maintains the same as BToWiFi at low rates

then decreases to reach 23% of that of BToWiFi at high rate. BToUWB transfer time

is always less than that of Bluetooth BR/EDR and ranges from 36% to 5% of that of

Bluetooth BR/EDR.

For the energy consumption per bit, BToUWB is always more energy efficient

than both BToWiFi and Bluetooth BR/EDR. BToUWB energy consumption per bit

ranges from 26% to 5% of that of BToWiFi and from 71% to 10% of that of

Bluetooth BR/EDR.

For the end-to-end delay, BToUWB maintains the same as BToWiFi at low

rates then decreases to reach 20% of that of BToWiFi at high rate. BToUWB end-to-

end delay is always less than that of Bluetooth BR/EDR and ranges from 36% to 5%

of that of Bluetooth BR/EDR.

Finally the total energy consumption per node, BToUWB is always consuming

less energy that both BToWiFi and Bluetooth BR/EDR. BToUWB energy

consumption per node ranges from 26% to 4% of that of BToWiFi and from 71% to

9% of that of Bluetooth BR/EDR.

012

Table ‎5.4 Comparison between BToUWB with BToWiFi and Bluetooth

Ra

te (

Mb

ps)

Co

nn

ecti

on

s

Throughput Transfer

Time

Energy per

Bit Delay

Total Energy

Consumption

BT

oW

iFi

Blu

etoo

th

BR

/ED

R

BT

oW

iFi

Blu

etoo

th

BR

/ED

R

BT

oW

iFi

Blu

etoo

th

BR

/ED

R

BT

oW

iFi

Blu

etoo

th

BR

/ED

R

BT

oW

iFi

Blu

etoo

th

BR

/ED

R

5 1 100% 280% 100% 36% 26% 71% 100% 36% 26% 71%

5 2 100% 293% 100% 34% 25% 71% 100% 35% 25% 71%

5 3 100% 307% 100% 33% 24% 67% 100% 33% 24% 67%

5 4 100% 315% 100% 32% 23% 67% 100% 32% 23% 67%

5 5 100% 329% 100% 30% 22% 66% 100% 31% 22% 66%

5 6 108% 348% 92% 29% 21% 66% 86% 28% 21% 67%

10 1 100% 560% 100% 18% 25% 36% 100% 18% 25% 36%

10 2 100% 580% 100% 17% 23% 36% 100% 17% 23% 36%

10 3 109% 611% 93% 16% 21% 34% 92% 16% 21% 34%

10 4 144% 628% 69% 16% 17% 33% 67% 16% 17% 33%

10 5 176% 659% 57% 15% 15% 33% 53% 15% 15% 33%

10 6 212% 710% 47% 14% 13% 34% 43% 13% 13% 34%

30 1 127% 1674% 79% 6% 18% 12% 79% 6% 18% 12%

30 2 213% 1734% 47% 6% 12% 12% 47% 6% 12% 12%

30 3 326% 1837% 31% 5% 9% 11% 30% 5% 9% 11%

30 4 440% 1897% 23% 5% 6% 10% 20% 5% 6% 10%

30 5 557% 1989% 18% 5% 5% 10% 31% 9% 5% 10%

30 6 675% 2143% 15% 5% 5% 12% 27% 8% 4% 9%

013

5.5 Conclusion

In this chapter, we have presented our NS2 BluetoothV3.0 model and then used

this model to simulate a normal Bluetooth operating environment. A number of

scenarios were created to compare the performance of the proposed controller to that

proposed by the Bluetooth SIG while using Bluetooth BR/EDR as a benchmark. Four

metrics were used which are throughput, transfer time, energy consumption per bit

and end-to-end delay. Scenarios were built with different number of connections,

distance between nodes and application rates.

The simulation results show that the Bluetooth SIG proposed controller failed

to meet the needs of the battery powered devices and streaming applications. While

our proposed controller met those needs and provided a better solution both in terms

of supported throughput and energy efficiency.

Chapter

6 Conclusions and Future Work

015

Chapter 6

Conclusions and Future Work


simple point-to-multipoint cable replacement applications. Bluetooth was then used

to form ad-hoc connections and even for building multi-hop ad-hoc networks.

Bluetooth has failed to support applications with high bandwidth demands such as

high-quality video streaming due to its low transmission rate.

Bluetooth V3.0 introduces the use of an alternative controller that provides a

high speed alternative radio link. Bluetooth SIG selected to build its alternative

controller on the IEEE 802.11g wireless technology.

6.1 Conclusions

In this study we propose another controller based on the UWB technology. The

proposed controller uses DCC TH IR-UWB instead of IEEEE802.11g. The two

alternative controllers are then evaluated by means of computer simulations in terms

of throughput, transfer time, energy efficiency and end-to-end delay.

A simulation model for the Bluetooth V3.0 was needed to be able to get more

insight and better understanding of the alternative controllers. For that we extended

the NS2 Bluetooth model (UCBT). The extended model simulates both the Bluetooth

SIG and the proposed alternative controllers and gives the ability to add more

controllers. The extended model is made publicly available for all researchers.

The simulation experiments herein reveal that BluetoothV3.0 has made benefit

of the BluetoothV2.1+EDR radio low power to overcome the high power

consumption of IEEE802.11g and UWB at low application data rates. Also

BluetoothV3.0 has made benefit of the high data rate of IEEE 802.11g or UWB for a

faster transmission.

The combination between wireless technologies in BluetoothV3.0 makes it

more energy efficient than a standalone IEEE802.11g or UWB.

We also conclude, based on the results of simulations that IEEE802.11g

controller has increased the throughput but in an energy inefficient manner and its

016

throughput is highly affected by the number of connections and application data rate,

making it a bad choice for battery powered devices.

The proposed DCC TH IR-UWB controller on the other hand, provides better

overall performance in terms of throughput, energy efficiency and ability to work in

a more crowded environment providing a better choice as a Bluetooth low-power,

high-rate alternative controller.

The proposed controller has a limited data rate of 180 Mbps in order to

conserve the battery power. Applications with rates above 180 Mbps will not be

suitable to run on this controller. Such applications‎normally‎don’t run on wireless

technologies unless this wireless technology is only dedicated to high speed

applications.

6.2 Future Work

Future interesting research directions are highlighted in the following points:

Support of uncompressed video streaming: The‎ DCC‎MAC‎ still‎ can’t‎ support‎

transmitting uncompressed video streams due to its limited rate (180Mbps). The

limited rate is caused by the large PRP used in order to minimize the energy

consumption. The UWB field is still young; a lot of research is still required to

reach an optimal MAC that can provide low-power and high-rates.

Support of alternative controller connection over multiple hops: While this

research has only been concerned with the performance of the alternative

controller connections within a piconet, studying the connection performance

over multiple links (Scatternets) is left for future research.

Support of QoS and Guaranteed alternative controller links: In this research only

best effort alternative controller links were considered; supporting QoS for the

alternative controller links is left for future research.

Moving active channel between controllers: Studying moving an active channel

between two controllers and the effect of that on the packet loss.

Thesis

Outcomes

018

Thesis Outcomes

[1] Shady S. Khalifa, Hesham N. Elmahdy, Imane Aly Saroit and S.H. Ahmed, "An

Assessment of Ultra Wide Band As an Alternative Controller for Bluetooth to

Support High Rate Applications on Battery Powered Devices", CiiT International

Journal of Wireless Communication, vol.3, no.7, pp.546-552, May 2011,

DOI:WC052011012.

[2] The development of the HSBT open source model to extend the UCBT model for

modelling the BluetoothV3.0+HS core specifications in the NS2 simulation

environment. HSBT model is available online at: http://code.google.com/p/hsbt

and in the NS2 contributed code page under the UCBT simulation model section:


http://code.google.com/p/hsbt


References

001

References

[1] M. Kazantzidis, M. Gerla, P. Johansson and R. Kapoor, “Personal area

networks: Bluetooth or IEEE 802.11?”, International. Journal of Wireless

Information Networks, Special Issue MANETs Standards, Research,

Applications, vol.9, no.2 , pp.89-103 , April 2002.

[2] I. Crk, F. Albinali, C. Gniady and J. Hartman, “Understanding energy

consumption of sensor enabled applications on mobile phones”, Proceeding

of the 31st Annual International Conference of the IEEE Engineering in

Medicine and Biology Society, Minnesota, USA , pp.6885-6888, September

2009.

[3] R. Razavi, M. Fleury and M. Ghanbari, “Fuzzy Control of Adaptive Timeout

for Video Streaming over a Bluetooth Interconnect”, Proceeding of the 12th

IEEE Symposium on Computers and Communications, Santiago, Portugal,

pp.27-32, July 2007.

[4] Bluetooth‎ SIG,‎ “Bluetooth‎ Specification‎ Version 3.0 + HS”, Technical

Specification, Bluetooth SIG, 2009.

[5] Bluetooth‎ SIG,‎ “Bluetooth‎ Specification‎ Version 2.1 + EDR”, Technical


[6] IEEE,‎ “802.11g part 11: Wireless LAN medium access control (MAC) and

physical layer (PHY) specifications: Further higher data rate extension in the

2.4 ghz band, Amendment to IEEE 802.11 Standard”, Standard, New York ,

IEEE, 2003.

[7] Lewicki, J. Pavón, J. Talayssat, E. Dekneuvel and G. Jacquemod, “A Virtual

Prototype for Bluetooth over Ultra Wide Band System Level Design”,

Proceeding of the Design, automation and test in Europe Conf., Munich,

Germany, pp.804-807, March 2008.

[8] T. Pering, Y. Agarwal, R. Gupta and R. Want, “CoolSpots: Reducing the

Power Consumption of Wireless Mobile Devices with Multiple Radio

Interfaces”, Proceeding of the 4th international conference on Mobile

systems, applications and services, Uppsala, Sweden , pp.220-232, June 2006.

000

[9] Y. Jung, H. Jeong, E. Song, J. Lee, S.Lee, D. Seo, I. Song, S. Jung, J. Park, D.

Jeong and W. Kim, “A Dual-Mode Direct-Conversion CMOS Transceiver for

Bluetooth and 802.11b”, Proceeding of the 29th European Solid-State

Circuits Conference, Estoril, Portugal, pp.225-228, September 2003.

[10] H. Nikookar and R. Prasad, “Introduction to Ultra Wideband for Wireless

Communications”, Springer 2009.

[11] H. Labiod, H. Afifi and C. DE Santis, "Wi-Fi, Bluetooth, ZIGBEE and

WIMAX", Springer, 2007.

[12] Bluetooth SIG, “Bluetooth‎ Specification Version 4.0”, Technical


[13] Bluetooth SIG, “Bluetooth Network Encapsulation Protocol (BNEP)

Specification”, Technical Specification, Bluetooth SIG, 2003.

[14] A. Nallanathan, W. Feng and H. K. Garg, “Coexistence of wireless LANs and

Bluetooth networks in mutual interference environment: An integrated

analysis”, Computer Communications, vol.30, no.1, pp.192-201, 2006.

[15] N. Golmie, R. E. Van Dyck and A. Soltanian, “Interference of Bluetooth and

IEEE 802.11: Simulation Modeling and Performance Evaluation”,

Proceeding of the 4th ACM international workshop on Modeling, analysis

and simulation of wireless and mobile systems, Rome, Italy, pp.11-18, July

2001.

[16] Kh. Shuaib, M. Alnuaimi, M. Boulmalf, I. Jawhar, F. Sallabi and A. Lakas,

“Performance Evaluation of IEEE 802.15.4 Experimental and Simulation

Results”, Journal of Communications, vol.2, no.4, pp.29-37, 2007.

[17] Y. Xiao and Y. Pan, “Emerging‎wireless‎LANs, wireless PANs and wireless

MANs”, Wiley 2009.

[18] IEEE 802.11a work group, “Part 11. Wireless LAN medium access control

(MAC) and physical layer (PHY) specification: high-speed physical layer in

the 5GHz band”, Standard, IEEE, 1999.

[19] IEEE 802.11b work group, “Part 11. Wireless LAN medium access control

(MAC) and physical layer (PHY) specifications: High-speed physical layer

extension in the 2.4GHz band”, Standard, IEEE, 1999.

002

[20] IEEE 802.11e work group, “Part 11. Wireless LAN medium access control

(MAC) and physical layer (PHY) specifications: amendment 8: Medium

access control (MAC) quality of service enhancements”,‎ Standard, IEEE,

2005.

[21] IEEE 802.11n work group, “Part 11. Wireless LAN medium access control

(MAC) and physical layer (PHY) specifications: amendment Amendment 5:

Enhancements for Higher Throughput”, Standard, IEEE, 2009.

[22] Federal Communications Commission, “Federal Communications

Commission(FCC 02-48) ET Docket 98-153 (Revision of Part 15 of the

Commission’s‎ Rules Regarding Ultra-Wideband Transmission Systems)”,

Regulation, 2002.

[23] IEEE 802.15.3 work group, “IEEE‎ P802.15-03/268r3: Multi-Band OFDM

Physical Layer Proposal”, Technical Proposal, IEEE, 2004.

[24] IEEE 802.15.3 work group, “IEEE P802.15-04/0137r1: DS-UWB Physical

Layer Proposal”,‎Technical‎Proposal,‎IEEE,‎2004.

[25] Agere, HP, Intel, Microsoft, NEC, Philips and Samsung, “Wireless Universal

Serial Bus Specification v1.0”, Technical Specification, USB Implementers

Forum, 2005.

[26] Wimedia Alliance, “ECMA-368: High Rate Ultra Wideband PHY and MAC

Standard 2nd edition”,‎Standard, ECMA, 2008.

[27] Wimedia Alliance, “ECMA-369: MAC-PHY Interface for ECMA-368 2nd

edition”, Standard, ECMA, 2008.

[28] E. Linde, “An Investigation Into The Viability Of UWB As lower-Layer For

Bluetooth”, Masters Thesis, University of Pretoria, Department of Electrical,

Electronic and Computer Engineering, 2009.

[29] J. R. Fernandes and D. Wentzloff, “Recent Advances in IR-UWB

Transceivers: An Overview”, Proceeding of IEEE International Symposium

on Circuits and Systems, Paris, France , pp.324-328, June 2010.

[30] X. Shen, W. Zhuang, H. Jiang and J. Cai, “Medium Access Control in Ultra-

Wideband Wireless Networks”, IEEE Transaction on Vehicular Technology,

vol.54, no.5, pp.1663-1677, September 2005.

003

[31] Z. Kong, D. Tsang, B. Bensaou and D. Gao, “Performance analysis of IEEE

802.11e contention-based channel access”, IEEE Journal on Selected Areas in

Communications, vol.22, no.10, pp.2095-2106, August 2004.

[32] J. Le Boudec, R. Merz, B. Radunovic and J. Widmer, “DCC-MAC: A

Decentralized MAC Protocol for 802.15.4a-like UWB Mobile Ad-Hoc

Networks Based on Dynamic Channel Coding”, Proceeding of the first

International Conference on Broadband Networks, California, USA, pp.396-

405, October 2004.

[33] A. Hyseni, N. Riaz and M. Ghavami, “Comparative investigation of

performance of ultra-wideband multiple access schemes for wireless sensor

networks”, BT Technology Journal, vol.26, no.1, pp.133-139, September

2008.

[34] B. Gupta and P. Mohapatra, “A survey on ultra wide band medium access

control schemes”, Computer Networks, vol.51, no.11, pp. 2976-2993, 2007.

[35] S. Aedudodla, S. Vijayakumaran and T. F. Wong, “Rapid ultrawideband

signal acquisition”, Proceeding of IEEE Wireless Communications and

Networking Conference, Georgia, USA, pp.1148-1153, March 2004.

[36] M. Hämäläinen, J. Saloranta, J. Mäkelä, I. Oppermann and T. Patana, “Ultra

Wideband Signal Impact on IEEE802.11b and Bluetooth Performances”,

Proceeding of the 14th IEEE Proceedings on Personal, Indoor and Mobile

Radio Communications, Beijing, China, pp.280-284, September 2003.

[37] Y. Jeon, S. Lee, S. Lee, S. Choi and D. Y. Kim, “High definition video

transmission using bluetooth over UWB”, IEEE Transactions on Consumer

Electronics, vol.56, pp.27-33, February 2010.

[38] A. Bit, M. Orehek and W. Zia, “Comparative analysis of Bluetooth 3.0 with

UWB and Certified Wireless-USB protocols”, Proceeding of IEEE

International Conference on Ultra-Wideband, Nanjing, China , pp.1-4,

September 2010.

[39] J. Park and J. Lee, “Compact UWB chip antenna design using the coupling

concept”, Progress In Electromagnetics Research, vol.90, pp.341-351, 2009.

[40] A. Medi and W. Namgoong, “A High Data-Rate Energy-Efficient

Interference-Tolerant Fully Integrated CMOS Frequency Channelized UWB

004

Transceiver for Impulse Radio”, IEEE Journal of Solid-State Circuits, vol.43,

no.4, pp.974-980, December 2008.

[41] IEEE 802.15.3 work group, “IEEE Std 802.15.3TM-2003: Wireless Medium

Access Control (MAC) and Physical Layer (PHY) Specifications for High

Rate Wireless Personal Area Networks (WPANs)”, Standard, IEEE, 2003.

[42] P. Frenger, P. Orten, T. Ottosson and A. Syensson, “Rate-Compatible

Convolutional Codes for Multirate DS-CDMA Systems”, IEEE Transactions

on Communications, vol.47, no.6, pp.828-836, June 1999.

[43] J. G. Proakis, “Digital Communications”, 4th edition, McGraw-Hill, 2001.

[44] F. Huang, “Evaluation of Soft Output‎Decoding‎ for‎Turbo‎Codes”, Masters

Thesis, Virginia Polytechnic Institute, Department of Electrical Engineering,

1997.

[45] T. Lkhagvatseren and F.‎ Hruska,‎ “Path‎ loss‎ aspects‎ of‎ a‎ wireless‎

communication system‎ for‎ sensors”,‎ International‎ journal‎ of‎ computers‎ and‎

communications, vol.5, pp.18-26, 2011.

[46] S. Ghassemzadeh and V.‎ Tarokh,‎ “UWB‎ path‎ loss‎ characterization‎ in‎

residential‎ environments”,‎ Proceeding‎ of‎ IEEE‎Radio‎ Frequency‎ Integrated‎

Circuits Symposium, Philadelphia, USA , pp.501-504, June 2003.

[47] BlueCore 6, http://www.csr.com/products/18/bluecore6-rom (accessed June

18, 2011).

[48] NXP BGW211 Low-power WLAN 802.11g SiP, http://www.mt-

system.ru/documents/bgw211.pdf (accessed June 18, 2011).

[49] Highland Systems, “SuiteTooth: Bluetooth simulation model Suite for

Opnet”, Technical Report, Highland Systems, 2004.

[50] OPNET, http://www.opnet.com/ (accessed June 18, 2011).

[51] UCBT-Bluetooth Network Simulator, http://www.cs.uc.edu/~cdmc/ucbt/

(accessed June 18, 2011).

[52] Q. Wang, “Scheduling and Simulation of Large Scale Wireless Personal Area

Networks”, PhD Thesis, University of Cincinnati, Department of Computer

Science and Engineering, 2006.

[53] Network Simulator 2 (NS-2), http://www.isi.edu/nsnam/ns/ (accessed June

18, 2011).

005

[54] HSBT-High Speed Bluetooth NS-2 extension, http://code.google.com/p/hsbt

(accessed June 18, 2011).

[55] EPFL-UWB extension for NS-2, http://uwb.epfl.ch/ns-2/index.html (accessed

June 18, 2011).

[56] G.‎Heiman,‎“Basic Statistics for the Behavioural Sciences”, Sixth edition,

Wadsworth Cengage Learning, 2011

.

Appendix

A

NS2 Experiments TCL Script

007

Appendix A

NS2 Experiments TCL Script

# Instead of doing changes to the code for every run just set the run number #and the TCL script will modify the parameters accordingly if {$argc != 1 } { puts "Please insert the run number 0 -> 31" set r 0 } else { set r [lindex $argv 0] } # ====================================== # Define Node Configuration parameters #======================================= set val(mac) Mac/BNEP set val(palType) PAL/UWB ;#PAL/802_11 or PAL/UWB set val(prop) Propagation/TwoRayGround set val(chan) Channel/WirelessChannel set modulationInstance_ [new Modulation/CodedPPM] set val(energy) EnergyModel set val(initialenergy) 10800000 ;# Initial power in Watts = 3Wh set val(txPower_) 108 ;# Active alternative MAC/PHY TX Energy consumption # per second; WiFi = 592 and UWB = 108 set val(rxPower_) 98 ;# Active alternative MAC/PHY RX Energy consumption #per second; WiFi = 375 and UWB = 98 set val(idlePower_) 80;# Active alternative MAC/PHY Idle Energy #consumption per second; WiFi = 300 and UWB = 80 set val(sleepPower_) 10 set val(transitionPower_) 10 set val(transitionTime_) 0.005 set val(btActiveEnrgConRate_) 81 ;# Active BT Energy consumption per #second set val(x) 50 ;# X dimension of the topography set val(y) 50 ;# Y dimension of the topography set val(trafficStartTime) 7 set val(trafficStopTime) 22 set val(simulationStopTime) 40 ################################################## # ====================================== # Define Node Configuration variables #======================================= ##### packetGenerationRate in bits/sec possible values ###### set pr(0) 1000000 set pr(1) 5000000 set pr(2) 10000000 set pr(3) 30000000 ########################################################

008

set val(numberOfConnections) [expr (($r%8)+1)] set val(nn) [expr ($val(numberOfConnections)*2)] ;# number of #mobilenodes # total number of MACs = twice number of nodes as each node has 2 MACs set val(numberOfMACs) [expr ($val(nn)*2)] ;# total number of MACs set val(application) "CBR" set val(agent) "UDP" ;# "UDP" , "TCP" set val(controller) "UWB" ;# "BT2.1+EDR","802.11b" , "802.11g" , "UWB" set val(version) "802.11g" ;#"802.11b" , "802.11g" note : must be set though it #is only used when the controller is "802.11b" , "802.11g" set val(packetGenerationRate) [expr ($pr([expr int(floor($r/8)) % 4]))] ;#send #rate during on time (bps) set val(packetSize) 1400 #================= # Initialize #================= # *** Initialize Simulator *** set ns_ [new Simulator] # *** Initialize Results file *** set filename "$r$val(controller)$val(agent)results.csv" set resultsf [open $filename w] # *** Initialize Trace file *** set filename "$r$val(controller)$val(agent)trace.csv" set tracefd [open $filename w] $ns_ trace-all $tracefd # *** Initialize Network Animator *** set filename "$r$val(controller)$val(agent)nam.nam" set namtrace [open $filename w] $ns_ namtrace-all-wireless $namtrace $val(x) $val(y) # *** set up topography object *** set chan [new $val(chan)];#Create wireless channel set topo [new Topography] $topo load_flatgrid $val(x) $val(y) # Create General Operations Director (GOD) object. It is used to store global #information about the state of the environment, network, or nodes that an # omniscent observer would have, but that should not be made known to any #participant in the simulation. create-god $val(numberOfMACs)

009

#================= # configure nodes #================= $ns_ node-config -macType $val(mac) \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \ -movementTrace OFF \ -energyModel $val(energy) \ -initialEnergy $val(initialenergy) #================= # create nodes #================= for {set i 0} {$i < $val(nn) } {incr i} { set node_($i) [$ns_ node $i] $node_($i) rt AODV $node_($i) on [$node_($i) set l2cap_] set ifq_limit_ 30 ;#set the size of the queue for the L2CAP layer $node_($i) set-rate 3 ;# set 3mb high rate set bb($i) [$node_($i) set bb_] $bb($i) set energy_ $val(initialenergy) $bb($i) set activeEnrgConRate_ $val(btActiveEnrgConRate_) ############# Add node trace ################### set filename "$r$val(controller)$val(agent)node$i.csv" set nodeTrace($i) [open $filename w] puts $nodeTrace($i) "Time BTEn AmpEn IdleT IdleE TXT TXE RXT RXE" } ############# Add PAL/Controller ##################### for {set i 0} {$i < $val(nn) } {incr i} { $node_($i) add-PAL $val(palType) $val(version) $topo $chan $val(prop) \ $val(txPower_) $val(rxPower_) $val(idlePower_) \ $val(sleepPower_) $val(transitionPower_) $val(transitionTime_) \ $modulationInstance_ } set ifq [new Queue/DropTail] ;#Declaration of the queue or buffer $ifq set limit_ 20 ;#Limit the queue (packet)

021

#============================== # Setup traffic flow between nodes #============================== for {set i 0} {$i < $val(numberOfConnections) } {incr i} { # Create Constant Bit Rate Traffic sources if { $val(agent)=="UDP"} { set agent($i) [new Agent/UDP] ;# Create UDP Agent } else { set agent($i) [new Agent/TCP] ;# Create TCP Agent } $agent($i) set prio_ 0 ;# Set Its priority to 0 $agent($i) set packetSize_ 1500 if { $val(agent)=="UDP"} { set sink($i) [new Agent/LossMonitor] ;# Create Loss Monitor Sink in order to be able to trace the number obytes received } else { set sink($i) [new Agent/TCPSink] } set j [expr (2 * $i)] if { $i < [expr ($val(nn)/2)]} { $ns_ attach-agent $node_($j) $agent($i) ;# Attach Agent to source node $ns_ attach-agent $node_([expr ($j+1)]) $sink($i) ;# Attach Agent to sink node puts "< $j [expr ($j+1)]" } else { $ns_ attach-agent $node_([expr (($i % ($val(nn)/2))*2+1)]) $agent($i) ;# Attach Agent to source node $ns_ attach-agent $node_([expr (($i % ($val(nn)/2))*2)]) $sink($i) ;# Attach Agent to sink node puts "> [expr (($i % ($val(nn)/2))*2+1)] [expr (($i % ($val(nn)/2))*2)]" } $ns_ connect $agent($i) $sink($i) ;# Connect the nodes set app($i) [new Application/Traffic/CBR] ;# Create Constant Bit Rate application $app($i) set packetSize_ $val(packetSize) ;# Set Packet Size $app($i) set rate_ $val(packetGenerationRate) ;# Set CBR rate $app($i) attach-agent $agent($i) ;# Attach Application to agent ############# Add connection trace ################### set filename "$r$val(controller)$val(agent)connection$i.csv" set connectionTrace($i) [open $filename w] puts $connectionTrace($i) "Time bytes packets Throughput loss delay totalReceived totalLost"

020

#============================== # Initialize value holders #============================== set holdtime($i) 0 set holdseq($i) 0 set holdrate($i) 0 set sentBytes($i) 0 set receivedBytes($i) 0 set oldReceivedBytes($i) 0 set totalSentBytes($i) 0 set totalReceivedBytes($i) 0 set totalLost($i) 0 set totalReceivedBytes($i) 0 set avgDelay($i) 0 set count($i) 0 set totalTime($i) 0 } #============================== # Create connections between nodes #============================== for {set i 0} {$i < $val(numberOfConnections) } {incr i} { set j [expr (2 * $i)] if { [string compare $val(controller) "802.11b"] == 0 || [string compare $val(controller) "802.11g"] == 0 || [string compare $val(controller) "UWB"] == 0} { if { $i < [expr ($val(nn)/2)]} { $ns_ at [expr ($i/10+0.2)] "$node_($j) make-hs-connection $node_([expr ($j+1)])" puts "($j) make-hs-connection [expr ($j+1)]" } else { #$ns_ at 0.1 "$node_([expr (($i % ($val(nn)/2))*2+1)]) make-hs-connection $node_([expr (($i % ($val(nn)/2))*2)])" puts "802.11 no con" } } elseif { [string compare $val(controller) "BT2.1+EDR"] == 0 } { if { $i < [expr ($val(nn)/2)]} { $ns_ at [expr ($i/10+0.2)] "$node_([expr ($j)]) make-bnep-connection $node_([expr ($j+1)]) 3-DH5 3-DH5 noqos $ifq" puts "[expr ($j)] make-bnep-connection [expr ($j+1)] DH5 DH5 noqos $ifq" } else { #$ns_ at 0.1 "$node_([expr ([expr (($i % ($val(nn)/2))*2+1)])]) make-bnep-connection $node_([expr (($i % ($val(nn)/2))*2)]) DH5 DH5 noqos $ifq" puts "bt no con" } } else { error "no type defined" }

022

$ns_ at [expr (($i/10+0.2)+1+($i*2/10))] "$app($i) start" ;# Start transmission AODV get route $ns_ at [expr (($i/10+0.2)+2+($i*2/10))] "$app($i) stop" ;# Stop transmission AODV get route $ns_ at [expr ($val(trafficStartTime)+($i*2/10))] "$app($i) start" ;# Start data transmission $ns_ at [expr ($val(trafficStopTime)+($i*2/10))] "$app($i) stop" ;# Stop data transmission } #========================================================== # Procedure record Statistics (Bit Rate, Delay, Drop,energy) #========================================================== proc record {} { global node_ app agent sink holdtime holdseq holdrate receivedBytes oldReceivedBytes sentBytes \ totalSentBytes totalReceivedBytes totalLost nodeTrace connectionTrace val avgDelay count totalTime set ns [Simulator instance] set time 0.5 ;#Set Sampling Time to 0.5 Sec set totalDataRate 0 set totalBytes 0 ############## Collect connections statistics ############# for {set i 0} {$i < $val(numberOfConnections) } {incr i} { set now [$ns now] if { $val(agent)=="UDP"} { set b($i) [$sink($i) set bytes_] set l($i) [$sink($i) set nlost_] set lpt($i) [$sink($i) set lastPktTime_] set np($i) [$sink($i) set npkts_] } else { set b($i) [$agent($i) set ndatabytes_] set l($i) [$agent($i) set nrexmitpack_] set np($i) [$agent($i) set ndatapack_] set lpt($i) $now } set receivedBytes($i) [expr ($receivedBytes($i)+$b($i))] set totalReceivedBytes($i) [expr ($totalReceivedBytes($i)+$b($i))] set totalLost($i) [expr ($totalLost($i)+$l($i))] set delay($i) [expr ($np($i) - $holdseq($i))] if { $np($i) > $holdseq($i) } { set delay($i) [expr ($lpt($i) - $holdtime($i))/($np($i) - $holdseq($i))] }

023

set totalDataRate [expr ($totalDataRate + [expr (($b($i)+$holdrate($i))*8)/(2*$time*1000000)])] set totalBytes [expr ($totalBytes + $receivedBytes($i))] if { [expr (($b($i)+$holdrate($i))*8)/(2*$time*1000000)] > 0 } { ########## save the collected statistics to the connection trace file ##### puts $connectionTrace($i) "$now $receivedBytes($i) $np($i) [expr (($b($i)+$holdrate($i))*8)/(2*$time*1000000)] [expr $l($i)/$time] $delay($i) $totalReceivedBytes($i) $totalLost($i)" # do not consider the first entry in calculating the averages if { $holdrate($i) > 0 } { if { $delay($i) > 0 } { set avgDelay($i) [expr ($avgDelay($i) + $delay($i))] set count($i) [expr ($count($i)+1)] } } if { $oldReceivedBytes($i) != $receivedBytes($i) } { set totalTime($i) [expr ($totalTime($i) + $time)] } } ############Reset Variables####################### if { $val(agent)=="UDP"} { $sink($i) set nlost_ 0 $sink($i) set bytes_ 0 } else { $agent($i) set ndatabytes_ 0 $agent($i) set nrexmitpack_ 0 } set oldReceivedBytes($i) $receivedBytes($i) set holdtime($i) $lpt($i) set holdseq($i) $np($i) set holdrate($i) $b($i) } ############## Collect nodes statistics ############# for {set i 0} {$i < $val(nn) } {incr i} { #BT energy set bb($i) [$node_($i) set bb_] set btEn($i) [$bb($i) set energy_] #amp Energy set ampEn($i) [$node_($i) ampEnergy] set ampIdleT($i) [$node_($i) ampIdleTime] set ampIdleE($i) [$node_($i) ampEnergyIdle] set ampTXT($i) [$node_($i) ampTXTime] set ampTXE($i) [$node_($i) ampEnergyTX] set ampRXT($i) [$node_($i) ampRXTime] set ampRXE($i) [$node_($i) ampEnergyRX] ########## save the collected statistics to the node trace file ##### puts $nodeTrace($i) "$now $btEn($i) $ampEn($i) $ampIdleT($i) $ampIdleE($i) $ampTXT($i) $ampTXE($i) $ampRXT($i) $ampRXE($i)" }

024

###### Add the stopping criteria which is only stop if there are nothing more to receive otherwise reschedule the record ################ if {$totalDataRate == 0 && $totalBytes > 0 && [$ns now] > $val(trafficStartTime)} { $ns at [expr ([$ns now]+0.5)] "stop" } else { $ns at [expr $now+$time] "record" ;# Schedule Record after $time interval sec } } ########## Start Recording at Time 0 ############## $ns_ at 0.0 "record" #========================================================== # Procedure stop finalize the statistics and close all trace files #========================================================== proc stop {} { global ns_ resultsf tracefd namtrace nodeTrace connectionTrace val r avgDelay count totalReceivedBytes totalTime totalLost sink node_ set networkDelay 0 set networkThroughput 0 set networkEnergyConsumption 0 set networkDeliveryRatio 0 set networkBytesReceived 0 set networkEnergyPerBit 0 set nonEstablishedConnections 0 set simulationTotalTime 0 puts $resultsf "agent controller Run_id application_Generation_Rate(bps) packet_Size(bytes) #nodes #Connections Distance(m) connection_id from to avg_Delay(sec) avg_rate(Mbps) avg_lost_ratio%(%packets) sent(bytes) received(bytes) total_time(sec) count Energy_per_bit(wpb)" for {set i 0} {$i < $val(numberOfConnections) } {incr i} { close $connectionTrace($i) set from [expr (2 * $i)] set to [expr ((2*$i)+1)] if { $i >= [expr ($val(nn)/2)]} { set from [expr (($i % ($val(nn)/2))*2+1)] set to [expr (($i % ($val(nn)/2))*2)] } set bb($to) [$node_($to) set bb_] set btEn($to) [$bb($to) set energy_] set ampEn($to) [$node_($to) ampEnergy] set totalEn($to) [expr (2 * $val(initialenergy) - $btEn($to) - $ampEn($to))]

set bb($from) [$node_($ from) set bb_] set btEn($from) [$bb($from) set energy_] set ampEn($from) [$node_($ from) ampEnergy] set totalEn($from) [expr (2 * $val(initialenergy) - $btEn($from) - $ampEn($from))]

025

if { $val(agent)=="UDP"} { set np($i) [$sink($i) set npkts_] } else { set np($i) 0 } if { $count($i) == 0 } {

set count($i) 1 set nonEstablishedConnections [expr ($nonEstablishedConnections + 1)] } if { $totalTime($i) == 0 } { set totalTime($i) 1 } if { $totalLost($i) == 0 } { set totalLost($i) 1 } if { $totalReceivedBytes($i) == 0 } { set totalReceivedBytes($i) 1 } puts $resultsf "$val(agent) $val(controller) $r $val(packetGenerationRate) $val(packetSize) $val(nn) $val(numberOfConnections) NA $i $from $to [expr ($avgDelay($i)/$count($i))] [expr (($totalReceivedBytes($i) * 8)/($totalTime($i) * 1000000))] [expr ($totalLost($i)*100 /($np($i)+$totalLost($i)))] NA $totalReceivedBytes($i) $totalTime($i) $count($i) [expr (($totalEn($to)+

$totalEn($from)) / ($totalReceivedBytes($i) * 8))]" set networkDelay [expr ($networkDelay + [expr ($avgDelay($i)/$count($i))] )] set networkThroughput [expr ($networkThroughput + [expr (($totalReceivedBytes($i) * 8)/($totalTime($i) * 1000000))])] set networkDeliveryRatio [expr ($networkDeliveryRatio + [expr (100*$totalLost($i)/($np($i)+$totalLost($i)))])] set networkBytesReceived [expr ($networkBytesReceived + $totalReceivedBytes($i))] set networkEnergyPerBit [expr ( $networkEnergyPerBit + $totalEn($to) + $totalEn($from))] set simulationTotalTime [expr ($simulationTotalTime + $totalTime($i))] } puts $resultsf "agent controller Run_id application_Generation_Rate(bps) packet_Size(bytes) #nodes #Connections Distance(m) node_id BT_energy(%mW) AMP_energy(%mW) total_energy_consumption(%mW) bt ampTotal idleE idleT RXE RXT TXE TXT sleepE sleepT" for {set i 0} {$i < $val(nn) } {incr i} { close $nodeTrace($i) set totalEn($i) [expr (2 * $val(initialenergy) )] set bb($i) [$node_($i) set bb_] set btEn($i) [$bb($i) set energy_] set totalEn($i) [expr ($totalEn($i) - $btEn($i))] set btEn($i) [expr (($val(initialenergy) - $btEn($i))*100/$val(initialenergy))] set ampEn($i) [$node_($i) ampEnergy] set totalEn($i) [expr ($totalEn($i) - $ampEn($i))]

026

set ampEn($i) [expr (($val(initialenergy) - $ampEn($i))*100/$val(initialenergy))] set totalEn($i) [expr (($totalEn($i))*100/(2*$val(initialenergy)))] set networkEnergyConsumption [expr ($networkEnergyConsumption + $totalEn($i))] puts $resultsf "$val(agent) $val(controller) $r $val(packetGenerationRate) $val(packetSize) $val(nn) $val(numberOfConnections) NA $i $btEn($i) $ampEn($i) $totalEn($i) [$bb($i) set energy_] [$node_($i) ampEnergy] [$node_($i) ampEnergyIdle] [$node_($i) ampIdleTime] [$node_($i) ampEnergyRX] [$node_($i) ampRXTime] [$node_($i) ampEnergyTX] [$node_($i) ampTXTime] [$node_($i) ampEnergySleep] [$node_($i) ampSleepTime]" }

set networkThroughput [expr ($networkThroughput /

$val(numberOfConnections) )] set networkDeliveryRatio [expr ($networkDeliveryRatio /

$val(numberOfConnections))] set networkDelay [expr ($networkDelay / $val(numberOfConnections))]

set simulationTotalTime [expr ($simulationTotalTime / $val(numberOfConnections))]

set networkEnergyConsumption [expr ($networkEnergyConsumption / $val(nn))] set networkEnergyPerBit [expr (($networkEnergyPerBit

/$networkBytesReceived)/ 8) ]

puts $resultsf "agent controller Run_id application_Generation_Rate(bps) packet_Size(bytes) #nodes #Connections Distance(m) avg_NW_Delay(sec) avg_NW_rate(Mbps) avg_NW_lost_ratio(%packets) NW_sent(bytes) NW_received(bytes) NW_Energy_per_bit(wpb) NW_total_energy_consumption(%mW) #nonEstablishedConnections simulationTotalTime" puts $resultsf "$val(agent) $val(controller) $r $val(packetGenerationRate) $val(packetSize) $val(nn) $val(numberOfConnections) NA $networkDelay $networkThroughput $networkDeliveryRatio NA $networkBytesReceived $networkEnergyPerBit $networkEnergyConsumption $nonEstablishedConnections $simulationTotalTime"

############ Flush Trace Files ################## close $resultsf $ns_ flush-trace close $tracefd close $namtrace exit 0 } puts "Starting Simulation..." $ns_ run

Appendix

B

Trace Files Format

028

Appendix B

Trace Files Format

Four types of trace files are generated after running the script in Appendix A,

those files are:

NS2 trace file: It is a single file per simulation run. This trace file follows the

UCBT trace format for the Bluetooth packets and the NS2 default format for the

alternative controllers (802.11 and UWB).

Connection trace file: For every connection, a separated file is created. A new

entry is added to this file every time the record procedure is called. This file

contains the following fields:

o Time: time stamp at which the record procedure was called.

o Bytes: number of bytes received since the last record.

o Packets: number of packets received since the last record.

o Throughput: the current connection throughput in the time between

the two records.

o Loss: percentage of the number of packets lost since the last record.

o Delay: average packet delay in the time between the two records.

o totalReceived: total number of bytes received

o totalLost: total percentage of the number of packets lost.

Node trace file: For every node a separated file is created. A new entry is added

to this file every time the record procedure is called. This file contains the

following fields:

o Time: time stamp at which the record procedure was called.

o BTEn: total energy consumed by the Bluetooth interface up till now.

o AmpEn: total energy consumed by the alternative controller interface

up till now.

o IdleT: total alternative controller idle time up till now.

o IdleE: total alternative controller energy consumption in the idle state

up till now.

029

o TXT: total alternative controller transmission time up till now.

o TXE: total alternative controller energy consumption in the transmit

state up till now.

o RXT: total alternative controller reception time up till now.

o RXE: total alternative controller energy consumption in the receive

state up till now.

Collective statistics trace file: It is a single file per simulation run. It consists of

three sections:

o Connections summary section: this section has a single record per

connection contains the final connection statistics. Connection

summary record consists of the following fields:

agent : “UDP”‎‎or‎“TCP”

controller: "BT2.1+EDR","802.11b" , "802.11g" , "UWB"

Run_id

application_Generation_Rate(bps)

packet_Size(bytes)

#nodes: number of nodes

#Connections: number of connections

Average Distance(m)

connection_id: connection identifier

From: source node address

To: destination node address

avg_Delay(sec): average connection packet delay

avg_rate(Mbps): average connection throughput

avg_lost_ratio%(%packets): average connection packets lost

percentage.

sent(bytes): not implemented, calculated from the NS2 trace

file.

received(bytes): total number of bytes received by the

connection.

031

total_time(sec): total connection active time to send and

receive all packets.

count : number of times the record procedure has been called.

Energy_per_bit(j/b): (Energy consumed to send + Energy

consumed to receive) / (Number of bits received)

o Nodes summary section: this section has a single record per node

contains the final node statistics. Node summary record consists of the

following fields:

Agent:‎“UDP”‎‎or‎“TCP”

Controller: "BT2.1+EDR","802.11b" , "802.11g" , "UWB"

Run_id


packet_Size(bytes)



Distance(m)

node_id: node address

BT_energy(%mW): energy percentage consumed by the

Bluetooth interface by this connection.

AMP_energy(%) : energy percentage consumed by the

alternative interface by this connection.

total_energy_consumption(%) : total energy percentage

consumed by the alternative interface by this connection.

Bt(mW): consumed energy by the Bluetooth interface by this

connection.

ampTotal(mW): total consumed energy by the alternative

interface by this connection.

idleE(mW): total consumed energy by the alternative interface

by this connection in the idle state.

idleT(sec): total time alternative interface spent in the idle

state.

030

RXE(mW): total consumed energy by the alternative interface

by this connection in the receive state.

RXT(sec): total time alternative interface spent in the receive

state.

TXE(mW): total consumed energy by the alternative interface

by this connection in the transmit state.

TXT(sec): total time alternative interface spent in the transmit

state.

sleepE(mW): total consumed energy by the alternative

interface by this connection in the sleep state.

sleepT(sec): total time alternative interface spent in the sleep

state.

o Network summary section: this section contains only a single record

which takes averages of the connections and nodes statistics. Network

summary record consists of the following fields:

Agent:‎“UDP”‎‎or‎“TCP”

Controller: "BT2.1+EDR","802.11b" , "802.11g" , "UWB"

Run_id


packet_Size(bytes)



Distance(m)

avg_NW_Delay(sec): average of all connections packet delay.

avg_NW_rate(Mbps): average of all connections throughput.

avg_NW_lost_ratio(%packets): average of all connections

packet loss percentage.

NW_sent(bytes): not implemented.

NW_received(bytes): total bytes received by all connections.

NW_Energy_per_bit(j/b): total energy consumed by all nodes/

total bits received by all connections.

032

NW_total_energy_consumption(%): average energy

consumption percentage of the nodes nodes.

#nonEstablishedConnections: number of connection failed to

establish due to collision.

simulationTotalTime: time taken to receive all packets by all

nodes.

Appendix

C

Propagation Models

034

Appendix C

Propagation Models

Two propagation models are used in this research ITU site-general model and

Tarokh model. The ITU site-general model is used with the 2.4GHz technologies like

Bluetooth and WiFi to model the signal propagation in an indoor environment. The

Tarokh model is used to model the Ultra Wide Band (UWB) signal propagation.

ITU site-general model

The ITU site-general model for path loss prediction in an indoor propagation

environment is given by equation 1:

Ltotal = 20 log10 f + N log10 d + Lf(n) – 28 (1)

where: Ltotal is the total pass loss in decibel (dB)

f is the transmission frequency in MHz

N is the distance power loss coefficient

d is the distance in meter (m) ( d >1)

Lf (n) is the floor penetration loss factor and n is the number of floors

between the transmitter and the receiver.

Tarokh model

The Tarokh model is a statistical path loss model for indoor UWB signals given

by equation 2:

Ltotal = PL0 +‎10‎γlog10 (d/d0) + S (2)

where: Ltotal is the total pass loss in decibel (dB)

PL0 is the Intercept Point, which is a fixed quantity and depends on the

materials blocking the signal within 1m.

035

γ‎is‎the‎path‎loss‎exponential‎which‎changes‎from‎one‎home‎to‎another‎

and have a normal distribution N[µγ ,σγ ].

d is the distance between source and destination (d0 is the reference

distance = 1 meter).

S is the Shadow fading, which varies randomly from one location to

another location within any home.

a strategy for improving bluetooth performancescholar.cu.edu.eg/?q=shkhalifa/files/a_strategy... ·...

Documents