Using TCP/IP applications between two peers over BlueTooth usually require many manual steps from the user. Our Connection Diversity framework offers mechanisms to automate all these steps. The implementations of Connection Diversity over BlueTooth enables TCP/IP applications to transparently use BlueTooth and smoothly handoff to other link layers. We explain how Connection Diversity interface with BlueTooth and various aspects of the implementation, including the management of connections, discovery, Co-Link and name resolution. We then suggest a few modification of BlueTooth to improve its suitability for peer to peer applications. We also discuss how to optimise BlueTooth handoffs. This implementation allowed us to test various peer to peer usages models, we report their user friendliness, their performance characteristics and how the design of BlueTooth impacts user experience.
The BlueTooth wireless technology started as a humble cable replacement [1], but has quickly evolved into the Swiss Army Knife of wireless technologies, allowing all kinds of appliances to be wirelessly connected together.
The vast majority of network applications are written for TCP/IP. Using those TCP/IP applications between two BlueTooth peers requires various manual steps : the user need to explicitly establish the link prior to starting the application, and close it afterwards. If the link breaks, the user need to select another link and restart the application.
It is our belief that users should focus on the task they want done, not on managing various link layers. Our Connection Diversity framework implements various techniques to make the link layer transparent to the user, and offers the potential to make the usage of peer to peer TCP/IP applications over BlueTooth much more user friendly.
Connection Diversity explores how mobile devices can interact using
the wide variety of wireless technologies existing today, with a
special emphasis on peer-to-peer and ease of use [11].
2.1 Usage model and assumptions
Connection Diversity offers a simple usage model for peer to peer applications, where a user, through his mobile device, interacts locally with other physically nearby users or appliances in the environment (peer to peer). Links layers are automatically managed and invisible to the user.
A principal underlying assumption of Connection Diversity is wireless diversity : the availability of multiple wireless technologies with different characteristics in each information device. All applications are TCP/IP based to achieve link layer independence, and we want to enable all existing popular applications without modifying them.
The Connection Diversity framework is composed of various components inserted in a standard operating system. It currently fully supports IrDA, BlueTooth and 802.11.
The Connection Manager (Fig. 2.2) is the central controller, a daemon managing the various wireless interfaces of the system and mapping application connections to those [14]. The Connection Manager monitors both peer discovery and outgoing connection requests to implement On-Demand TCP, P-Handoff and Co-Link.
On-demand TCP enables peer to peer TCP/IP on a wide variety of wireless links [11]. TCP/IP connections are automatically established and configured over the wireless link when applications need them, between two peer devices, without the need for infrastructure, and then closed down.
P-Handoff enables transparent migration of peer to peer TCP connections between wireless links [12]. P-Handoff doesn't require any infrastructure and is fine grained, allowing flexible use of available links. A Policy Manager tries to optimally use those links for each connection based on range, speed and cost.
Co-Link enables the use of any wireless link to activate and configure another wireless link [13]. This allows a device to use the most power efficient links for discovery and enable higher performance links only on-demand.
Different wireless technologies present different APIs, different
operating characteristics and topologies [12]. The core and methods of Connection
Diversity are generic but require a Link Adaptation Layer (LAL)
for each wireless technology we want to manage [11]. We enumerate those requirements here.
2.3.1 Discovery Management
The Connection Manager depends on the knowledge of which peers can be reached via each link layer, so it can decide what potential connections can be routed on each link layer.
The LAL needs to provide peer discovery. Wireless Discovery is
not trivial [13], however most link layers
offer built-in facilities for discovery, and we want to reuse those
for efficiency [11]. The LAL needs to know
within a reasonable time when a new peer is discovered. It also
manages peer expiry : it must keep track of discovered
peers and remove them from the discovery log when they are no longer
reachable (again, within reasonable time).
2.3.2 Peer IP Identity
Most often, the link layer discovery only reveals the link layer identity of peers discovered (MAC address). However, both the Connection Manager and the Ad-Hoc resolver need the IP identity of those peers, consisting of a Globally Unique IP address and a DNS name [11]. Therefore the LAL needs to convert peer link identities to peer IP identities.
Applications are TCP/IP based, so the LAL needs to transport IP
traffic over the link layer. This requires the proper encapsulation of
IP packets in link layer packets, and the proper setup of IP
configuration and routes.
2.3.4 Connection Management
Many link layers are connection oriented and don't offer automatic connection management, leaving it up to the user to connect devices together. The Connection Diversity framework automates this connection management [11].
To enable TCP/IP traffic, the LAL needs to be able to create link connections to the desired peers, and to close those, based on its routing decisions. It also needs to detect and close idle link connections.
Most wireless links are unreliable, so the LAL must monitor those connections for link failures. It needs to know when the link detects likely failure conditions (blocked link), and also when the link layer destroys the link connection because of this failure condition. We usually prefer to have those two events separate [12], because it's more efficient to monitor the likely failure condition while the link is still connected (even with errors) and because disconnecting and reconnecting the link layer incur a large overhead.
The name resolver translates both the DNS names and link local names of peers into their Global IP address [11], without using a global infrastructure. A resolver module is needed for each link layer, with corresponding link local names.
Co-Link uses HTTP requests and is mostly link layer independent [13]. Co-Link needs to query and represent a link layer configuration, and must be able to activate the link layer and apply efficiently such configuration.
To better understand the integration of BlueTooth into the Connection Diversity framework, we did a complete implementation of its Link Adaptation Layer. We also implemented additional features in the BlueTooth Adaptation Layer to enable additional usage models (Section 6).
BlueTooth is quite different from link layers already supported, so this implementation helps validating the original design of the Connection Diversity framework.
BlueTooth is a wireless communication standard initiated in 1997 by Ericsson and Intel [1] and now managed by the BlueTooth SIG (Special Interest Group) [2]. BlueTooth was influenced by the IrDA [5] and USB [7], and offers the functionality of a wireless USB and serial cable replacement.
Like IrDA, and as opposed to 802.11, the BlueTooth link layer is
connection oriented, so two BlueTooth devices explicitly need to
connect to each other before being able to exchange any data [2].
3.2 Discovery Management
BlueTooth offers a link layer discovery process called Inquiry. The Inquiry procedure returns the list of BdAddr (BlueTooth MAC addresses) of devices that can be reached.
Most devices periodically check if they need to answer Inquiries (Inquiry Scan mode - every 1.28s for 11ms). A device performs an Inquiry by repetitively sending requests and collecting answers from its neighbours (Fig. 3.2).
The default Inquiry duration is 12s. Due to the design of Inquiry Scan mode (delayed answer [2]), the minimum time to get any answer from Inquiry is 4s, and the probability to get an answer from a peer within 4s is often below 50%.
We have implemented a discovery manager that can use Inquiry to build a discovery log (Fig. 3.5). It performs a periodic Inquiry for 4s every 60s (Table 1). This aims to tradeoff the latency of discovery, the length of time the interface is unusable (while doing Inquiry) and the Inquiry overhead (both in throughput loss and power - Section 4.1).
Once a peer is discovered, we need to keep track of it and manage its expiry. This is done through the periodic Inquiry ; if a peer is not discovered for 10 successive Inquiries, it is expired and removed from the discovery log (Table 1).
Inquiry in the discovery manager can be turned off, and can also be triggered on-demand by the name resolver. The additional "auto" mode allows tracking of discovered peers : Inquiry is off by default and enabled only when there is a valid peer in the discovery log.
The discovery manager can also perform passive discovery, i.e., to discover peers without doing any Inquiry. Peers performing Inquiry don't reveal anything about their identity. However, whenever a peer connects to us, we can be notified of it and get its BdAddr. The discovery manager monitors this event and adds the BdAddr of every incoming connection in the discovery log (if it doesn't already exist).
The discovery manager also monitors Inquiries triggered by other applications on the device and collects their results.
| Parameter | standard | new value |
|---|---|---|
| Periodic Inquiry period | - | ˜60 s |
| Periodic Inquiry duration | - | 3.84 s |
| Discovery log expiry | - | 10 min |
| On-demand Inquiry duration | 12.8 s | 6.4 s |
| SDP retries | - | 3 |
| Page timeout | 5.12 s | 4 s |
| Page Scan period | 1.28 s | 0.64 s |
| Link Supervision Timeout | 20 s | 5 s |
| Connection idle timeout | - | 10 s |
| Transmit Watchdog timeout | - | 500 ms |
Inquiry and passive discovery only return the BdAddr of peers and their class of device bit-field, and do not contain any other data that could be used to identify the peer. Therefore, the discovery manager needs to query individually each BdAddr found for its peer IP identity (Section 2.3.2).
This is done using SDP (Service Discovery Protocol). SDP associates metadata to each BlueTooth socket, enabling discovery of their functionality and attributes [2]. The SDP server on each device maintains a list of SDP service records, and any peer can query those records with a simple protocol.
We simply added an additional SDP attribute to the SDP record of the BNEP socket (Section 3.4). This attribute contains the IP identity of the device (Section 2.3.2).
Each time the discovery manager finds a new BdAddr, it creates a BlueTooth connection to this peer and fetches the SDP attribute containing the IP identity (Fig. 3.2).
The BlueTooth connection is based on a Paging handshake, and requires the BdAddr of the peer. After Paging completes, the higher level of BlueTooth stack can connect (SDP in our case). The time to perform the SDP request itself is usually small with respect to Page time (Table 2).
Paging is similar to Inquiry and synchronises the two BlueTooth devices on the same Frequency Hopping pattern [2]. The target device periodically checks if it needs to answer Pages (Page Scan mode - for 11ms every 1.28s). The initiator sends Page requests until it gets an answer or timeout.
To minimise connection latency, we reduced the Page timeout from 5s to 4s and the Page Scan period from 1.28s to 0.6s (Table 1). The peer itself may be doing an Inquiry and unable to answer us, so we will retry the SDP query up to 3 times (once after each successful Inquiry or passive discovery) before marking the discovery log entry invalid.
Performing a SDP query on each peer is time consuming (Fig. 3.2), therefore to improve scalability
the peer identity is cached in the discovery log. Since not all peers
answer SDP requests, especially those that don't support Connection
Diversity, we pre-filter peers based on their class of device.
3.4 IP adaptation
We decided to use a simple subset of PAN to do IP adaptation. PAN (Personal Area Network) [3] is one of the standardised networking profiles of BlueTooth, designed specifically for creating ad-hoc networks of devices or connecting to dedicated access points.
The subset of PAN we use is BNEP (BlueTooth Network Encapsulation Protocol), which is a direct encapsulation of Ethernet frames over a BlueTooth L2CAP socket (Fig. 3.5).
The IP address configured at each end of the link is the node Global
IP address [11], so there is no need for
dynamic IP configuration. The BlueTooth Manager also sets up a host IP
route and a ARP table entry for each BNEP connection, so that packets
are properly routed.
3.5 Connection Management
When the Connection Manager requests a link connection, the BlueTooth manager creates and configures it. It first connects to the peer using Paging (Section 3.3), then creates a BNEP connection using the standard BNEP API, finally configuring IP and the route. The BlueTooth Manager maps the peer connections to the various BlueTooth interfaces available and attempts to find the best BlueTooth interface for each one. It enforces the 7 slaves and 1 master limitation [2], and has basic master/slave switch support [2].
There is no facility in BlueTooth to detect idle links, so we use Netfilter and optional KeepAlive packets to monitor IP traffic. Netfilter [10] is the standard packet monitoring facility of the Linux kernel and allows the BlueTooth Manager to count incoming and outgoing packets on the BNEP connection. After 10s without seeing any activity between two peers, the BlueTooth Manager closes the associated connection and puts the peer back in demand mode (Table 1).
To detect final loss of connectivity, we use the underlying BlueTooth facility : the Link Supervision Timeout dictates the time a BlueTooth link remains alive without an answer from the peer [2]. We set it to 5s (the smallest value larger than an Inquiry, to avoid false positives). When the Link Supervision Timeout expires, the BNEP channel is automatically destroyed, the Connection Manager gets notified of it and usually triggers P-Handoff [12].
We also implemented the blocked link event (Section 5).
3.6 Ad-Hoc Name Resolver
The BlueTooth name resolver module interfaces to both the Connection Manager and the discovery manager (Fig. 3.5).
If periodic Inquiry is active, the Connection Manager already knows about all BlueTooth peers, and the name resolver only needs to query the Connection Manager cache.
If periodic Inquiry is not active, the cache is empty. In the case of DNS names, the name resolver will return "not found" to avoid impacting the performance of regular DNS queries. The resolver still tries to resolve BlueTooth link local names, because those can be resolved only on the BlueTooth link.
The first form of link local name is composed with the name of the peer and the .bt suffix, such as name.bt . After the cache lookup, the resolver can trigger an complete Inquiry (via the discovery manager - including associated SDP requests) and wait for the result.
The second form of link local name is composed with the BdAddr of the peer and the .bdaddr suffix. After the cache lookup, the resolver can trigger a SDP request on this BdAddr (via the discovery manager).
The Co-Link configuration [13] data for BlueTooth only contains the BdAddr (BlueTooth MAC address) of the peer. We can not add BlueTooth clock offset, because it is relative to the adapter local clock. The XML fragment looks like :
<BT BdAddr="BD:AD:D8:01:23:45"/>
When Co-Link activation of BlueTooth is requested, the BlueTooth manager switches on the best BlueTooth interface, extracts the BdAddr from the XML, and passes it to the discovery manager. The discovery manager then directly issues an SDP request on this BdAddr to verify its reachability and get its IP identity. Once the identity is known, the Connection Manager can reroute traffic to this peer.
Our implementation uncovered some issues with the current BlueTooth implementation and specification that would likely apply to other peer to peer applications (Section 6). We also present a few simple techniques that would make BlueTooth more friendly for such peer to peer applications.
The BlueTooth specification was designed to be mostly master-slave [2], and by using it in peer to peer mode, we
seems to be pushing some of its limits. The peer to peer usage model
increases concurrency, two nodes are more likely to do incompatible
activities at the same time.
4.1 Issues with Inquiry
The single most problematic aspect of BlueTooth is the slow, exclusive and expensive Inquiry procedure.
While performing an Inquiry the BlueTooth interface of a node can't be used for anything else for its whole duration (such as servicing existing connections or accepting new incoming connections). If a peer tries to connect to it (Paging), it will fail. If two nodes perform Inquiry at the same time, they won't discover each other. We see those failures fairly often in the discovery process (periodic Inquiry + SDP).
When using periodic Inquiry, it usually takes minutes to discover new peers and expire them (Table 2). The Inquiry consumes significantly more power than other BlueTooth modes. Another issue is that, once connected, the node that is the slave usually loses its ability to perform Inquiry, so can't keep track of its reachable peers until it disconnects.
The cause of this is both the nature of Frequency Hopping, which requires peer synchronisation, and design choices. In BlueTooth, the node can synchronise to a peer only when this peer goes in Inquiry Scan mode, and to preserve throughput this happen infrequently. The node doing Inquiry also has to transmit in every possible transmission slot [2].
Beyond our current setting of periodic Inquiry (Table 1), there is not much that can be done to fix Inquiry, because it is a core feature of the BlueTooth specification (Section 3.2). The only workaround is to use Co-Link to bypass entirely the Inquiry process (Section 6.4).
If a node tries to connect (Paging) to a node that does Inquiry, it will fail (Section 4.1). Similarly, if two nodes Page each other at the same time, they both will fail. Therefore, we had to make the Co-Link process over BlueTooth explicitly asymmetric : only the initiator attempts to do a SDP query.
We also had stability problems with the hardware (lockups). When doing
passive discovery, we have to wait until the incoming connection is
accepted before performing Paging. With Co-Link, we also needed a 20ms
delay between the activation of the BlueTooth interface and Paging.
4.3 Power saving modes
Many proposals in the PAN working groups make use of BlueTooth power saving modes (Park mode) to improve scalability or enable scatternets.
The Connection Manager only establishes link connection as needed and close them down when unused, so it doesn't need scatternet support and it is already saving power. One scenario is to use Park mode to improve the discovery process, by keeping track of discovered peers : the node would automatically connect to all discovered peers, put them in Park mode, and periodically poll them.
Using park mode forces the use of a networking model and introduces a significant complexity : we would have to manage a mesh of peer-to-peer connections. Between each pair of nodes, one must be master and the other slave. Some nodes may be parked by multiple masters, and some nodes might be both master and slave (with respect to different peers). The master also will need to periodically unpark each slave to verify if it is still reachable.
The performance of Park mode is not much better than our current solution (using Paging). To wake up a peer, the device has to wait for the park beacon [2], and this is roughly in the same order of time as the Page Scan period.
Finally, park mode does not allow us to eliminate the need for
periodic Inquiry. Only Inquiry allows to discover new nodes
coming into range. As we still need periodic Inquiry to happen, the
advantage of using Park mode is marginal, and we believe that the
complexity and management overhead of such setup is not justified for
our usage model (Section 2.1).
4.4 QoS implementation (Link monitoring)
The QoS latency variation constraint can be helpful for triggering handoffs (Section 5.3). Unfortunately, current BlueTooth implementations don't support this feature.
The Connection Manager needs a way to keep track of peers it has discovered, and to expire them (Section 2.3.1).
Currently, this is implemented via the periodic Inquiry. We don't want to use any of the Power Saving mode due to the complexity and lack of benefits (Section 4.3).
Another solution is to use Paging probes [15]. Every BlueTooth node has a known Paging Scan behavior (typically a 11ms window every 1.28s). Once the initial discovery of a peer is done, the node could remember its peer's Paging Scan parameters. Then, it only needs to send a Page at the time it knows the peer is doing Page Scan to verify that the peer is still reachable (and timeout or disconnect immediately).
If the number of peers is relatively limited, this technique would be
much more efficient than periodic Inquiry or Park mode. Unfortunately,
due to the timing accuracy needed, this can only be implemented in the
BlueTooth hardware module.
5 The Blocked Link Event (handoff)
The blocked link event is used to detect failing link (Section 2.3.4), and is therefore the main performance factor for handoff [12]. We describe various ways to implement this event and their limitations.
The Link Supervision Timeout [2] is the standard way to detect link failures : it specifies the length of time before the BlueTooth hardware close inactive connections. It can be set to very short values (minimum 0.625 ms).
However, a shorter timeout increases the probability of spurious disconnections, for example if there is a temporary interferer or if the peers goes momentarily out of range. To maximise usage of the BlueTooth link, it is necessary to efficiently detect these disconnections and recover from them.
When the Link Supervision Timeout expires, the corresponding BlueTooth connection is closed, and therefore recovery requires the rediscovery of the peer and the reconnection to it. With our current setup, the peer discovery may exceed a minute (Table 2). We could trigger an Inquiry at that point, but it would still take over 6 s and waste a lot of resources (power and bandwidth - Section 4.1).
The high cost of recovery prevents us to use a short Link Supervision Timeout, and this is the reason why its default setting is 20 s Table 1. To have efficient recovery, we need a mechanism for blocked link event that doesn't close the link, similar to our implementation over IrDA [11].
A standard way to monitor link quality is through RSSI measurements (signal strength). The blocked link event could be generated when the RSSI goes below a specific threshold. The BlueTooth hardware offers an API to read the last RSSI measured on each connection [2].
RSSI values depend on the hardware characteristics. Therefore, the RSSI threshold need to be calibrated for each specific hardware, which is highly unpractical.
RSSI is mostly affected by distance, but not by random interference. If a strong interferer blocks communication, it won't affect RSSI, but the link may be totally blocked.
The API doesn't offer any way to know when the RSSI measurement was last updated, so the RSSI reading may not correspond to the present situation. When communication breaks, no signal is received, so the RSSI is no longer updated, while the last RSSI reading might be still strong.
The RSSI is not carried in each received packet, it has to be explicitly and separately probed at regular intervals. This adds some I/O overhead and time delay.
The BlueTooth RSSI mechanism may be used to detect blocked links in
some conditions, but we feel that it's not dependable enough to cover
all real world cases.
5.3 QoS latency variation limit
Our preferred way to implement the blocked link event would be through the BlueTooth QoS mechanism. BlueTooth QoS allows to set a latency variation limit in the link layer : this generates an event for packets which can't be properly transmitted within this time constraint [2].
Delays in transmission are mostly due to retransmissions, which are caused by excessive range or interference. When the link is blocked, packets would be retransmitted for a long time, and therefore an event would be eventually generated.
Unfortunately, current implementations don't support this QoS feature (Section 4.4), so we could not experiment with it and determine its proper setting.
The solution we have finally implemented is a Transmit Watchdog in the BlueTooth protocol stack.
Each time some packets are successfully sent, the BlueTooth hardware send a Number Of Completed Packets HCI event [2]. The delay between the time the packet was submitted to the hardware and this event is a good approximation of the actual transmission delay, and can be used to generate the blocked link event.
To avoid the overhead of monitoring all transmitted packets and Number Of Completed Packets events, the Transmit Watchdog need to be implemented in the lower layer of the BlueTooth stack (Section 6.1).
This mechanism has some flaws. It can't distinguish transmit delays due to a blocked link or normal BlueTooth operation (heavy loaded link, Power Saving, Inquiry...). This is why we would prefer a solution implemented in the MAC itself (Section 5.3). For example, to test this mechanism we just had to set the link in Power Saving Hold mode [2]. Fortunately for us, the hardware used was able to transmit and Inquire in parallel, so Inquiry didn't trigger the watchdog.
The Transmit Watchdog is set to 500 ms (Table 1), to balance performance and
spurious events. Recovery is triggered by the absence of blocked
link event (i.e. if no event has been received for more than
500 ms).
6 Usage models and findings
The current implementation of Connection Diversity over BlueTooth is
quite flexible and enables various usage models. However, those also
expose some usability issues of BlueTooth, where some design features
of the BlueTooth protocol impact the user experience of any BlueTooth
peer to peer application.
6.1 Implementation details
Connection Diversity has been implemented on Linux [8]. The hardware used is 3Com USB BlueTooth dongles (CSR chipset, BlueTooth 1.1 compliant, 100m range). The BlueTooth Linux stack is BlueZ 2.3 [9], with its standard SDP and BNEP support. We tested various standard Linux applications ; web browsing, mp3 streaming, telnet, ftp...
Both the discovery and identity process are implemented in a standalone daemon. The IP adaptation is the BNEP kernel module of BlueZ. The BlueTooth manager is implemented in a module of the Connection Manager daemon. The BlueTooth resolver is a NSS library [11].
We implemented the Transmit Watchdog in the low level of BlueZ. A
timer is activated for each ACL transmission and canceled when the
Number Of Completed Packets event is received. When the timer
fires, it generates a pseudo-HCI event to user space applications.
6.2 Transparent usage model
Connection Diversity aims for full transparency : the user and the application should not be aware of the BlueTooth link. In this usage model, we want to support any IP application over BlueTooth without explicit user setup. This also allows the Policy Manager to decide itself if it should use BlueTooth or an alternate link for each TCP connection.
This usage model is very intuitive. The user just need to start his favorite TCP/IP application and specify the DNS name or IP address of the peer, or use a wildcard (for example any.bt). The Connection Manager automatically handle all the low level details for the user (connection, handoff...).
To achieve this, the BlueTooth discovery module must be set to do periodic Inquiry and collect identity of reachable peers. When the Connection Manager detects an application that wants to communicate this peer, it automatically establishes the associated BlueTooth connection (Section 3.5).
Name resolution is instantaneous, because all peer identities are cached (Section 3.3). The establishment of the link is fairly fast (Table 2), because the MAC address is already known (therefore mostly equal to the Paging time).
The main issue is that each peer has to do periodic Inquiry, which is slow (Table 2), consumes power and results in a significant number of connection failures (Section 4.1).
| Action | Typical time |
|---|---|
| Page (no failure) | 150 ms - 700 ms |
| SDP request (excluding Page) | < 40 ms |
| BNEP + IP setup (excluding Page) | ˜ 70 ms |
| TCP connection, transparent mode | 250 ms - 850 ms |
| TCP connection, explicit mode | ˜ 8.5 s (1 peer) |
| TCP connection, Co-Link on IrDA | ˜ 2s |
| Peer discovery (periodic Inquiry) | 10 s - 140 s |
| Handoff to 802.11 (blocked link) | 700 ms |
| Recovery from 802.11 (unblocked) | 900 ms |
The typical usage model for most BlueTooth applications is to have discovery and connection explicitly triggered. Our current implementation allows to reproduce this usage model with unmodified TCP/IP applications.
To enable this, the user must specify in the application only BlueTooth link local names (Section 3.6) and can not use regular IP addresses or DNS names. Those names force on-demand name resolution, therefore periodic Inquiry doesn't need to be run by the discovery module.
The link local name specified is resolved by the BlueTooth ad-hoc resolver. As periodic Inquiry is disabled, it triggers a full Inquiry and waits until the discovery module has queried all the discovered peers via SDP. The name resolution process takes a minimum of 7s (Table 2) and increases with the number of discovered peers (and this time also depends on the success or failures of the SDP queries).
The BlueTooth destination must also learn the identity of the initiator of the connection, to set up IP properly. When the initiator does its SDP query on the destination, the destination uses the passive discovery mechanism (Section 3.2) to query back the IP identity of the initiator.
When the name resolution is done, the application starts sending data to the destination. The demand mechanism of the Connection Manager triggers the establishment of the BNEP connection, similar to the previous usage model.
The main advantage of this usage model is that there is no periodic
Inquiry, so power consumption is lower and connection setup is more
reliable. Unfortunately the whole setup is so slow that it is
noticeable to most users (Table
2). In addition the restriction to only use local link names
prevent compatibility with the rest of Connection Diversity.
6.4 Co-Link usage model
One of the main issues with BlueTooth is the need to perform Inquiry (Section 4.1). By using Co-Link, we can use a link offering a better discovery process to enable BlueTooth and bypass Inquiry entirely [13].
The two alternatives that we currently support are IrDA and 802.11. Using 802.11 is problematic because it needs to be preconfigured (ESSID and mode setting). On the other hand, IrDA is a good discovery link [6].
IrDA discovery is relatively low power, efficient and fast. The default setup on IrDA is to have periodic discovery every 3s [11]. The full connection setup (including TCP/IP) over IrDA is less than 1s [12].
The usage model is transparent, identical to our initial usage model (Section 6.2) with the restriction that the IrDA ports must be aligned. The user can specify an IP address, DNS name, link local name or wildcard such as any.irda.
After the initial setup over IrDA, the application start to communicate immediately. In parallel, Co-Link does the HTTP query, enables the BlueTooth port, and does a SDP query to the peer. After those steps are completed, the connection may be migrated to BlueTooth using P-Handoff.
This is a typical run using a SIR link (115 kb/s) :
time event => action 23:19:33.678 packet on demand channel => connect on IrDA 23:19:34.375 connected on IrDA => forward packets on IrDA 23:19:34.378 packets forwarded => Start Co-Link query 23:19:34.521 Co-Link reply => connect on BlueTooth 23:19:35.287 connected on BlueTooth, P-Handoff done
Another scenario is to use BlueTooth to activate and configure a 802.11 link, in this case the usage model is similar to the two previous ones, and with similar restrictions.
P-Handoff is fully functional over BlueTooth and transparent to the user. When a BlueTooth connection is blocked, its TCP connections are automatically migrated to an alternate link layer, if the BlueTooth link layer recovers TCP connection may be migrated back (based on policy).
The implementation of the blocked link event permits fast handoff. A typical handoff to 802.11 takes around 700 ms (Table 2), which is the sum of the watchdog timeout (500 ms) and the 802.11 connection setup time (200 ms) [12].
In case the link unblocks (absence of watchdog event), the recovery time is around 900 ms, and recovery is very reliable. While recovery is happening, traffic still flows on the alternate link, so further optimisation is not really needed.
P-Handoff also automatically migrates TCP connections from an alternate link to BlueTooth, when either the peer is discovered over BlueTooth or the alternate link is blocked.
The Connection Diversity framework is flexible enough to accommodate the BlueTooth technology. Various modules need to be added to the framework, to handle the Inquiry process, SDP queries and BNEP connections. The techniques we implemented and our configuration of BlueTooth is mostly generic and should apply to other applications.
The current implementation of Connection Diversity can make full use of BlueTooth and offers several useful usage models for peer to peer TCP/IP networking. The implementation has been optimised to give good performance and ease of use, and is only limited by BlueTooth itself.
Using Co-Link can workaround the slow and expensive Inquiry process needed to discover new peers. The implementation of a transmit watchdog allows fast and predictable handoff, as well as fast and reliable recovery from erroneous handoffs.
Based on this experience, we make suggestions of improvements to the BlueTooth implementations to aid peer to peer applications, such as adding QoS support, Paging Probes and using Co-Link.
Thanks to Max Krasnyansky, Marcel Holtmann and Stephen Crane for the BlueZ hacking opportunities and integrating my patches, and thanks to Steven Singer for his detailed explanations of CSR firmware features.
Thanks to Casey Carter for the infrastructure of the Connection
Manager, and Venky Krishnan and Tajana Simunic for their picky review
of this paper.
9 References