UPTEC IT04011

Examensarbete 20 pMars 2004

LUNAR over Bluetooth

Olof Rensfelt

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress: Box 536 751 21 Uppsala

Telefon:018 – 471 30 03

Telefax: 018 – 471 30 00

Hemsida:http://www.teknat.uu.se/student

Abstract

LUNAR over Bluetooth

Olof Rensfelt

This report describes the porting of the ad hoc protocol LUNAR to theBluetooth wireless technology. Typically ad hoc routing protocols arerun over traditional broadcasting radio technologies such as IEEE802.11b. Bluetooth however is connection orientated which means thatthe same network forming mechanisms used in other wirelesstechnologies can not be used. The report describes the relevant partsof the Bluetooth stack followed by a description of the designdecisions made during the implementation. There are two actualimplementations described in the report. One designed to run on theLinux operating system in userspace, and another implementation wherethe protocol logic is put in a kernel module. Finally the experiencesgathered throughout the work are presented.

ISSN: 1401-5749, UPTEC IT04 011Examinator: Roland BolÄmnesgranskare: Lars-Åke LarzonHandledare: Richard Gold

Contents1 Introduction 3

2 Background 42.1 Ad hoc networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Possible scenarios for ad hoc networks . . . . . . . . . . . . . . . . . . 52.1.2 Existing implementations . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 SelNet & LUNAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1 LUNAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 � LUNAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 kLUNAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 Protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.4 HCI - Host Controller Interface . . . . . . . . . . . . . . . . . . . . . . 162.3.5 L2CAP Logical Link and Adaption Protocol . . . . . . . . . . . . . . . 162.3.6 SDP Service Discovery Protocol . . . . . . . . . . . . . . . . . . . . . . 172.3.7 RFCOMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.8 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.1 Scatternet forming protocols . . . . . . . . . . . . . . . . . . . . . . . . 182.4.2 MANETs and Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Design 203.1 Relevant differences from earlier implementations . . . . . . . . . . . . . . . . . 203.2 Discovering new neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Setup piconets and scatternets . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 Routing in and between Piconets . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Implementation 244.1 BlueZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 User space implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Kernel space implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3.1 Changes to BlueZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.2 Netlogic in the kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Testing & discussion 295.1 The userspace version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 The kernel version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6 Discussion 306.1 Link layer approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1

6.2 Usage of Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.3 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.4 Cross layer information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7 Conclusions 32

8 Future work 338.1 Scatternet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.2 Further Bluetooth adaption of LUNAR . . . . . . . . . . . . . . . . . . . . . . . 338.3 Simulation of LUNAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2

1 IntroductionIn recent years many small devices have been equipped with wireless interfaces. The mostwidespread technology among these is Bluetooth[1, 2]. Bluetooth was created as a cable replace-ment with small devices in mind and most of the major corporations on the market are membersof the consortium that currently develop the specification. This broad support is a reason whyBluetooth is beginning to be widely deployed. Many different types of devices, for instancePDAs, cellphones, laptops, keyboards and other peripherals are using Bluetooth. Another reasonis the price of a Bluetooth unit has dropped below a critical point where it is feasible to includeit in cheap end products. With this new technology spreading it becomes interesting to studyhow it can be used to create networks between devices and how it can work with already existingnetworking techniques. There are many usages for networks between small devices, for instanceit would allow files to be exchanged between devices which would simplify collaboration.

3

2 BackgroundThe goal of this work was to study how the ad hoc protocol LUNAR [18] works with Bluetooth[1]. To understand the problems that were encountered during the work there are two areas thatneed to be explained. The first area is the concept of ad hoc networks and the definitions usedwhen it is discussed. The second area is the Bluetooth technology that is the physical limitationfor this work.

2.1 Ad hoc networksAd hoc network routing protocols are a relatively new form of routing protocols. Ad hoc means“for the purpose”. In network terms it could describe a group of nodes not having any initialknowledge about each other forming a network. These nodes could move within, enter or leavethe network freely. The mobility of the nodes thus create a dynamic network environment whichis typically very differnet from traditional wired networks.

In the basic definition of ad hoc networks no infrastructure such as base stations are in-volved. Because there are no infrastucture participating nodes needs to form the network be-tween peers. The routing functionality is illustrated in figure 1, and this is often referred to asbuilding a multi–hop path.

Because of the dynamic network topology paths might quickly become obsolete so all adhoc routing protocols have some kind of path maintenance or path rebuilding. There are twoapproaches to path maintenance that are used, the proactive approach and the reactive approach.The proactive approach means maintaining paths to peers in case they will be needed. Theproactive approach normally has a relatively big overhead in path maintenance traffic but a pathmight exist at once when needed.

The other approach is the reactive or “on demand” approach. This means that a path dis-covery is triggered when an application is trying to initiate a communication with a remote node.This creates less maintenance traffic and often less complexity in the protocol but introduces aninitial delay to new connections.

A

B C

A

B C

Figure 1: A multi hop scenario, A communicating with C, B forwards data

4

2.1.1 Possible scenarios for ad hoc networks

The first application and usage scenarios for ad hoc networks are military usages. The idea ofcreating a network without any infrastructure would be suitable for a battle zone. Another ofthe early suggestions of usage was disaster areas, where ad hoc networks could be used to allowcommunications between rescue workers.

More recently ad hoc protocols have been suggested for meetings and conference scenarios.For instance a group of persons working together on an assignment can form a network to transferfiles between each other.

One of the more recent scenarios are sensor networks where a lot of small low–poweredsensor devices could be randomly spread over an area and then be made to form a network togather data. Within this context interesting ideas like data harvesters or stronger up–link nodescollecting data add new angles to the design of ad hoc routing protocols.

2.1.2 Existing implementations

There are a are a large number of ad hoc routing protocols implemented. Within the InternetEngineering Task Force (IETF) a working group for ad hoc networks has been formed. This isthe MANET [14] group (Mobile and Ad hoc NETworking) and they have four different protocolproposals considered for standardization. These are :

- The Ad hoc On demand Distance vector routing protocol (AODV)AODV [19] is a reactive protocol which keeps routes up as long as the source node needsit. It also supports multicast groups routing.

- Dynamic Source Routing protocol (DSR)DSR [16] is a completely reactive protocol. Because it is a source routing protocol thesource is allowed to choose the most beneficial route through all intermediate nodes. Alsosince the sender knows all nodes a packet will travel it is by design loop free.

- Optimized Link State Routing Protocol (OLSR)OLSR [15] is a table driven and proactive protocol. It means that it exchanges networktopology information regularly. Some nodes are promoted to multipoint relay (MPR)nodes which are used as communication points which traffic pass through. Being a MPRmeans that nodes around it has chosen it to relay traffic to them. A MPR broadcasts to thenetwork that it can reach the surrounding nodes.

