Bluetooth-based Ad-Hoc Networks for Voice Transmission .1 Bluetooth-based Ad-Hoc Networks for Voice

  • View
    212

  • Download
    0

Embed Size (px)

Text of Bluetooth-based Ad-Hoc Networks for Voice Transmission .1 Bluetooth-based Ad-Hoc Networks for Voice

  • 1

    Bluetooth-based Ad-Hoc Networks for Voice Transmission

    Frank Kargl - Stefan Ribhegge - Stefan Schlott - Michael Weber Department of Multimedia Computing, Albert-Einstein-Allee 11,

    89081 Ulm, University of Ulm, Germany, +49-731-50-31310,

    frank.kargl|stefan.ribhegge|stefan.schlott|michael.weber@informatik.uni-ulm.de

    Abstract—In this paper we inspect the possibilities of us- ing Bluetooth for building Ad-Hoc networks suitable for transmitting audio and esp. voice data using synchronous SCO links. We analyze the features or problems that Bluetooth offers for transmitting audio data in a multihop network. As the existing MANET routing protocols that emerged out of the work of the IETF MANET WG (like AODV, DSR etc.) can not be directly used to work with Bluetooth, we present a new routing protocol called Blue- tooth Scatternet Routing (BSR) that is influenced by other MANET routing protocols but pays special attention to the restrictions of Bluetooth (like number of connections, con- nection setup times etc.). The protocol is also inspired by the channel switching concept of ATM. Some initial results of simulations and real-life tests give an impression of the performance and efficiency this protocol can reach in an ap- plication scenario.

    I. PAPER OUTLINE

    After section II gives an introduction to a scenario of voice transmission in a Bluetooth based MANET, sections III to V give a short overview on relevant aspects of Blue- tooth, MANETs and earlier work in this field. Section VI analyzes the benefits and problems of mobile ad-hoc net- working via Buetooth with special focus on audio/voice transmission. We argue that existing MANET routing pro- tocols cannot be used straightforward with Bluetooth but need adaption. In section VII we describe our contribu- tion: a routing protocol called ”Bluetooth Scatternet Rout- ing” (BSR). As the Bluetooth hard- and software avail- able today doesn’t implement the standard completely - e.g. often scatternet functionality is missing - we have implemented only parts of the protocol directly. Section VIII tries to evaluate the efficiency of BSR with an ap- proach combining measurements and simulation. Section IX concludes our paper with a summary and outlook.

    II. MOTIVATION

    Many of the research activities in the field of mobile ad-hoc networks (MANET) assume that cheap short to medium range radio transceivers will become very com- mon in the next years. Most of the practical work and

    BT

    BT

    BTBT

    Fig. 1. Example scenario of a Bluetooth ad-hoc network

    implementations focus on IEEE 802.11 Wireless LAN as an underlying physical radio network used for simulations or tests. For use in limited wearable devices like PDAs or cellphones, 802.11 has the disadvantage of consum- ing more battery power than other technologies like Blue- tooth [1][2]. Furthermore it seems that after some startup problems Bluetooth may really become a common fea- ture of cellphones (like the Ericsson T68m and others) or PDAs (like the new Compaq IPAQ 3870).

    So the developers of the MANET routing protocols should consider that their protocols might also be used in a Bluetooth environment. The initial goal of our work pre- sented here was to evaluate if the current protocols can be easily used in combination with Bluetooth or what modifi- cations need to be done to enable Bluetooth-based Ad-hoc networking.

    First we try to find a scenario where most of the char- acteristics and problems of MANETs and Bluetooth will appear. In this scenario we connect a large number of Bluetooth-enabled cellphones to a (multi-hop) MANET in order to enable Bluetooth-relayed phone calls between them.

    There are a large number of possible application fields for this scenario. Think of a large office building where people move a lot between their office desk, conference rooms or central areas like printer-rooms or the cafeteria. Fixed-line telephones don’t provide a reasonable grade of reachability here. So people tend to call their colleagues at their cellphone in order to find our their current location or to reach them for urgent requests etc. Of course the

  • 2

    RADIO BASEBAND

    HCI

    Bluetooth Hardware

    HCI

    Host

    L2CAP RFCOMM SDP ... PPP

    Application

    UART, USB, RS232 ...

    Fig. 2. Bluetooth stack

    network carrier of the cellular phone network charges for these calls. Given our scenario above people may be able to do the same calls at no cost.

    Another usage of the system proposed may be on large exhibits or fares where a lot of people with Bluetooth- enabled phones may meet. Again relaying calls between two visitors (like friends visiting different halls that want to meet for lunch) via a Bluetooth-based MANET may save costs compared to the normal cellular phone network.

    III. BLUETOOTH OVERVIEW

    In this section we will give a very brief overview of the relevant aspects of the Bluetooth standard. For detailed information see [1][2].

    When initiated in 1998, the original idea of Bluetooth was to create a cheap wireless replacement for the myriad of data wires that surround today’s multimedia devices.

    Bluetooth uses a protocol stack of several layers. Fig- ure 2 shows an simplified overview. The Radio Layer de- scribes the physical radio system. Bluetooth devices fall within one of three different radio classes, but nearly all of todays Bluetooth-enabled devices use Class 3 radios, esp. the smaller battery-powered systems like cellphones. These devices have a radio range of about 10m. Bluetooth uses a frequency hopping scheme where the hopping se- quence is coordinated by the master of each Piconet (see below).

    The Baseband Layer is responsible for transmission and reception of data packets, error detection and encryption (if used).

    The Link Controller uses a state machine to control syn- chronization, connection setup and shutdown. This state machine has different states that are called Standby, Page, PageScan, Inquiry, InquiryScan and Connection. A con- nected device may either be in the state Active, Hold, Sniff or Park. For details see [1].

    When a device wants to connect another device it first has to do an inquiry for its direct neighbors. After re- ceiving the inquiry results it can contact another device

    Scatternet w Slave

    in wo Piconets

    ith

    t

    M

    M

    S S/M

    M

    S

    Scatternet with Master in

    one and Slave in another Piconet

    Fig. 3. Examples of Scatternets

    using its unique Bluetooth address. When connected the two devices form a so-called Piconet. The initiator of the connection becomes the Master of this Piconet, the other device becomes a Slave. When the Master contacts addi- tional devices, this Piconet will contain multiple slaves up to a maximum of 7.

    When a device A that is e.g. a Slave in one Piconet con- tacts another device B then a new Piconet is formed with A being the Master in this new Piconet and still being a Slave in the original Piconet. Any connected combina- tion of Piconets is called a Scatternet. Figure 3 shows some Scatternet examples. A Scatternet is essentially some form of a MANET where traffic may be relayed between Piconets. Unfortunately the Bluetooth standard does not describe any Routing protocol for this and most of the hardware available today has no capability of form- ing Scatternets. Some even lack the ability to communi- cate between Slaves of one Piconet or to be a member of two Piconets at the same time. We will give details on this later.

    For building MANETs based on Bluetooth we need to find a suitable routing algorithm and implement this func- tionality on the application level. Later this may be inte- grated into the Bluetooth stack itself.

    After connecting another device, data may be trans- mitted using the ACL mode (Asynchronous Connection Less). In Bluetooth the data transmission is controlled completely by the Master. Slaves may only transmit data after being polled by the Master. ACL data transmission implements error detection and retransmission.

    The other transmission mode uses SCO links (Syn- chronous Connection Oriented). SCO links need to be established explicitely and only after an ACL connection has been setup. Each SCO link reserves 64kBit/s of band- width. In contrast to the ACL links, SCO links have no retransmission, packets with errors are silently discarded. A master may establish up to three SCO links to its slaves.

    The Host-Controller-Interface (HCI) separates the Bluetooth hardware from the part of the protocol stack that is usually implemented in software. Thanks to this standardized interface, the Bluetooth hardware and the Bluetooth stacks usually interoperate very well. The hard-

  • 3

    ware connection is standardized for HCI-UART, HCI- RS232 and HCI-HCI-USB. Others may follow.

    The Logical Link Control and Adaption Protocol (L2CAP) layer multiplexes different data streams, man- ages different logical channels and controls fragmenta- tion. Multiple higher layer modules may access the L2CAP layer in parallel. These higher layer modules may consist e.g. of RFCOMM for emulation of serial connec- tions, OBEX for transmission of serialized data objects or SDP for service discovery.

    IV. MANET OVERVIEW

    This section will give a short overview of MANET routing. For more detailed information see e.g. [3][4][5][6][7]. MANET routing protocols may be di- vided into two categories: proactive and reactive.

    Proactive protocols always try to maintain up to date routing tables for all reachable destinations. All well- known Internet routing protocols like RIP or OSPF fall in this cat