SeminarTopics.co.in

BlueStar


Published on Nov 23, 2015

Abstract

An important challenge in defining the BlueStar architecture is that both Bluetooth and WLANs employ the same 2.4 GHz ISM band and can possibly impact the performance. The interference generated by WLAN devices over the Bluetooth channel called as persistent interference , while the presence of multiple piconets in the vicinity creates interference referred to as intermittent interference.

To combat both of these interference sources and provide effective coexistence, authors proposed a unique hybrid approach of adaptive frequency hopping (AFH) and a new mechanism called Bluetooth carrier sense (BCS) in Blue-Star. AFH seeks to mitigate persistent interference by scanning the channels during a monitoring period. BCS takes care of the intermittent interference by sensing channel before transmission.

BlueStar takes advantage of the widely available WLAN installed base as it is advantageous to use pre-existing WLAN infrastructure. This can easily support long-range, large-scale mobility as well as provide uninterrupted access to Bluetooth devices .

Most recent solutions do not tackle the issue of simultaneous operation of Bluetooth and WLANs, that is, either Bluetooth or WLANs - but not both - can access the wireless medium at a time. The architecture proposed enables simultaneous operation by using existing WLAN hardware infrastructure. BlueStar enables Bluetooth devices, belonging to either a piconet or a scatternet, to access the WAN through the BWG without the need for any fixed Bluetooth access points, while utilizing widely deployed base of IEEE 802.11 networks. Introduction of BlueStar

BlueStars produces a mesh-like connected scatternet with multiple routes between pairs of nodes. It is a distributed solution. That is, all the nodes participate in the formation of the scatternet. But they do so with minimal, local topology knowledge (nodes only know about their one-hop neighbors). BlueStars, a new scatternet formation protocol for multi-hop Bluetooth networks, that overcomes the drawbacks of previous solutions in that it is fully distributed, does not require each node to be in the transmission range of each other node and generates a scatternet whose topology is a mesh.

The protocol proceeds in three phases:

1.The first phase, topology discovery , concerns the discovery of neighboring devices . This phase allows each device to become aware of its one hop neighbors' ID and weight.By the end of this phase, neighboring devices acquire a "symmetric" knowledge of each other .

BlueStar Protocol 1

2.The second phase takes care of BlueStar (piconet) formation. Given that each piconet is formed by one master and a limited number of slaves that form a star-like topology, we call this phase of the protocol BlueStars formation phase. Based on the information gathered in the previous phase, namely, the ID, the weight, and synchronization information of the discovered neighbors, each device performs the protocol locally. A device decides whether it is going to be a master or a slave depending on the decision made by the neighbors with bigger weight. By the end of this phase, the whole network is covered by disjoint piconets.

BlueStar Protocol 2

 

3. The final phase concerns the selection of gateway devices to connect multiple BlueStars. The purpose of the third phase of our protocol is to interconnect neighboring BlueStars by selecting inter-piconet gateway devices so that the resulting scatternet is connected whenever physically possible. The main task accomplished by this phase of the protocol is gateway selection and interconnection.

BlueStar Protocol 3

Bluetooth carrier sense (BCS) :

BlueStar employs carrier sense so that intermittent-like interference can be avoided. Carrier sensing is fundamental to any efficient interference mitigation with other technologies using the same ISM frequency band, and among Bluetooth piconets themselves. Author has incorporated BCS into Bluetooth without any modifications to the current slot structure.

Before starting packet transmission, the next channel is checked (i.e., sense) in the turn around time of the current slot. If the next channel is busy or becomes busy during the sense window, the sender simply withholds any attempt for packet transmission, skips the channel, and waits for the next chance. Otherwise, packet transmission is carried out. A direct consequence of this approach is that, eventually, an ARQ (automatic retransmission request) packet will be sent when the slot is clear and the communication is carried out.

Future work in BlueStar includes defining a more elaborate capacity allocation algorithm. In addition, we plan to investigate the correlation amongst the various simulation parameters in order to assess their impact on BCS and AFH. Mobility of both IEEE 802.11 and Bluetooth devices and its impact on both systems are also part of our future research.