- Topology Broadcast Based on Reverse-Path Forwarding (TBRPF)TBRPF [17] is a proactive, link state routing protocol but unlike OLSR it does not peri-odically exchanges topology data. Instead it exchanges differential data about the networktopology when it changes.

5

2.2 SelNet & LUNARThe ad hoc routing protocol LUNAR that this work is about is an application based on SelNet.SelNet[21] is a network architecture that offers a Virtual link layer. It creates the virtual linklayer by bridging arbitrary network segments together. The segments connected can for instancebe LANs, nodes or wLANs. The bridging of the segments is done with tunnels between nodes.These tunnels can use any link technology available.

SelNet node

Non SelNet node

UDP tunnel

Ethernet linkwLAN

Layer 2.5

Layer 2

Virtual Link Layer

Figure 2: SelNet creating a virtual link layer

The signaling between SelNet nodes to form tunnels is done using XRP (eXtensible Res-olution Protocol) and when a tunnel is set up, selectors are used as identifiers of tunnels. Theprocess of building a tunnel could be seen as an extended ARP (Address Resolution Protocol) re-quest. ARP is used to resolve IP addresses to link layer addresses. ARP only supports resolvingof directly linked neighbors. When using XRP the initiating node broadcasts a XRP (eXtensibleResolution Protocol) request to all its neighbors. The request is rebroadcast by the receiving

6

nodes and if the tunnel is sucesfully created the nodes along the tunnel will then act as ARPproxies.

The actual implementation of SelNet is positioned under IP as a underlay network and inter-cepts the IP traffic. The SelNet daemon traps ARP packets and rewrites them to XRP commandswhich are sent to other SelNet nodes. SelNet is currently worked on to implement a number ofdifferent backends. At the moment Ethernet, wLAN and UDP are implemented backends and aHTTP backend is in the planning stage.

2.2.1 LUNAR

IP data,ARP

IP data,ARP

IP datagrams

WiFi WiFi

XRP, data XRP, data

eth

IP IP

fixedInternet

IP subnet illusion

towardsLUNAR LUNARLUNAR

WiFi

Figure 3: LUNAR overview

LUNAR [22][18] is a SelNet application for wireless networks. LUNAR aims at a scenarioof 10-16 nodes and is implemented in the Linux operating system, Windows 2000/XP operatingsystems and for the Lego Mindstorm RCX. The aim with LUNAR has been to investigate adhoc routing approaches. Whilst many proposed ad hoc protocols constantly added complexity toreact to findings and shortcomings that arose during development, LUNAR was meant to aim atsimplicity.

In amount of C–code and protocol logic LUNAR is a very small routing protocol. TheLUNAR logic is implementable in ~550 lines of C–code and a system with self–configurationlogic had been implemented in less than 2000 lines of C–code. This is ~20–30 % less thanimplementations of other protocols without self–configuration functionality [22]. The simplicityof the logic has been proven a very useful property when ported.

LUNAR is a combined on-demand and pro-active protocol. It is on-demand in the sensethat tunnels only exist when needed. When a tunnel is needed is determined by intercepting ARPrequests. When a tunnel exists it is pro-active in the sense that the tunnel is torn down and rebuiltin a periodic fashion whether the route is still valid or not. This might seem counter intuitive buthas been shown to not affect the performance in a major way[22]. By taking the rather crudeapproach to rebuild possibly well functioning paths, the complexity of the protocol is kept to aminimum.

From experiences from working with other ad hoc protocols a notion of an ad hoc horizonhas been used. This means that there is a limit to how many hops it is useful or possible toperform. In the design of LUNAR this limit has been set to 3 hops.

7

Since LUNAR is a application using the SelNet network architecture it is positioned at“layer 2.5” as seen in figure 3. By positioning LUNAR there it is possible to emulate a LAN bycreating point–to–point multi–hop paths between end nodes. To create multi–hop paths LUNARlinks ad hoc route discovery to ARP and rewrites ARP requests to XRP commands as previouslydescribed when explaining SelNet in 2.2.

As SelNet, LUNAR is positioned under IP and intercepts all IP traffic. When an ARPrequest is intercepted from the IP stack it is rewritten to the XRP command “route request”(RREQ). This command is sent on the wireless interface and hopefully received by all the inrange neighbors. Before sending the RREQ a response selector is created, in order to to receivea potential resolve answer. If a neighbor receives the RREQ and realizes that it is for someoneelse, it will create a response selector and rewrite the RREQ. The RREQ is then rebroadcastedas long as the ad hoc horizon has not been met. When the the resolved node gets the RREQ itwill create a delivery selector and answer with a “route reply” (RREP). If it is a multi–hop pathit will answer to the intermediate nodes response selector. This will cause the intermediate nodeto create a forwarding entry and in turn reply to the originating node. When this is done a tunnelis already set up and ready to forward data. The tunnel is one-way and the return path doesnot necessarily traverse the same nodes as the outgoing traffic. The tunnel setup is illustrated infigure 4.

CB

A

RREQ

CB

A

RREQ

CB

A

RREP

CB

A

RREP

CB

A

Figure 4: The tunnel building operation. Node A is resolving node C. B relays the route request(RREQ) and makes a response selector. Node C replies to B. B replies to A after creating aforwarding entry. When A receives B’s reply the tunnel is created.

The first LUNAR implementation is for the Linux operating system. It resides in userspaceand uses the TUN/TAP functionality in the Kernel. This TUN/TAP kernel module will let auserspace program intercept all packets from the IP stack, rewrite the packets at will and reinsert

8

Component Compiled size (~)Stripped BrickOS 7 Kb� LUNAR 5.5 KbVan Jacobsen Header Compression 4.5 Kb (optional)� IP 3.5 Kb

Table 1: Memory usage in the � LUNAR system

them. This functionality is used to trap the ARP requests and convert them to XRP packets. XRPcommands are sent in ASCII format in the packet and the packet might contain more than onecommand. To implement the rebuilding of tunnels the MAC–address timeout in the ARP cacheis set to 3 seconds. When it times out it will trigger a new tunnel building phase by issuing a newARP–request. Packets that can not be delivered because there is no delivery path set up will notbe buffered. Instead LUNAR relies on upper layer protocols to resend lost packets.

2.2.2 � LUNAR� LUNAR [24]is a modification of LUNAR for embedded systems running on the Lego Mind-storm RCX. The Lego Mindstorm has a h8300 Hitachi micro controller and 32 K bytes of RAM.The communication media is Infra Red at 2400 Baud. The simplicity of LUNAR was essentialto make the protocol fit in such a restraint environment.

