Bluetooth Resource Center

Home
Search
Market Research
Add a Link

What Is Bluetooth?

Members

Bluetooth Mobility & Roaming

   Two major current limitations of Bluetooth are: that communication between devices must be direct (and hence is limited by the quality of service of the radio channel between them); and secondly that they do not support the movement of an active terminal from one network interface device to another. Essentially in Bluetooth, a device in a piconet A cannot communicate with another bluetooth device in a different piconet B, regardless if it was a member of piconet A previously. This article briefly examines several theoretical ways in which these interpiconet issues could be handled, and developed.

    Note : the Bluetooth SIG is in the process of addressing these issues in new profiles, however if you are not an adopter member you cannot have access to these frameworks. In order to prevent the accidental disclosure of any of the discussions , nothing here is based or influenced by the profile discussions. This means that models presented here may not relate to the profiles or to any actual roaming implementation.    

Theoretical/Technical Papers on Bluetooth Roaming

    Although the possibility exists of implementing a LAN based network of Bluetooth devices (Bluetooth devices implementing the LAN Access Profile , for example), this still requires an intermediary of a non-bluetooth link (e.g fixed line internet) between two LAP Devices. Currently there is no profile specified which elaborates how intersecting piconets can communicate. However this has not prevented research into this area , and the follow-on question of Roaming. In recent months there has been a large increase of new papers concerning modifications to or analysis's of the Bluetooth Radio System. Some of these have focused or touched on ways of handling roaming. A cross-section of these papers have been examined here:

• A Routing Vector Method for Routing in Bluetooth Scatternets P. Bhagwat, A. Segall
• IP Services over Bluetooth: Leading the Way to a New Mobility M. Albrecht, M. Frank, P. Martini, M. Schetelig, A. Vilavaara, A. Wenzel
• Routing Connections In Bluetooth C. McDaid
• Transmission of IP Packets over Bluetooth Networks (Note: work in progress) Atwal K. , Akers R.

A Routing Vector Method for Routing in Bluetooth Scatternets

    This paper proposes an innovative ad hoc routing strategy for bluetooth scatternets, based on the concept of route vector. Although a number of routing schemes for wireless models already exist or have been proposed, Bluetooth scatternets differ fundamentally in many respects from other wireless networks.

    The methods presented in this paper uses the means of Route Vector, ie.e the encoding of source route paths in Bluetooth scatternets, and can be used to broadcast packet throughout the scatternet or to a single target. To accommodate this method of routing bluetooth packet through a scatternet, two protocols are covered: route discovery & packet forwarding

Packet Forwarding

    In this paper , the means to provide packet forwarding is done through the the definition of a Layer 3 header & payload. Assuming that the Layer 2 consists of the ordinary 54-bit Header (containing the local-piconet designated AM_ADDR of the destination) + 0-2745 bit payload containing the voice and/or data field of a bluetooth packet (see Packet Format). Now within the payload we define a layer 3, which will define the first few bits of the payload as a layer 3 header. This header contains a number 2 flags, (FF & BF), a destination address (which is the remote-piconet designated AM_ADDR of the destination, this value is provided by route discovery) and a routing vector field, which contains the path of the packet(s) , and consists of an alternating sequence of AM_ADDR's and LocID's (a 3-bit number allocated to each piconet connected to a bluetooth device).

    For a Unicast packet the flow is as follows:Once the path has been inserted into the RVF field of the packet , the source device sends it to the AM_ADDR of a relay device (a relay device is the term to a device connected to one or more piconets), which then sends it to the next AM_ADDR on a different piconet,which has been determined by the matching the LocID stored in the RVF with the LocID assigned to each piconet of which the relay device is a member of.  After each relay through a piconet, the RVF field is reduced until, it is zero, in which case the destination piconet has been reached, and the packet is sent to the correct AM_ADDR. Broadcast of a packet through a piconet is different and relays on a growing the RVF field, with each relay device sending the packet to every device not already on the RVF

Route Discovery

    Route discovery is achieved by using broadcast SEARCH and unicast REPLY packets. The payload of the SEARCH accumulates the list of pairs that represent the route from the destination to the source. Each relay that receives a SEARCH adds it's AM_ADDR and the LocID of the piconet in which it has received the packet, before forwarding ton the SEARCH. It then sends a REPLY to the packet source, along the path indicated by the SEARCH packet. In this way the packet source device can determine the scatternet environment.

IP Services over Bluetooth: Leading the Way to a New Mobility

    This document first examines existing ways of implementing networks in mobile environments before showing how to create a Bluetooth mobile network: the BLUEPAC system (BLUEtooth Public ACess).  It does this by taking IP an a basis, and also combining functionalities of Mobile IP and  Cellular IP for routing issues and handover support respectively.

    The BLUEPAC system is made up of 3 stratum,

• a Gateway,
• BLUEPAC Base Station (BBS) and i
• individual BT devices,

much like the report Routing Connections In Bluetooth, presented below.The Gateway attaches the BLUEPAC LAN to the rest of the world, and is directly connected to the BBS's . A bluetooth link is used to communicate between each BBS and any BTs in area. A local IP is used to address to a BT connected to a BBS, this Local IP is either assigned or has been previously pre-assigned.

    To handle roaming of both foreign BTs (BT's with foreign care-of-addresses) and home BTs (BT's with home care-of-addresses) Mobile IP concepts and functionalities are widely used. For example: Foreign BTs (with a pre-assigned IP address) arriving in the BLUEPAC LAN can use their home address to forward communication to themselves. Also the reverse, of Home BTs entering a foreign network is handled:

1. by either assigning a unique IP address to each Mobile BT as a co-located care-of-address, (thus meaning it becomes a full member of the foreign network),
2. or by assigning a foreign agent care-of-address for all mobile BTs in the foreign network (i.e. an address of the foreign agent).

    Roaming/Handoff is handled by using some of the concepts presence in Cellular IP. In the BLUEPAC system, several routers may exist between the Gateway and the BBS. data that passes from the BT to the Gateway may pass through routers. Each packet received from a router updates the routing cache by mapping the sending device's IP address to the interface the packet was received from, i.e. the interface leading to that device. When a BT leaves its current BBS range it joins onto a new BBS. It continues sending data through the new BBS, but these packets update the routing caches in the routers, on their way to the gateway. For the period up to a timeout value, 2 routes are available, but the old route times out after not been used for a short while. all nodes above the Gateway do not notice the handover. 

Routing Connections In Bluetooth 

     Although certainly not up to the same standard as the reports detailed above, (it was written as my final-year college project project), this report merits a look due to it's bluetooth network setup and it's practical approach of handling the handover issue.

     The routing network introduced and detailed in this report is the Bluetooth Routing Scheme, (sometimes abbreviated to BRS). It is a distributed network involving:

• An MSC, (Message Switching Centre), which is the hub of the network.
• This has several stationary Bluetooth devices, called FMs (Fixed Masters) attached to the MSC by fixed line connections.
• These Fixed Masters can contain mobile Bluetooth Devices, called MTs (Mobile Terminals), in their piconets.

    The fixed line connections here use the Bluetooth protocol (slightly modified, - different physical layer) to communicate to the MSC. Although this does seem a contradiction in terms (why not use a dedicated LAN fixed line communication protocol like ATM or Etherent?), it does mean that , if so desired, the communication link between the MSC and FMs can be replaced by a Bluetooth wireless connection. The fixed line bluetooth connection was introduced to ensure connectivity in a large office building environment.

    Routing is done by Device BD_ADDR, of which a dynamic routing table is maintained in the MSC, this routing method is quite straight-forward. The implementation of Handover in this report is probably the most interesting. A very quick overview

1. Either the FM or MT detects the current Bluetooth link connecting them is 'bad' (by the current RSSI reading setting at both side of the link)
2. a handover request is sent to the MSC. This request contains the Bluetooth device address of the MT, the device address of the New Master (determined by the MT slightly earlier) and the difference between the Mobile Terminal’s native clock and the new Master’s clock, i.e. the clock offset.
3. The MSC then can transmit the MT’s address and clock offset to the new Master and instruct it to start paging for the MT. 

    The RSSI/power setting bad link detection method outlined above seems to be the most logical means of detecting when handover should occur in Bluetooth, and so the report is interesting in bringing up this procedure. Also a slave-initiated handover seems  to be the best method of handling handover. Although the BRS has errors, including some obvious ones i can see in the Bluetooth protocol deduction, it has been included to show a possible means of handling handover. For the complete report, plus presentation & demo app, click here.

Transmission of IP Packets over Bluetooth Networks

    The above papers are not the only way of tackling the routing problem, one very in-depth and interesting document is  Transmission of IP Packets over Bluetooth Networks (ver 1.1), a work-in-progress internet draft published by the Internet-Engineering Task Force. this shows a standard for the transport of Internet Protocol Version 4 and Internet Protocol Version 6 datagrams over Bluetooth piconets. the draft is probably the most advanced and feasible of all the Bluetooth routing networks proposed.

    In brief this draft document adds a Bluetooth Network Encapsulation Protocol (BNEP). BNEP runs over the Bluetooth L2CAP layer, and provides a method for IP Encapsulation, by allowing IP to run over the BNEP layer. It has drawbacks in that its adds another layer of complexity etc. , but the same can be said for routing solutions, they must present additions to the bluetooth protocol if they are to be feasible (and successful). The proposed solution will have the following stack on an IP Router attached to an IP capable wired-line network/ wireless network:

    One interesting proposal in this draft is the use of an Address Resolution Protocol. This is to allow an End-User wishing to discover the  identity of device attached at some distance away on the IP network (i.e. not on the same piconet, but on the same network (wireless or otherwise)). This protocol takes the bluetooth link-layer information of a device and uses it to map to an equivalent IP address. Each Master must maintain a table of IP addresses to link-layer addresses for every attached IP capable device. The mapping may be an IP address to a logical link-layer address (link local), or a physical link-layer address. An implementation may use a logical link-layer address such as the logical Connection Identifier (CID)provided by L2CAP and optionally the Bluetooth Device Address (BD_ADDR).

Conclusion

    It is a widely-held belief that a lack of the ability to create a 'proper' Bluetooth pan-piconet network is one major drawback of the present incarnation of the Bluetooth Specification. However it must be remembered that Bluetooth was originally designed as a low-cost/low-power system, and therefore routing handover etc. may have been not so much a necessity, rather a luxury a low-cost device could ill-afford. 

    Regardless of the past practicalities of not including network support, work by the Bluetooth SIG on future profiles addressing routing issues is on-going, showing that it is finally being addressed. Other companies are also tackling the issue. Some of their proposals resemble the papers presented above, illustrating the paper's relevance in seeking to understand how to combine Bluetooth's unique protocols , with the demands of a fully mobile, wireless network.

Back to Cathal's Corner     More Bluetooth Articles