As a mac–level protocol, LNP ( Lego Network Protocol ) was used. This is a part of BrickOS(previously knowned as legOS) which is a open source operating system for the Mindstorm. TheIP stack used was � IP [13] which is a stack developed for small devices and with portabilityin mind. To be able to transfer TCP traffic with an usable throughput a header compressionalgorithm was included. This algorithm will reduce the average header length from 40 bytes(fixed header length) to 3 bytes. Without the compression the TCP control traffic congests themedia, so the compression highly increases performance. What actually makes this kind ofcompression possible is the nice property of the SelNet IP subnet illusion. No intermediatenode in a tunnel needs to understand anything of the end nodes communication. It is truly atunnel where anything goes in and if delivered turn up unmodified at the end node. One othertechnique that was used was to adapt the tunnel length depending on what upper layer protocolwas transferred. If the upper layer protocol was HTTP the tunnel length was set to 6 seconds toallow for the relatively big data packets that the web page resulted in, if not a 3 second tunnelwas used.

2.2.3 kLUNAR

The next step in the evolution of LUNAR was an implementation residing in the kernel. Thisimplements the LUNAR logic and network stack connection as a kernel module. To the userkLUNAR simply looks like a network interface and using this interface will give the user accessto the LUNAR network. The benefits of locating the logic in the kernel is both performance andclean design. The modifications made to the original LUNAR were a new packet format as wellas a transition to a binary representation of commands. This is to gain performance as well as

9

not having to do string parsing in the kernel. The kLUNAR implementation also added supportfor two–way tunnels. This allows for creation of the return route whilst resolving the outgoingroute.

kLUNAR has also been ported to the windows 2000/XP environment to allow for cross–platform testing as well as to simplify deployment [26].

10

Power Class Output power (Max) Minimum Output Power Controlat max setting

1 100 mW (20 dBm) 1 mW (0dBm) Mandatory: +4 dBm to 20 dBmOptional: -30 dBm to 4 dBm

2 2.5 mW (4 dBm) 0.25 mW (-6 dBm) Optional: -30 dBm to 4 dBm3 1 mW (0 dBm) - Optional: -30 dBm to 4 dBm

Table 2: Transmission power classes

2.3 BluetoothThe work on the Bluetooth [3] technology started in 1995 when Ericsson research started tostudy wireless cable replacement techniques. This work was not called Bluetooth at the time butwas later named after the nordic king Harald Blåtand(circa 935 - 985) 1.

In 1998 the Bluetooth Special Interest Group (SIG)[2] was formed by Ericsson, Nokia,IBM, Toshiba and Intel and in 1999 the first version of the specification was released (spec 1.0).Bluetooth enabled devices then started to turn up in the consumer market.

Most newly produced cellphones and PDAs comes with Bluetooth or at least have it as anoptional extra. Bluetooth modules are becoming cheap enough to include in very light weight enduser products. When this occurs the number of Bluetooth enabled devices will likely increase in aexplosive manner. Some argue that there are technical shortcomings to the Bluetooth technologybut as of now there is really no concurrent technology that targets the same market.

The most significant technical property of the Bluetooth technology is that it uses SpreadSpectrum technology. This means that it uses frequency hopping2 during communication. Theradio interface allows Bluetooth devices to communicate without line of sight. Line of sight isnot needed because radio waves can travel through materials that light can not. This makes itpossible to have your laptop using the cellphone in your coat pocket to connect to the Internet.Previous connection technologies on small personal devices where cable or IrDA [20](InfraredData Association) but IrDA needs line of sight to be able to transfer data.

2.3.1 Radio

Frequency hopping has been used within wireless communication systems for a long timesince it can provide both robustness and security to a system. Robustness by making it lessvulnerable to interference from other energy sources since it is unlikely that the noise energyis spread over all the frequencies the frequency hopping device uses. Security by making itharder to eavesdrop on the traffic. In the case of Bluetooth, frequency hopping is also a mean to

1Harald Blåtand is famous for uniting the Nordic countries and maybe the name shows a will to unite the majorcorporations involved in personal devices.

2Frequency hopping was invented by the famous Austrian born actress and inventor Hedy Lammar (1911-2000)[3]

11

minimize the risk of collision when several Bluetooth networks are within range of each other.Random collisions are likely to occur in the environment that Bluetooth is designed to workin which is the license free ISM (Industrial,Scientific and Medical) band where many differenttypes of wireless devices operate. This band is global license free with the exception of Francewhere it is free but have larger guard bands which of course leaves less usable frequencies. Thisdifference is will probably soon disappear since France is planning to conform to the rest of theworld in this matter.

The algorithm that calculates the frequency hop patterns is supposed to, with a high prob-ability, choose a distance between two subsequent frequencies, so if a message is lost due tocollision on one frequency it is unlikely that the next frequency will be jammed by the samesource. The Bluetooth technology is a Time Division Multiplexed (TDM) technology. This isbecause all communication is slot oriented. All packets take up 1,3 or 5 slots where a slot is a625 � s.

There are three different classes of Bluetooth radio devices defined in the Bluetooth specifi-cation (table 2). The most widespread devices today are class 3 but class 1 devices have recentlystarted to appear. As seen in table 2 a class one unit has mandatory power control. This isa energy saving function that is of great importance since most Bluetooth devices are batterypowered. The power control operates by having a receiver monitoring RSSI (Received SignalStrength Indication) and sending LMP (Link Managing Protocol) packets to the transmitter. Ifthe RSSI indicates a very strong signal the transmitter can lower its sending effect to save power,and if it is low it can boost the power to get a good communication.

2.3.2 Baseband

LAP , 24 bits UAP , 8 bits NAP , 16 bits

Figure 5: The BD_ADDR with subparts, Lower Address Part (LAP), Upper Address Part (UAP)and Non-significant Address Part (NAP)

Master

Slave

Slave

Slave

Slave

Figure 6: Piconet

Before data transfer can be done, a baseband connection setup phase take place. This con-sists of a inquiry procedure followed by a paging procedure. When paging is done the two devices

12

are connected in a master/slave relationship and data can be transferred. The master/slave rela-tionship means that the slave is following the frequency jumping pattern defined by the mastershardware adress (BD_ADDR). During such a connection the master controls the communicationand the units are said to be in a piconet (figure 6). There are two different types of link levelcommunication, ACL(Asynchronous Connection Less) and SCO(Synchronous Connection Ori-ented). ACL communication can be seen in figure 7 where one also can see how the slots areused.

To be able to conform to the Bluetooth specifications of how to transfer data over the RFinterface there is a need for a link controlling layer. This layer handles the specifications demandsfor power control and as well as the transitions between the different link states that will beexplained later. This layer consists of the Link Manager (LM) and the Link Controller (LC). TheLC is controlling the sending of individual packets on the link while the LM controls the linkitself.

To get input to the link controlling mechanisms every Bluetooth device produced have aunique 48 bit MAC-address called BD_ADDR (figure 5). This consists of three parts that havedifferent functions in the link controller. The NAP (Non-significant Address Part) part of theaddress is used to initiate the encryption, the UAP(Upper Address Part) is used for CRC(CyclicRedundancy Check) and Frequency hopping and LAP(lower Address Part) is used for timingsettings but also frequency hopping.

As soon as a master slave relationship is created a ACL connection exists.When connectedwith a ACL link a slave is only allowed to send if the previous slot was destined to itself. Ifconnected with a SCO link on the other hand, bandwidth is reserved for communication whichgives the slave the right to send in predefined slots.

As previously said the system module that controls the link state is the Link Controller. TheLink Controller can be in 9 different states during operation.

MASTER

SLAVE 1

SLAVE 2

SLAVE 3

Figure 7: Packet transfer within piconet

13

- StandbyThe device is not active, the radio interface is off.

- InquiryThe device is trying to find other Bluetooth devices within range. If a device is discovered itwill answer with Frequency Hop Synchronization (FHS) packets containing the necessaryBD_ADDR and other information to make a connection.

- Inquiry ScanFor a device in the inquiring state to be able to find another device, the remote device needsto be in the Inquiry Scan state. Most devices will set themselves in Inquiry Scan state withregular intervals to be discoverable. The device needs to be in the Inquiry Scan state fora relatively long time period since there is no pre-connection synchronization of clocks orfrequency hopping. The inquiry can take between 1.2 to 60 seconds and a typical inquiryis circa 10 seconds. The inquiring device changes frequencies rapidly while the Inquireddevice changes channels slowly. This scheme is meant to minimize the time until there isa frequency match between two devices.

- PageWhen a device wants to set up a connection it enters the Page state using the informationobtained from the inquiry process. This will let the device become Master in the initiatedconnection. It is possible to initiate a connection without the extra information obtainedfrom the inquiry (using the BD_ADDR) but this is more time consuming since there is noinformation on clock offset or frequencies used. In a worst case scenario such a connectioncan take up to 10 seconds to finalize, however it is extremely unlikely that it will take thatlong.

- Page ScanPage scan is the state that a device enters to be able to handle a incoming connection.As with inquiry scan most device periodically enters this state to allow other devices toconnect to them. When a device in the page state is within range and connects the devicein page scan will send FHS packets and become slave in the created connection.

- Connection ActiveWhen in Connection active the Master sends a POLL packet to check that the connectionwas set up correctly. If the slave answers the connection is up. If something goes wrongboth devices will timeout and can restart the connection process.

- Connection HoldWhen in Connection Hold, a device will not receive ACL traffic. This might be used to doinquiries or to save power.

- Connection SniffConnection Sniff is when a device checks for traffic to it in a predecided period to be ableto be waked up by the master.

14

- Connection ParkIf Connection Parked, device will sporadically listen for traffic, just to keep the clock syncwith the Master.

The second module of the Bluetooth link layer is the link manager. The link manageroperates per connection and uses the ACL header and special LMP packets to create a stablecommunication channel. The functionality that the Link Manager provides is for instance roleswitching, which is when the master becomes slave and vice versa in a connection. It alsoprovides control of multi slot packets. Multi slot packets are more efficient for data transfer butmight not work in combination with SCO communication. This is because SCO means reservingevery n’th slot for SCO packets and multi slot packet might not fit in between.

When the ACL link is established between two devices they are said to be connected in apiconet. A piconet is one master and up to seven slave devices if there is only ACL connections(see figure 6). If SCO links are used a master can only control 3 slaves.

The piconet is defined by the master which decides the frequency jumping pattern. Thispattern is dependent on the masters BD_ADDR, and the masters clock. Because the piconetis defined by properties of the master, a device can only be master in one piconet. However, adevice might be a slave in multiple piconets or master in one and slave in another. When a masteror a slave participate in two piconets as described, and therefor divide its time between the two,the two connected piconets form a scatternet as seen in figure 8.

Master

SlaveSlave

Slave Slave

Slave Slave

SlaveMaster

Figure 8: Scatternet

When the piconet or scatternet is created as described here user data can be exchangedbetween devices. All user data is transferred over L2CAP which will be described in 2.3.5

2.3.3 Protocol stack

All functionality described in the previous chapter are normally implemented in the physicalBluetooth module. To communicate between the software parts of Bluetooth stack to the partsthat are in the module, the HCI (Host Controller Interface) protocol is used. The user might useHCI to initiate or reset the module as well as configure the Link Manager but as soon as data istransferred L2CAP (Logical Link and Adaption Protocol) is used. In the protocol stack are also

15

SDP, Service Discovery Protocol and RFCOMM, but they are not really relevant for this workand will only be shortly explained.

Bluetooth module

HCI L2CAP

SDP RFCOMM

User Applications

Figure 9: The Bluetooth stack

2.3.4 HCI - Host Controller Interface

HCI interfaces between the hardware and the host system on Bluetooth implementations thatdivide the processing power between the host processor and a Bluetooth module. To make thisseparation the HCI protocol serves as a logical division of the stack. As seen in figure 9 the HCIprotocol both interface to the user and the hardware. The interface to the user offers a mean tocommunicate with the baseband controller and the link manager, to read hardware status, as wellas setting and reading control registers. The interface to the hardware provides the functionsmentioned but also transferring L2CAP data to and from the physical Bluetooth module.

The HCI protocol consists of different packet types. First there are HCI command packetsthat are used to control the hardware. Then there are HCI event packets that informs the stack ofevents from the hardware and last there are different data packets that pass L2CAP data to andfrom the hardware.

2.3.5 L2CAP Logical Link and Adaption Protocol

The L2CAP could be considered the transport layer of the Bluetooth system. To allow for mul-tiple services on the same device a PSM (Protocol Service Multiplexer) is associated with everyL2CAP connection. The PSM works like ports do in TCP/IP.

When a upper layer protocol requests a L2CAP link to another device, the L2CAP layerwill initiate a ACL link and then start to negotiate connection settings over the signal channel.When the connection is set up it will be kept alive by the L2CAP. Then the functionality to pingconnected devices as well as to query them for device information, exists apart from the datatransfer.

16

When data is passed to the L2CAP layer to be transferred to the other device the L2CAPlayer will be responsible for fragmentation. This means sending it in smaller packets matchingthe previously negotiated MTU (Maximum Transfer Unit). On the receiving node the otherinstance of L2CAP will reassemble the data before sending it up the stack to the application.

Connectionless data channels can exist but not with Quality of Service (QoS) since the ne-gotiation of parameters involved in QoS could take forever with more than two nodes involved.The broadcast offered by ACL is not used by L2CAP but instead point–to–multipoint commu-nication is set up. In connectionless data transfer the channel ID does not map to a PSM so thePSM is sent with every packet. The point–to–multipoint connection is called a group.

The channel identifiers mapping to PSMs allows for multiple connections to different PSMsbetween the same nodes to traverse the same physical link (ACL link).What makes it possibleto demultiplex the connections are channels. This leaves the L2CAP layer in charge of resourcesharing among multiple connections.

2.3.6 SDP Service Discovery Protocol

When a Bluetooth network is up, and a node wants to access resources or services, for instance,wanting to print a file, the SDP protocol is used. Any Bluetooth node can be a SDP server and/orclient. The SDP service has the predefined PSM 0x0001 so any device know where to initiatethe L2CAP connection if a SDP server should be queried. The SDP server keeps a database ofoffered services on the device for the client to query or browse.

2.3.7 RFCOMM

One common use of Bluetooth is a point to point connection between two devices transferringdata. Historically serial ports have been used for this kind of tasks but in Bluetooth the RFCOMMprotocol is used to emulate a RS232 serial port. It emulates the line settings like Baud rate, paritybits, data bits and flow control. The RFCOMM is for example used in BNEP, Bluetooth NetworkEncapsulation Protocol, as well as in other point-to-point communications.

2.3.8 Profiles

Profiles are specifications of end user functionality to allow for devices from different vendorsto function well together. There exists a fundamental profile that all other profiles depends on,this is the Generic Access Profile (GAP). This profile defines what functionality every Bluetoothdevice must have. This includes definitions of how baseband connections should work, howinquiry are performed and how some security functionality should be used.

One of the most interesting profiles for data transfer between peers is the Personal AreaNetwork (PAN) profile. This regulates how IP traffic should be carried through a Bluetoothnetwork. The PAN profile only depends on the GAP profile and uses the Bluetooth NetworkEncapsulation Protocol (BNEP) to transfer IP traffic between devices.

Personal Area Networks rely on two types of services. These are the Network Access Point(NAP) and Group ad–hoc network (GN) services (figure 10). For clients (PAN users) to find a

17

NAP or GN, SDP is used. The NAP functions as a bridge to a non Bluetooth network and mightoffer Internet connection while the GN might work as a transferring node in a piconet.

Network Access Point

Internet

PAN users

General Ad Hoc Network

PAN users

Figure 10: NAP and GN

2.4 Related workThe work related to this thesis could be divided into two subsections. The first being the proto-cols proposed for creating scatternets. The other subsection is what have been done to use thistechnology for MANETs. There have also been much work done to study the physical propertiesof the Bluetooth Radio interface. Also studies of how Bluetooth interfere with 802.11 networksare interesting since the two technologies are likely to occur in the same places.

2.4.1 Scatternet forming protocols

A lot of work have been done on scatternet forming with Bluetooth devices. The majority ofthe work has been simulations and there do not seems to be many implemented protocols. Oneimplemented is the treenet algorithm from the group behind the BTNodes [5]. Unfortunatelyexperiences from using this protocol is not yet published.

Some people have taken a theoretical approach to the study of scatternets. For instance Law,Mehta and Siu in [8] have used formal methods to prove the correctness of their algorithm whichthey propose, followed by simulations. It seems to be a common standpoint that a proactiveapproach to scatternet construction is the most beneficial with one example of the opposite whichis discussed in the next section.

Many of the proposals use some kind of probability argument by introducing randomnessinto the device discovery and role decision. For instance letting nodes be in different inquirystates random amount of time. Then by simulating sometimes as much as 2000 nodes in ascatternet, they show that the randomness works well in such a big scatternet. Many of theseproposals might not be very suitable for a LUNAR network which aims at 10-16 nodes. Because

18

of the master/slave relationship between nodes it is obvious that tree algorithms come close tomind. Bluetrees [11] is one such protocol.

2.4.2 MANETs and Bluetooth

In [12] Kargl, Ribhegge, Schlott and Weber have tried to make a MANET approach to Bluetoothworking in creating a multi–hop speech transferring system. This would allow for two Bluetoothenabled devices like cellular phones to make a call without using any infrastructure like basestations. They take a reactive approach to baseband connection building, which makes sense inthe scenario with Bluetooth devices forwarding sound where connections could be expected tobe rare and long, but in a data transfer network an initial delay of circa 10 second is probably tomuch.

19

3 DesignDuring the work with the porting of LUNAR to the Bluetooth technology, many design deci-sions have been a compromise between the simplicity and straightforwardness of LUNAR andthe rather complex design of Bluetooth. Also since the Bluetooth specification is still under de-velopment the design work was mainly focused on the available hardware and the functionalityoffered by official Linux Bluetooth stack BlueZ[6]. It is hard to say whether the hardware hasposed limitations to the design since a very practical design process has been used, where thehardware rather than the specification has been used as the definition of Bluetooth.

3.1 Relevant differences from earlier implementationsThe problem of creating a Bluetooth ad hoc network consists of three major subproblems. Thefirst is finding neighbors, what nodes are there within range and which of these are possible toconnect to? How to find neighbors is specified in the Bluetooth specification and is dependenton the inquiry process. The second problem is to set up baseband connections in a somewhatintelligent way. This problem is a research area on its own and for instance [8] is a proposalamong many. The third problem is to route traffic within the created piconet or scatternet. A bigdifference from 802.11 is that there is no real broadcast functionality in Bluetooths link layer butrather a point–to–multipoint one.

Scatternet

Piconet

Piconet

LUNAR network

Figure 11: LUNAR creating a flat network on top of the uneven Bluetooth topology

20

3.2 Discovering new neighborsIn networks using 802.11, the process of finding new neighbors is simply to send a broadcastmessage and wait for replies. Any node within range can answer and knowledge about eachother has been exchanged. With Bluetooth the lengthy inquiry operation described in 2.3.2 isused. It is not certain that all nodes within radio range will be possible to discover. For anode to be discoverable it needs to periodically enter the inquiry scan state and this needs to beconfigured in the Bluetooth hardware. Because of the state machine like operation of the radiointerface, going into inquiry or inquiry scan will interrupt other radio activity. In a multi–hopsituation this could cause a problem if a forwarding node decides to go into inquiry. A normaltime for a inquiry is circa 10 seconds (shortest possible is 1.2 seconds) and that is a very longtime to block a node, especially since it needs to be done frequently. If one take a pro–activeapproach to the creation of piconets there is no real need for a member of the network to find newnodes unless there has been a partitioning of the network. This means that a single disconnectedor newly entered node themselves are responsible for doing an inquiry and thereafter join thenetwork.

3.3 Setup piconets and scatternetsWhen nodes have an idea of who their neighbors are they can either take the pro–active approachor the reactive. In this work a pro–active approach has been used, unlike another MANETproposal[12] where they take a reactive approach to match the needs of a telephone system,where making a call could be looked upon as a route discovery. When a pro–active approach isused there is a need to form and maintain the scatternets.

There are a few scatternet forming protocols proposed but not that many implementationsexist, one example of an implementation is the treenet protocol using the BTNodes. It is not ob-vious what parameters to optimize when creating scatternets. In [8] they claim that good qualitymeasures are number of piconets, how many piconets nodes simultaneously participate in andthe network diameter. In this work the network forming logic is the simple “find neighbors andconnect to them”. This will not create optimal scatternets but it allows for a close to deterministicnetwork forming logic. The deterministic property showed to be very useful during debugging.

When a node is connected it will not do any new inquiries. It is not only to not disturb datatransfer but also because the actual hardware used apparently did not support for a slave to do aninquiry while connected to a piconet.

One problem with only letting unconnected nodes search for new ways to connect is if thereis a partitioning of the network. This would lead to a broken network until a new node entersand connects to both partitions and thereby bridges the subnets again. To act against partitioningof the network a scheme to “reglue” the network was used. This scheme is very simple andlooks promising. A node using the scheme keeps track of when it was last active in sending orreceiving data and how it is connected. If the node is slave in only one piconet and not masterin another piconet it is allowed to perform the reglue operation illustrated in figure 12. When anode’s reglue timer expires and it is only a leaf slave it will send a command into the network.When the command is sent the node will disconnect and perform a inquiry. This command will

21

extend other nodes reglue timers to avoid multiple nodes leaving the network close to each other.If the node find more than one nodes it will connect to them all performing a reglue. If it findsless than 2 nodes it will reconnect to its previous master in order not to build chainlike networktopologies.

Instead of disconnecting the node could maybe stay connected to the master in a non activemode (hold, park, sniff) but since the gain would be marginal it was not implemented in thisscheme.

S6 S6

M1

S3

S7

MS5

S4

M1

S3

S7

S6

MS5

S4Inquiring

M1

S3

S7

S6 Now master

MS5S4

M1

S3

S7

MS5

MS2 S4

1) MS2 Goes down 2) S6 Sends XRP command that extends the other nodes reglue timers

3) S6 Finds two other nodes and therefore performesthe reglue operation

4) The network is reglued

Figure 12: The reglue operation

3.4 Routing in and between PiconetsOne thing not specified in the Bluetooth specification is how traffic should be forwarded betweennodes. In this work forwarding of IP traffic has been the goal and therefore the IP address

22

mapping to the BD_ADDR has been used for routing decisions. It would be interesting to studyhow the SDP (2.3.6) could be used to resolve services in a multi–hop fashion instead of addressesbut that is beyond the scope of this work. The similarity between resolving a BD_ADDR and aMAC–address in 802.11 is obvious and did not pose any difficulty in the design. The rebuildingof tunnels every three seconds was kept for simplicity although another approach was considered.This alternative approach was to make tunnels exist as long as there is a connection all the waybetween end nodes. This could be done because of the connection orientation of Bluetooth andcould be accomplished by letting any intermediate node tear down a tunnel in both directions.By allowing a intermediate node to tear down a tunnel a broken connection mid–path wouldinitiate a new tunnel building from the initial node. But with this version of LUNAR the periodicrebuilding previously described is used.

23

4 ImplementationDuring the course of this work three different implementation approaches where tried. The firstwork with Bluetooth was performed using the BTNodes[5]. These are small embedded unitsconsisting of a atmel avr micro controller, a Bluetooth module and some RAM. The BTNodessystem libraries offer an interrupt driven programming model which made the port from the ex-isting implementation non–trivial. The system libraries for the BTNodes are under developmentwhich caused some problems when they where used to test unstable code against. A while intothe work the BTNodes was exchanged for USB Bluetooth devices.

There are two different implementations of the Bluetooth LUNAR port. The work has beenfocused on the practical implementation with the now existing hardware.

BlueZUtils

Bluetooth Applications

HCIsockets

L2CAPprotocol

SCOsockets

BlueZ Core

Userspace

Kernelspace

Bluetooth Hardware

VHCIdriver

UARTdriver

USBdriver

Otherdrivers

Berkley socket interface

Protocol interface

Driver interface

Host Controller Interface

Figure 13: BlueZ Overview

4.1 BlueZBlueZ is the official Linux kernel Bluetooth stack. There are a number of other implementationsbut after investigating them on a ’looking at the source’ depth BlueZ became the choice for thiswork. This was because the code looked very clean and well structured. Since BlueZ is part ofthe official kernel one might also suspect that it is a pretty stable implementation. At the momentof this work BlueZ supports the use of multiple simultaneous Bluetooth devices and offers aBerkley Sockets interface to all layers of the Bluetooth Stack. It is implemented in a modularfashion and consists of a kernel core module and a number of kernel modules implementing thedifferent parts of the Bluetooth specification. Among these are HCI, L2CAP, BNEP and device

24

drivers for different hardware. Along with the stack implementation BlueZ also provides utilitiesto handle and test connections, and also analysis tools. As seen in figure 13 the BlueZ utilitiesresides in userspace which is relevant for the implementations later described.

4.2 User space implementationThe user space implementation utilizes the forwarding logic from the � LUNAR code as well asthe connection to the IP–stack. The netlogic module is the glue to the Bluetooth interface andis where the Bluetooth specific functionality is implemented. Netlogic is equivalent to the layer2 functionality of the netbox module used in the previous implementations. Netbox is a toolboxto grab ethernet frames from the ethernet device and pass them to an application and also allowmodified ethernet frames to be injected back into the networking stack. The Netlogic could havebeen incorporated with the TUN device functionality in a netbox like way. However this was notdone in order to keep the modification of the existing code to a minimum. The overview of theimplementation design can be seen in figure 14.

Sockets

/dev/tun

User space Kernel space

uLUNAR

Netlogic BlueZ

Bluetooth hardware

IP stack

Figure 14: The design of the user space implementation

The netlogic module has three functions. The first is to form the baseband connections. Thismeans to initiate inquiries and connect to the in–range neighbors found, as well as performing thereglue operation. The second task is to allow the LUNAR logic to perform a simulated broadcastto neighbors. This could be performed with a point–to–multipoint connection but is implementedas a sequential sending of the same data to all the neighbors. The third and last task is to offer asend data to neighbor functionality. Since � LUNAR code only handles a 4 bit hardware addressthe netlogic module keeps a mapping between the selector and what connection handle (socket)to use to reach this node. The mapping is done by making the netlogic module aware of � LUNARand snoop the RREQs and RREPs coming and going to the � LUNAR module (underlaying theunderlay). It does not rewrite any packet data but by snooping it can keep a picture of whattunnels exist.

The actual Bluetooth modules used where D–Link 120 USB dongles. With the functionality

25

of BlueZ to handle multiple devices and a USB hub it was possible to let one physical machine bemany nodes in the LUNAR cloud. As stated in 4.1 the BlueZ utilities being implemented as userspace programs showed to be very nice since a lot of the code from the utilities could be reused.The initiation code for this implementation takes as a command line parameter which HCI deviceto use, as well as how the netlogic should behave. By making the netlogic configurable at runtimeit is easy to have control of how the scatternet and piconets where formed. This showed to bevery valuable during development and testing.

26

4.3 Kernel space implementationAs the user space version proved successful the next step was to see if the network forming logicand the forwarding logic could be placed within the device driver for the Bluetooth device. Thiswould allow for a transparent network illusion to the user where getting access to the LUNARcloud would be as easy as initiating a virtual network device. The code from kLUNAR gavethe interface to the virtual device as well as forwarding logic. What needed to be added was thenetlogic module and the interface to the Bluetooth hardware.

Having the kernel listening to incoming connections might not be considered good kernelcoding practice. However this is not the first application that uses the possibility. The KernelHTTP daemon (kHTTPd) [25] uses the socket interface on TCP/IP sockets from within the ker-nel. The kHTTPd is even a part of the 2.4.x official kernel tree which give the approach somekind of legitimacy.

HCIsockets

L2CAPprotocol

SCOsockets

BlueZ Core

Kernelspace

Bluetooth Hardware

VHCIdriver

UARTdriver

USBdriver

Otherdrivers

Driver interface

Host Controller Interface

Netlogic

kLUNARkSAPF

eth1

netbox

Compiles into one kernel module

Figure 15: the kernel version

27

4.3.1 Changes to BlueZ

Since the functions BlueZ offers expect to be called from user space they check the pointersto return memory for validity. This makes it impossible to call these functions from within thekernel and therefor the functions needs to be duplicated. This makes it necessary to modifyBlueZ even though it would be preferred to be able to use the unmodified version. Problems doalso occur when the modifications to the BlueZ stack causes circular dependencies among thekernel modules. This was solved by simply compile the relevant parts of the stack into one bigmodule (figure 15).

4.3.2 Netlogic in the kernel

The approach taken to allow for the netlogic to operate in the Kernel is similar to the one ofkhttpd. The socket interface is called from within the kernel and sockets are handled by thekernel module. At first a timer approach was used. This meaning that the module periodicallychecked if something had happened on the sockets. This introduced a unnecessary large jitterand should therefor be rewritten to use a kernel thread to simulate the select() functionality.

The kernel module is loaded on insertion of the Bluetooth USB dongle. When loaded themodule creates a virtual network interface (in figure 15 it is /dev/eth1) and then enters a waitingmode. When the user issues the “ifconfig eth1 up” command the netlogic starts to operate.

When started netlogic opens a listening socket on the predefined LUNAR PSM. If the listen-ing initiates without problem an inquiry is started to find reachable neighbors. If neighbors arefound the netlogic creates sockets and try to connect them to the found neighbors. When this isdone the initiation phase of the netlogic is finished and the system goes into ordinary operation.

When running the netlogic periodically checks the listening socket for connection attemptsand accepts them on arrival. When accepted a pointer to the socket is kept in conjunction withthe BD_ADDR of the corresponding neighbor.

The goal of the initiation and periodical tasks are to keep connections to as many neighborsas possible at all times. This to be able to forward route requests with a minimum of delay.

28

5 Testing & discussionThe testing of the LUNAR for Bluetooth system has mainly been function testing. When theinitial version was functioning the work effort was moved to the kernel version trying to use someof the knowledge gathered from porting userspace � LUNAR to Bluetooth. Unfortunately thekernel version is not fully functioning. However it looks very promising to get it fully functioningfrom the tests performed.

5.1 The userspace versionThe userspace version is proved to be functioning. It finds neighbors, connects to them and routestraffic in the created scatternets.

To perform the tests with different network topologies a number of � LUNAR enabled Blue-tooth devices was used. The netlogic was then initiated using runtime argument that controlledits behavior. The netlogic accepts two commands. First it can be run in silent mode. This meansthat it does not try to find neighbors but it will accept incoming connections. The second optionis to only allow it to connect to a certain number of neighbors. By using these two options it iseasy to control how scatternets are formed. The measurements performed were using ping pack-ets through the created networks. This does not take into account the asymmetric performanceof ACL links but can give an overall idea of the performance that can be expected.

RTTs(Round Trip Time) for a few link topologies are presented in table 3. The big differ-ence between the mean and the max RTTs can probably be explained by the fact that some pingpackets is delayed because of the tunnel rebuilding phase. It can also be seen from the table that atwo hop path within a piconet has much higher capacity than a two hop path through a scatternet.

5.2 The kernel versionThe kernel version code is not fully functional. At the moment it initiates correctly meaning thatit inserts into the kernel as module when the Bluetooth device is inserted. The ksapf module isinitiated and the code then waits for activation. When the virtual Ethernet device is configuredby the user the OS sends an “ifup” event to an event handler. When this event is received thenetlogic is started and on “ifdown” it is stopped. When the netlogic initiates it opens the listeningsocket and then enters the inquiry state. When neighbors are found they are added correctly tothe neighbor list. If another Bluetooth node initiates a L2CAP connection to the open listeningsocket the netlogic accepts and correctly creates a new socket. The netlogic periodically checksthe newly created socket for incoming data but when data arrives there is a problem with lockingthe socket so that when the read is performed the kernel locks up. There is no fundamentaldifference between this netlogic module implemented like a kernel thread and the khttpd.

29

Topology min avg max mdev

M SDST

SRC

30.159 76.263 231.254 45.699

M SSSRC

DSTM 80.086 248.449 650.157 110.265

M SSSRC

DSTM

SM 100.151 330.594 1173.374 198.467

M SDST

SRC

S 109.812 175.546 868.290 100.818

Table 3: RTT in ms measured with 100 ping messages through a LUNAR network

6 DiscussionThe conclusions and experiences gathered from this work are mostly of negative nature. UsingBluetooth for MANETs is not a straightforward task.

6.1 Link layer approachAs described before the lengthy inquiry process makes it hard to create a Bluetooth networkthat adopts quickly to topology changes. In order to make a Bluetooth network usable at all aproactive approach to scatternet forming is needed. If a protocol that keeps the scatternet up isnot suitable, at least knowledge about neighbors should be kept at all times. Using Bluetoothfor sensor networks might be a good idea because of the price and availability but yet again, ifthe network is very dynamic it will probably be very hard to create scatternets. A problem withhaving to use the proactive approach is that Bluetooth devices often is battery powered. Evenwith Bluetooth’s extensive power control it will cost energy to keep the network up at all times.

6.2 Usage of BluetoothThe use of Bluetooth in an office environment where certain nodes have permanent power ismore likely to be successful than the completely Ad Hoc scenario. This is not very strange sinceBluetooth initially was developed as a cable replacement technology. As a cable replacementBluetooth works very well and will probably prosper in the years to come. The PAN profile isvery usable but it is unlikely that there is a need for a scatternet (more than 8 nodes) on oneperson so the well functioning piconet should be enough.

6.3 RoutingThere is still a need to route traffic within the piconet and this functionality is developed usingthe BNEP and the GN. It seems that the GN uses BNEP over every link. This means that if a IPpacket is bigger than the ACL link MTU, it will be fragmented by L2CAP. When it is received bythe next node the IP packet needs to be defragmented completely before it can be routed further

30

along the path. Using SelNet could improve this since there is no need to study the IP header inorder to route a fragment of the packet once the tunnel is up. Thus allowing for a packet streamon the link layer without the need for defragmentation on the intermediate nodes. If BNEP isused with IP routing every intermediate node needs to defragment the packet before making arouting decision which would cause a non optimal use of the link.

6.4 Cross layer informationOverall the notion of layering with the Bluetooth stack is somewhat problematic. It is unlikelythat a MANET for Bluetooth could be successful without extended knowledge of the link layerspecialties that Bluetooth offers. One argument for cross layer optimizations is that the optimallink layer connection in Bluetooth is dependent on the IP traffic that comes. Using a strictlayered approach means loosing the ability to create link formations that take more than one hopinto consideration[9]. If IP routing is used the routing tables could be made much more accuratewith the help of link layer information.

31

7 ConclusionsIn this report the work to port the ad hoc routing protocol LUNAR to Bluetooth has been de-scribed. The relevant parts of the Bluetooth stack and the definitions used when discussing adhoc networks has been presented followed by a description of the design decisions made whenthe system was created.

The actual porting process resulted in two different implementations. The first was theLinux user space version using the official Linux Bluetooth stack BlueZ and the second one is theLinux kernel version where the protocol was compiled into the Bluetooth stack. The userspaceversion has been tested and is functioning while the kernel version is not finished.

The overall experience gathered from this work is that traditional ad hoc networks do not fitthe connection oriented Bluetooth technology well. It is not likely that an ad hoc routing protocolwithout layer 2 knowledge will perform well over Bluetooth.

32

8 Future workThe next step in the development of LUNAR for Bluetooth is making the kernel implementationfully functional. Apart from that the next interesting topics are as follows.

8.1 ScatternetBecause LUNAR for Bluetooth was designed to allow for a change of scatternet building logicit would be interesting to evaluate one or more of the proposed protocols. It seems like the arealacks working implementations and studies from real life scenarios and more work is thus neededhere.

8.2 Further Bluetooth adaption of LUNARThere are two different modification to LUNAR that could be interesting to study. First is thepossibility of very long lived tunnels. To not risk having broken tunnels alive for a long timeevery intermediate node would need to be able to tear the tunnel down. To do this it is needed toadd a tear down identifier to the RREQ packet as well as one to the RREP. The identifier couldpoint to the needed information of what tunnels to remove. Then when a node looses connectionto a neighbor it can tear down the tunnel by signaling the relevant neighbors.

It could also be interesting to study how the power class 1 units could be used to do connectbetween different local LUNAR networks.

8.3 Simulation of LUNARIt is very hard to set up physical tests with the number of nodes needed to stress the design of aBluetooth scatternet forming protocol. Therefor simulations are often used. It seems like no onehave tried how the un–intelligent network forming protocol of just connecting actually works. Itmight be that it is good enough for small scatternets. The simulations done are mostly done withthe tool bluehoc [4] which is an extension to the network simulator NS-2.

33

References[1] Bluetooth homepage: http://www.bluetooth.com

[2] Bluetooth SIG homepage: http://www.bluetooth.org

[3] J. Bray and C. F. Sturman Bluetooth 1.1: Connect Without Cables (2nd Edition)

[4] BlueHoc: Bluetooth performance evaluation tool Bluetooth 1.1: Connect Without Cables (2ndEdition) http://www-124.ibm.com/developerworks/opensource/bluehoc/

[5] BTnodes, A Distributed Environment for Prototyping ad hoc Networks http://www.btnode.ethz.ch/

[6] The “BlueZ” Linux Bluetooth Stack http://bluez.sf.net/

[7] Law, C. and Mehta, A.K. and Siu, K.Y. “Performance of a New Bluetooth Scatternet FormationProtocol" http://citeseer.nj.nec.com/472978.html

[8] Ching Law and Amar K. Mehta and Kai-Yeung Siu. “A New Bluetooth Scatternet FormationProtocol" http://citeseer.nj.nec.com/law02new.html

[9] Bhaskaran Raman and Pravin Bhagwat and Srinivasan Seshan “Arguments for Cross-Layer Opti-mizations in Bluetooth Scatternets" http://citeseer.nj.nec.com/381045.html

[10] Godfrey Tan and John Guttag. “A Locally Coordinated Scatternet Scheduling Algorithm” "The27th Annual IEEE Conference on Local Computer Networks (LCN),2002” http://citeseer.nj.nec.com/tan02locally.html

[11] G. V. Zaruba, S. Basagni, and I. Chlamtac, “Bluetrees– Scatternet Formation to Enable Bluetooth-Based Ad Hoc Networks” "Proc. IEEE International Conference on Communications, ICC 2001"http://citeseer.nj.nec.com/tan02locally.html

[12] Frank Kargl, Stefan Ribhegge, Stefan Schlott, Michael Weber “Bluetooth-based Ad-Hoc Net-works for Voice Transmission” "36th Annual Hawaii International Conference on System Sciences(HICSS’03)"

[13] Adam Dunkels. “uIP - A Free Small TCP/IP Implementation for 8- and 16-bit Controllers” http://www.dunkels.com/adam/uip/

[14] IETF MANET Working Group. MANET Charter, 2000. http://www.ietf.org/html.charters/manet-charter.html.

[15] RFC 3626: Optimized link state routing protocol.

[16] David B. Johnson, David A. Maltz, Yih-Chun Hu, and Jorjeta G. Jetcheva. “The dynamicsource routing protocol for mobile ad hoc networks”, 2000. http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-04.txt.

[17] RFC 3684

34

[18] LUNAR home pages: http://cn.cs.unibas.ch/projects/lunar/and http://www.docs.uu.se/selnet/lunar/.

[19] Charles Perkins and Elizabeth M. Royer. RFC 3561: ad hoc on–demand distance vector (AODV)routing,

[20] IrDA organisation http://www.irda.org/

[21] Christian Tschudin and Richard Gold. “Network Pointers”. First Workshop on Hot Topics in Net-works (HotNets-I), 28th-29th October 2002

[22] Christian Tschudin and Richard Gold. “Lightweight Underlay Network Ad-Hoc Routing” imple-mentation. Uppsala University Technical Report 2003-021.

[23] Christian Tschudin and Richard Gold. “Lightweight Underlay Network Ad-Hoc Routing” imple-mentation. Uppsala University Technical Report 2003-021.

[24] Olof Rensfelt and David Rosén http://www.docs.uu.se/docs/research/projects/selnet/lunar/ulunar/

[25] kHTTPd “kHTTPd- Linux HTTP Accelerator” http://www.fenrus.demon.nl/

[26] Oskar Wibling. “Porting LUNAR to Windows”. Communications Research Group, TechnicalReport. Uppsala University, 2003.

35