UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Bluetooth scatternet formation and internetworking with 802.11 and GPRS Chakrabarti, Satyajit 2004

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2004-0397.pdf [ 8.73MB ]
Metadata
JSON: 831-1.0051058.json
JSON-LD: 831-1.0051058-ld.json
RDF/XML (Pretty): 831-1.0051058-rdf.xml
RDF/JSON: 831-1.0051058-rdf.json
Turtle: 831-1.0051058-turtle.txt
N-Triples: 831-1.0051058-rdf-ntriples.txt
Original Record: 831-1.0051058-source.json
Full Text
831-1.0051058-fulltext.txt
Citation
831-1.0051058.ris

Full Text

Bluetooth Scatternet Formation and Internetworking with 802.11 and GPRS by Satyajit Chakrabarti B.Tech., Institute of Engineering and Management, University of Kalyani, 2002  A THESIS S U B M I T T E D IN P A R T I A L F U L F I L L M E N T O F THE REQUIREMENTS FOR THE D E G R E E OF  Master of Science in T H E F A C U L T Y O F G R A D U A T E STUDIES (Department of Computer Science)  We accept this thesis as conforming to the required standard  The University of British Columbia September 2004 © Satyajit Chakrabarti, 2004  UBCl  m)  THE  UNIVERSITY OF BRITISH COLUMBIA  FACULTY OF GRADUATE STUDIES i  Library Authorization  In presenting this thesis in partial fulfillment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission.  £ A T y AH" I T  (°^AKKftBftRT1  XI h°l /aoo4  Name of Author (please print)  Title of Thesis:  D e  9  r e e :  Department of  Date (dd/mm/yyyy)  *R IxA P  0 ^ .  HafiT^  oJ  fjQ Vvo  Go <>3J{^AAQhftYvyiflJnOV^QW\(L :  Ano^QQ.  puW>  Year:  ,3rjo4  Sebmfl.  The University of British Columbia I Vancouver, BC  Canada  grad.ubc.ca/forms/?formlD=THS  page 1 of 1  last updated: 20-Jul-04  Abstract Mobile A d - H o c n e t w o r k s ( M A N E T ) using B l u e t o o t h technology has gained immense popularity among the networking community. Nowadays electronic devices like cell phones come equipped w i t h Bluetooth. Whereas Bluetooth technology has certain obvious advantages like low power consumption and reliable connection but it suffers some inherent problems including low area of operation, limit of 7 slave devices per master device. 802.11 technology on the other hand, has a wider area of operation and therefore very useful as Access points and higher bandwidth i n the order of 11 M b p s i n 802.11b. B u t 802.11 has a higher power consumption than Bluetooth. Cellular networks have a much wider coverage i n geographical area than 802.11. Complementing B l u e t o o t h w i t h 802.11 and cellular network technology like G P R S would solve the shortcomings of these three technologies. T h i s thesis is composed of four projects.  It introduces R C B T E E ( A Re-  motely Controlled Bluetooth Enabled Environment) which presents a simple Bluetooth Scatternet formation algorithm w i t h remote control applications and a single access point connected to a content server. T h e n E q u i B l u e is presented.  EquiBlue  is a load balanced Bluetooth Scatternet formation algorithm. T h e n B l u e F i is i n troduced.  B l u e F i presents a conceptual software layer i n the protocol stacks of  Bluetooth and 802.11 to realize interoperability i n devices w i t h both Bluetooth and 802.11 interfaces. A t the end, BlueMobile, a novel protocol for handoff's i n Bluetooth, 802.11 and G P R S networks is presented. A thorough, analysis of all the four projects is done arid detailed simulation results are provided. T h e results underscore the importance of achieving convergence i n Bluetooth networks w i t h other networks like 802.11 and G P R S .  ii  Contents  Abstract  ii  Contents  iii  List of Tables  vi  List of Figures  vii  Acknowledgements  x  Dedication 1  2  xi  Introduction  1  1.1  Motivation  2  1.2  Thesis contributions  4  1.3  Thesis Outline  6 7  Background 2.1  Bluetooth Technology  7  2.2  Bluetooth P r o t o c o l Stack  8  2.2.1  R a d i o Layer  9  2.2.2  Baseband  10  2.2.3  L i n k Manager Protocol ( L M P )  11  2.2.4  Logical L i n k C o n t r o l and A d a p t a t i o n P r o t o c o l ( L 2 C A P ) . . .  12  iii  2.2.5  3  4  5  Host Controller Interface  13  2.3  B l u e t o o t h i n Operation  13  2.4  Bluetooth Power Modes  14  2.5  802.11 Technology  14  2.6  G P R S Technology  17  A Remotely Controlled B l u e t o o t h E n a b l e d Environment  18  3.1  Introduction  18  3.2  Related W o r k  19  3.3  Architecture of Remotely Controlled Bluetooth Enabled Environment (RCBTEE)  20  3.4  Scatternet Formation A l g o r i t h m  20  3.5  Simulation and Analysis of the Bluetooth Environment ( R C B T E E ) .  30  3.6  Applications for R C B T E E  34  3.7  Discussions  35  EquiBlue:  A L o a d Balanced Scatternet formation algorithm.  36  4.1  Introduction  36  4.2  Related W o r k  38  4.3  EquiBlue Algorithm  40  4.4  Simulation Results and Analysis  46  4.5  Discussions  52  B l u e - F i : A Convergence Architecture for B l u e t o o t h and 802.11 wireless networks  53  5.1  Introduction  53  5.2  Related W o r k  54  5.3  B l u e F i Handoff A l g o r i t h m  54  5.4  Analysis of the A l g o r i t h m  62  5.5  Bluetooth and 802.11 Coexistance  65  iv  5.6 6  7  Discussions  71  B l u e M o b i l e - A M o b i l e IP based Handoff system for Bluetooth, 802.11 and G P R S links  72  6.1  Introduction  72  6.2  Related W o r k  74  6.3  Mobile I P  74  6.3.1  Mobile I P Architecture  74  6.3.2  M o b i l e I P A d a p t a t i o n for Bluetooth, 802.11 A N D G P R S  . .  76  6.4  Mobile I P Handdoff A l g o r i t h m between Bluetooth, 802.11 & G P R S .  78  6.5  Analysis of the A l g o r i t h m  82  6.6  Discussions  87  Conclusions  88  7.1  Summary  88  7.2  Future W o r k  90  Bibliography  92  Appendix A  97  v  L i s t of T a b l e s  2.1  Bluetooth Power Modes  14  3.1  Comparison of R C B T E E w i t h other Bluetooth Scatternet algorithms  34  4.1  Comparison of E q u i B l u e w i t h other Scatternet Algorithms  52  5.1  A P I ' s available for the L S C for use  62  5.2  Summary of Results of B l u e F i  65  5.3  Comparison of Bluetooth and 802.11b  66  5.4  Comparison of Wireless standards  67  6.1  Results of BlueMobile  86  vi  L i s t of F i g u r e s  2.1  A Tree Structured Scatternet  8  2.2  T h e B l u e t o o t h P r o t o c o l Stack  9  2.3  B l u e t o o t h Packet Format [20]  9  2.4  B l u e t o o t h Packet Access Code Format [20]  10  2.5  B l u e t o o t h Packet Header [20]  10  2.6  B l u e t o o t h L i n k Controller State D i a g r a m [20] • • • •  11  2.7  Overview of the Lower software layers of the B l u e t o o t h stack [20] . .  12  2.8  G P R S Network Architecture  17  3.1  T h e architecture of the B l u e t o o t h Remote control environment  3.2  Piconet formation  20  3.3  Scatternet formation w i t h multiple piconets  21  3.4  A Tree Structured Scatternet  22  3.5  R C B T E E Step 1  23  3.6  R C B T E E Step 2  23  3.7  R C B T E E Step 3  24  3.8  R C B T E E Step 4  24  3.9  R C B T E E Step 5  25  3.10 R C B T E E Step 6  25  3.11 R C B T E E Scatternet Simulation  31  3.12 R C B T E E Remote Control Centre  33  vii  . . .  19  3.13 R C B T E E Scenario  33  4.1  M e s h Structured Scatternet  37  4.2  E q u i B l u e Step 1  41  4.3  E q u i B l u e Step 2  41  4.4  E q u i B l u e Step 3  42  4.5  E q u i B l u e Step 4  42  4.6  E q u i B l u e Step 5  43  4.7  E q u i B l u e Step 6  43  4.8  E q u i B l u e Step 7  44  4.9  E q u i B l u e Simulation  47  4.10 T o t a l Number of Piconets V s Number of Nodes  48  4.11 Scatternet Diameter V s Number of Nodes .  49  :  4.12 M e a n number of nodes per piconet V s Number of Nodes  49  4.13 V a r i a t i o n i n the mean number of piconets as the number of piconets increases-.  . . . . .  50  4.14 T h e total Inquiry messages send i n the algorithm  50  4.15 T h e total Page messages send i n the algorithm  51  4.16 T h e total Algorithmic messages send i n the algorithm  51  5.1  B l u e F i Software Layer Concept  56  5.2  B E R V s C I R i n a Bluetooth Transceiver  67  5.3  B E R V s C I R i n a Bluetooth Transceiver  68  5.4  B E R V s C I R i n a 802.11 Transceiver at 1Mbps  5.5  B E R V s C I R i n a 802.11 Transceiver at 11Mbps  69  5.6  B l u e t o o t h Transceiver w i t h 802.11 Interferer at 1Mbps and 11 M b p s  69  5.7  802.11 Transceiver at 1Mbps and 11Mbps w i t h B l u e t o o t h Interferer  70  6.1  I P datagram flow to and from a Mobile Host using Mobile I P . . .  6.2  T h e B l u e M o b i l e network architecture  viii  : .  .  68  75 78  6.3  M H moves from GPRS to Bluetooth  80  6.4  Overlapped Bluetooth and 802.11 zone  82  ix  Acknowledgements I would like to express my gratitude to m y supervisor, D r . Son Vuong, for his guidance, inspiration and encouragement. I am also grateful to D r . V i c t o r Leung for being my second reader and for his useful comments that have improved this thesis. I a m thankful to Prof. N o r m Hutchinson for his encouragement and feedback on my projects.  I would like to thank my Professors - Prof.  M i k e Feeley,  Prof. K a r o n Maclean, Prof. Joanna McGrenere, Prof. R a y m o n d N g , Prof. M a r k Greenstreet, Prof. Kellogg B o o t h , Prof. A l a n Wagner and Prof. G a i l Murphy. I gratefully acknowledge the financial support from the Department of C o m puter Science at U B C i n the forms of T A and R A as well as support from C I T R Network of Centers of Excellence, the Advanced Systems Institute of B C , and the industrial partner Proface I N D E . I would like to thank the co-authors i n various publications - L i y u n W u , A n i r b a n Sinha and Rajashree P a u l , as well as my lab mates - Sukanta Pramanik, Christian C h i t a , J u a n L i , K a m r a n M a l i k , X i a o J u a n C a i , G a r y Huang, K e n Deeter, M o h a m m a d A l a m , and Sergio G . Valenzuela. I would also like to acknowledge the love my parents, my grandma, my sister Sanghariiitra and brother-in-law Debashis gave and for their consistent support during m y graduate studies at U B C .  SATYAJIT  The University of British Columbia September  2004  x  CHAKRABARTI  To my mom, dad and grandma Always there for me, no matter what  Chapter 1  Introduction Bluetooth [1], [2], [3], [4] is a promising new short range wireless technology, which enables portable devices to form wireless ad hoc networks and P A N (personal area networks) and is based on a frequency hopping physical layer. T h i s implies that hosts communicate after having discovered each other by synchronizing their frequency hopping patterns. T h i s also means that even if all nodes are w i t h i n direct communication range of each other, only those nodes which are synchronized w i t h the transmitter can hear the transmission. To support any-to-any communication, nodes must be synchronized so that the pairs of nodes (which can communicate w i t h each other) together form a connected graph.  Bluetooth has become another important platform for ad hoc networking, apart from 802.11.  A d hoc networking over B l u e t o o t h can lead to many useful  applications. For example, i n a conference room, a special announcement can be broadcast to the Bluetooth enabled mobile phones and hand-held computers through an ad hoc network.  T h e area of ad hoc networking has gathered much research interests i n the past years. M a n y studies have concentrated on the routing issues of ad hoc networks  1  [5]. These studies usually assume that any two in-range nodes can communicate w i t h each other. Therefore, an ad hoc network can be modeled as a graph such that the in-range nodes are adjacent. For example, simulation-based studies [6], [7] of ad hoc routing protocols have been conducted w i t h a link-layer model based on or similar to the I E E E 802.11b standard.  A B l u e t o o t h network is composed of piconets. E a c h piconet contains one master and up to seven slaves.  Piconets can be connected into a Scatternet by  sharing slaves. A s shown by M i k l o s et al. [8] and Zurbes [9], the configuration of a scatternet has great effects on the performance of the network. For instance, when a scatternet contains more piconets, the rate of packet collisions increases.  1.1  Motivation  W h i l e much research has been done on the formation of Scatternet i n Bluetooth networks, other works have hitherto not investigated the load balance i n Scatternets. In Scatternets, sometimes lower processing power devices like cell phones can become Master devices, thus proving to be a bottleneck i n the Scatternet i n terms of processing power. Also, sometimes due to formation of large Scatternets w i t h many piconets causes packet collisions due to same frequency hopping spectrum i n neighboring piconets i n a Scatternet.  Since B l u e t o o t h hotspots and P A N s (personal area networks) are an emerging area, no investigation has hitherto been made into remote querying and remote controlling devices i n a B l u e t o o t h hotspot. W i t h W A P and W X M L and X H T M L becoming very popular tools i n web browsing from mobile devices, we thought it would be interesting to t r y to port our remote control and querying system to web enable it so that it could be used w i t h mobile devices as well.  2  Following are the previous works that have investigated handoff's: K a n s a l et al. [14] introduce a Handoff scheme for Bluetooth devices to allow mobility of devices i n B l u e t o o t h public access ( B l u e P A C ) environments. T h e paper by M i s h r a et al. [18] does a thorough analysis of the handoff procedure i n the 802.11 M A C layer. K a s t e l l et al. [19] presents security issues involved i n h y b r i d handover procedures. Pack et al. [15] uses a predictive authentication for fast handoff's i n 802.Ix mode. However, none of the previous works w i t h Bluetooth handoff's have investigated handoff w i t h other wireless technologies like 802.11 and G P R S . W i t h more and more handheld devices being shipped w i t h inbuilt Bluetooth and 802.11 interfaces, it's only natural that an interoperable framework is inevitable. I E E E 802.15.2 task group [10] looks into existence issues of Bluetooth W P A N ' s and 802.11 W L A N ' s .  In [44] Buddhikot et al. present integration of 802.11 and G P R S on seamless connectivity. M i n - h u a et al. [43] introduce a Mobile I P handoff scheme between 802.11 and G P R S . In [45] Sharma et al. bring forward a vertical handoff system between G P R S and W L A N by using extended Mobile IP. Albrecht et al. [42] present protocol concepts for an extension of I P for mobility issues i n B l u e t o o t h networks. Baatz et al. [17] concentrates on handoff support for mobility w i t h I P over Bluetooth. Perkins et al. [16] present a handoff scheme for M o b i l e IP's. None of the previous works on Mobile I P have focused on using Mobile I P to achieve handoff of Bluetooth w i t h 802.11 or G P R S .  In this thesis we focus on Bluetooth Scatternet formation and interoperability w i t h other prevalent wireless technologies- 802.11 and G P R S . In the first few chapters we concentrate on Scatternet formation issues and formation of a remote control and query enabled personal area network. W e investigate load balancing issues and present a load balanced Scatternet formation algorithm.  3  In the later part of the thesis, we focus on interoperability of Bluetooth w i t h 802.11 and G P R S . We t r y to solve this problem using two approaches - one using a software daemon that acts as a software layer conceptually between the protocol stack of Bluetooth and 802.11 by trapping packets between the interface and protocol stack.  In the other approach, we use Mobile I P to achieve handorT  between a Mobile I P enabled 802.11 and G P R S network.  1.2  Thesis contributions  T h i s thesis addresses two major deficiencies i n the area of Bluetooth technology: aspects of Scatternet formation and interoperability w i t h 802.11 and G P R S networks.  To address the problem of Scatternet formation, we have proposed R C B T E E and E q u i B l u e . R C B T E E presents a system for Remote controlling and remote querying B l u e t o o t h devices organized i n a Bluetooth hotspot according to a Scatternet formation algorithm. A remote web interface allows to control the B l u e t o o t h devices i n the hotspot as well as view the status of devices i n the hotspot. E q u i B l u e presents a novel load balanced Scatternet formation algorithm. E q u i B l u e assigns a weight to a device based on processing power and tries to reduce the piconet size for low weight devices and maximize the piconet size for higher weight devices. A t the same time, E q u i B l u e tries to keep the difference i n size between neighboring piconets small, i n case the neighbouring master devices are of similar weight. T h i s would be very useful i n applications where the Master device needs more resources like memory, processing power, since i n our system the higher processing power device is assigned the role of Master.  To address the problem of interoperability we have proposed B l u e F i and BlueMobile. B l u e F i presents a convergence architecture for B l u e t o o t h and 802.11 by introducing a software layer i n the protocol stack of B l u e t o o t h and 802.11. We  4  have analyzed various delay elements and optimized the convergence model. BlueMobile presents a novel solution for interoperability of Bluetooth, 802.11 and G P R S networks using Mobile IP. B y introduction of Mobile I P elements like Home Agent ( H A ) and Foreign Agent (FA) i n the network architectures, we analyze various delay elements i n the network and optimize the Handoff model.  T h e following are the research contributions of this thesis:  • W e propose a system for remote Control and remote querying of devices present i n a Bluetooth hotspot arranged according to a simple Scatternet formation algorithm. T h i s would be very useful i n applications where remoly querying the devices i n the hotspot is controlling devices is required. We have done a thorough estimation of the order of complexity of messaging between the B l u e t o o t h devices.-  -  , . .  ....  . ...  • W e present a load balanced Scatternet formation algorithm based on assigning weights to devices. We have simulated w i t h different number of nodes and evaluated it and shown that our algorithm is effective is achieving a load balanced network. O u r algorithm would be effective i n applications where the Master device needs more processing power, or where a load balance would increase the throughput i n the network. • W e propose a system for interoperability between Bluetooth and 802.11 devices by introduction of a conceptual software layer i n the protocol stack of Bluetooth and 802.11 which would actually be implemented as a operating system daemon which would trap the packets from the interface, modify or analyze them and send them to the protocol stack.  W e have analyzed the  various delay elements i n the handoff system. T h i s system would be able to support interactive audio, video and data applications over the network. 5  • W e present a novel Handoff system between Bluetooth, 802.11 and G P R S links based on Mobile IP. We introduce Mobile I P elements i n the networks of Bluetooth, 802.11 and G P R S and analyze all the cases of handoff between the different technologies. W e have also done an analysis of the delay elements i n M o b i l e I P handoff system. T h i s system would be able to maintain a T C P / I P connection over the Access point since typically the m a x i m u m retransmission timeout of T C P / I P is 1 minute. A u d i o or Video applications would suffer a slight jitter during handoff.  1.3  Thesis Outline  T h i s thesis is composed of seven chapters.  In Chapter 2, background information  and theory related to Bluetooth Scatternet formation and 802.11 and G P R S technologies is discussed.  Chapter 3 introduces a novel idea for remote control and  querying B l u e t o o t h device state i n hotspots - called " A Remotely controlled Bluetooth Enabled Environment ( R C B T E E ) " . Chapter 4 presents E q u i B L U E - a load balanced Scatternet formation algorithm. B l u e - F i : A n architecture for convergence of B l u e t o o t h and 802.11 networks, is presented i n Chapter 5. Chapter 6 presents B l u e M o b i l e - A Mobile I P based Handoff system for Bluetooth, 802.11 and G P R S links. F i n a l l y the thesis conclusion and future research work are discussed i n Chapter 7.  -  6  Chapter 2  Background 2.1  Bluetooth Technology  Bluetooth is short range 2.4 G H z I S M band technology.  It requires connection  oriented links before data can be sent or received [21]. Bluetooth radio system employs the Frequency Hopped Spread Spectrum (FH-SS) to gain access to the wireless medium. B l u e t o o t h devices share 79 channels of 1 M H z bandwidth w i t h i n the 2.45 G H z band. Frequency hopping improves security and F H - S S gives intereference i m munity.  A B l u e t o o t h Device(BD) can either take the role of a Master or Slave device. One Master B D can connect to at most 7 Slave B D ' s to form a piconet. A Master B D i n I N Q U I R Y state hops 3200 times per second according to a 32 channel hopping sequence. A Slave B D i n I N Q U I R Y S C A N state alters its listening frequency every 1.28 seconds along the same sequence. Once a Master B D discovers a Slave B D i n radio range and the Master B D learns the address and clock of the Slave B D , it switches to P A G E state and the slave switches to P A G E S C A N state. T h e pseudorandom frequency hopping sequence of both B D ' s are tightly synchronized prior to their entering the C O N N E C T E D state. Connection setup delay may be as long as 10 seconds during device discovery, and overcrowding the medium may increase the 7  delay more [25]. T h e radio range of B D equipped w i t h a class-B transmitter is only 10 metres [21]. W i t h class-A transmitter, the Bluetooth device range is 100 metres.  A piconet consists of 1 master and 7 slaves (as i n B l u e t o o t h 1.1b). Slaves can only communicate w i t h masters and Masters can only communicate w i t h slaves. A slave may be shared between two piconets as a "bridge-slave" allowing communication between the two piconets. After master and slave are connected they communicate w i t h a hopping sequence over all 79 channels at the rate of 1600 hops per second. Several Piconets join together through bridge slaves to form a Scatternet. A typical tree structured scatternet is shown is F i g . 2.1.  Figure 2.1: A Tree Structured Scatternet  2.2  Bluetooth Protocol Stack  T h e various layers of the Bluetooth protocol stack (Fig. 2.2) are briefly described below:  8  APPLICATION L A Y E R  A  4  TCS, RFCO.NDvl SDP  CONNECTOV'O BUS (USB, UART)  BLUETOOTH HARDWARE  RF (RADIO LAYER)  Figure 2.2: T h e Bluetooth P r o t o c o l Stack  2.2.1  Radio Layer  Bluetooth operates i n the unlicensed I S M band i n the frequency range 2400 M H z to 2483.5 M H z , i n most countries. Frequency H o p p i n g Spread Spectrum ( F H S S ) is used w i t h hops at 2402 + k M H z , where k = 0,1,2,3,.78. T h e Frequency hopping is used to combat interference and fading. T h e nominal hop rate is 1600 hops/second. Gaussian B i n a r y Shift K e y i n g is used to modulate the radio waves. T h e Gaussian prefilter has a bandwidth delay product B T = 0.5 . T h e transmitter power is OdBm for 10 metre range and 20 d B m for 100 metre range. T h e packet format of Bluetooth data packets is shown is F i g . 2.3. F i g . 2.4 shows the Bluetooth Packet Access Code format and F i g . 2.5 shows the Bluetooth packet header format. LSB  72  64  0-2745  ACCESS CODE  HEADER  PAVLOAD  MSB  Figure 2.3: Bluetooth Packet Format [20]  9  4  64  4  PREAMBLE  SYNC WORD  TRAILER  LSB  MSS 1  Figure 2.4: Bluetooth Packet Access Code Format [20] LSB  .• J  4  'lr  A M _ A O D R  TYPE  FLOW  1 1  ».  S E C *  •  ••  ,  MSB  KSC  Figure 2.5: Bluetooth Packet Header [20]  2.2.2  Baseband  T h e baseband layer controls the radio layer. T h e frequency hop sequences are provided by the baseband layer. Baseband layer also takes care of the encryption i n the lower layers, as well as packet handling. T w o types of links can be established between a master and a slave: 1. Synchronous Connection Oriented ( S C O ) L i n k T h e S C O link is symmetrical and point to point between the master and a specific slave. T h e S C O links reserve slots and can therefore be considered as a circuit-switched connection between the master and slave. T h e S C O links supports time critical information like voice traffic. U p t o three S C O links are supported, by a master for the same slaves or to different slaves. A slave can support upto three S C O links from the same master or two S C O links if the links originate from different masters. S C O packets are never retransmitted. SCO  links are optional and are not necessary to be implemented for B l u e t o o t h  compliance. 2.  Asynchronous Connection-Less ( A C L ) L i n k The ACL all  links provide a packet-switched connection between the master and  active slaves participating i n the piconet.  A C L links support both syn-  chronous and asynchronous data. Between a master and a slave, only a single ACL  link can exist. In majority of A C L 10  packets, packet retransmission is done  Bluetooth Ho^t Other Higher Layer Driver  *  HCI Driver  *  Physical Bus ( U S B , P C Card,Other) Driver Physical Bus Physical B u s ( U S B , P C C a r d , Other) Fiiniwmt' HardwareHCI Firmware Link Manager Firmware  t  B a c e b a n d C on trailer •  :  Bluetooth. Hardware | »l [ lj|  Software Firmware  [  | Hardware  Figure 2.6: B l u e t o o t h L i n k Controller State D i a g r a m [20] to ensure data integrity.  2.2.3  Link Manager Protocol (LMP)  T h e link manager P r o t o c o l is used i n link setup and control. T h e signals are interpreted and filtered out by the link manager on the receiving side and are not propagated to the higher layers. The L M P manages the piconet, and configures the links for service parameters like encryption. It provides functionality to attach or detach slaves, switch roles between a master and a slave and to establish A C L or S C O links. T h e L M P is also used to handle the low power modes - hold, sniff and park, which are designed to save power when the device is not sending data. F i g . 2.7 shows the state diagram of the B l u e t o o t h L i n k Controller.  11  Figure 2.7: Overview of the Lower software layers of the B l u e t o o t h stack [20]  2.2.4  Logical L i n k C o n t r o l and A d a p t a t i o n P r o t o c o l ( L 2 C A P )  T h e L 2 C A P protocol supports packet segmentation and reassembly, higher level protocol multiplexing, and conveying of quality of service information. T h e protocol multiplexing allows multiple applications to use the Bluetooth link. T h e segmentation and reassembly function allows the protocol to reduce the packet size provided to the size of the packets accepted by Baseband layer. T h e L 2 C A P accepts packet sizes upto 6 4 K b but the baseband layer can accept packets upto 2745 bits, so the L 2 C A P packets need to be segmented before sending to the lower layers. For received packets, the reverse procedure has to be followed where the packets are combined i n the proper order. L 2 C A P also allows applications to impose QoS on parameters like latency, delay variation and peak bandwidth. In general, L 2 C A P provides network layer functions to applications and higher layer protocols.  12  2.2.5  Host Controller Interface  T h e Host Controller Interface provides a command interface to the baseband controller and the link manager, and to access to the hardware status and control registers.  T h e H C I provides an uniform method of accessing Bluetooth baseband  capabilities. T h e H C I link commands provide the host w i t h the ability to control the link layer connections to other B l u e t o o t h devices. These commands involve the L i n k Manager to exchange L M P commands w i t h remote Bluetooth devices. H C I driver and H C I firmware is shown i n the lower layers i n F i g . 2.6.  2.3  Bluetooth in Operation  For A to talk to B : Step 1: Discovering a B l u e t o o t h device: 1. Device A transmits one or more inquiry packets 2. Device B replies w i t h F H S packet Step 2: Connecting to service discovery database: 1. A C L baseband connection is established. 2. L 2 C A P connection is set up over A C L channel. 3. S D P connection over L 2 C A P channel. 4. Device A receives D U N info from B ' s service discovery database. Step 3: Connecting to B l u e t o o t h service: 1. A C L link is set up. 2. Device A utilizes L M P to configure link. 3. L 2 C A P connection using the R F C O M M protocol 4. D U N connection is set up using R F C O M M connection. 13  The  2.4  Bluetooth Power Modes  Class 1 2 3  Table 2.1: Bluetooth Power Modes M a x output power Range Power control Mandatory100 m W (20 dbm) 100 m 2.5 m W (4 dbm) 10 m Optional 1 m l m W (0 dbm) Optional  T h e various Bluetooth Power modes are given below. Table 2.1 shows the power requirements and the range of various Bluetooth devices. Sniff M o d e : 1. Slave agrees w i t h its master to periodically listen for the master's transmissions. Hold Mode: 1. Device agrees to remain silent (in that particular piconet) for a given amount of time. 2. Device keeps its temporary address, A M . A D D R . Park Mode: 1. Slave device agrees w i t h its master to park until further notice. 2. Device relinquishes its active member address, A M _ A D D R . 3. Slave periodically listens to beacon transmissions from the master. 4. Slave can either be invited back (by the master) or can get itself unparked.  2.5  802.11 Technology  I E E E Standard 802.11 specifies a single M e d i u m Access C o n t r o l ( M A C ) sub layer and three P h y s i c a l Layer Specifications. 14  T h e M A C provides the following services:  1. Authentication (station service) 2. Deauthentication (station service) 3. Privacy (station service) 4. M S D U delivery (station service) 5. Association (distribution system service) 6. Disassociation (distribution system service) 7. D i s t r i b u t i o n (distribution system service) 8. Integration (distribution system service) 9. Reassociation (distribution system service) Stations can operate i n two configurations:  1. Independent configuration; the stations communicate directly to each other, so there is no infra-structure need to be installed. T h a t is why we called this "ad-hoc" networks. It ,is easy to operate, but the disadvantage is that the coverage area is limited. Stations i n such configuration are i n a Basic Service Set (BSS). W i t h o u t the E S S the stations operate i n an Independent B S S (IBSS). 2. Infra-structure configuration; the stations communicate to Access points which are part of a D i s t r i b u t i o n System. A n Access point serves the stations in a B S S T h e set of BSSs are called Extended Service Set (ESS). Note that 802.11 only specifies the air-interface, that is the interface between stations  15  and between stations and Access points.  W i t h a D i s t r i b u t i o n system, the  coverage area can be extended to whatever the internals of the distribution system for instance w i t h bridged wired L A N s . T h e standard provides the above mentioned services w i t h the following functionality: roaming w i t h i n a E S S , multiple data rates i n BSSs and Power Management (stations can switch off their transceivers to conserve power). T h e M A C protocol is Carrier Sense M u l t i p l e Access w i t h Collision Avoidance ( C S M A / C A ) . T h e standard includes a formal description of the M A C protocol using the S D L method standardized by the International Telecommunications U n i o n , Section Telecommunication ( I T U - T , formerly C C I T T ) T h e standard provides 2 Physical layer specifications for radio, operating i n the 2 400 - 2 483.5 M H z band (depends on local regulations) and one for infrared.  *  ; .  •  F r e q u e n c y H o p p i n g S p r e a d S p e c t r u m R a d i o P H Y . T h i s P H Y provides for 1 M b i t / s (with 2 M b i t / s optional) operation. T h e 1 M b i t / s version uses 2 level Gaussian Frequency Shift K e y i n g ( G F S K ) modulation and the 2 M b i t / s version uses 4 level G F S K . Direct Sequence Spread Spectrum R a d i o P H Y . T h i s P H Y provides b o t h 1 and 2 M b i t / s operation.  T h e 1 M b i t / s version uses Differential  B i n a r y Phase Shift K e y i n g ( D B P S K ) and the 2 M b i t / s version uses Differential Quadrature Phase Shift K e y i n g ( D Q P S K ) .  I n f r a r e d P H Y . T h i s P H Y provides 1 M b i t / s w i t h optional 2 M b i t / s . The 1 M b i t / s version uses Pulse Position M o d u l a t i o n w i t h 16 positions ( 1 6 - P P M ) and the 2 M b i t / s version uses 4 - P P M . E a c h P H Y specification includes state diagrams to formally describe the protocols.  16  2.6  GPRS Technology  G P R S (General Packet Radio Service) uses the bursty nature of voice traffic to make use of the physical channels of G S M for its packet traffic. A l t h o u g h it uses the same physical channels, G P R S uses new logical radio channels for its packet data traffic. It uses G S M network for operation. F i g . 2.8 shows the G P R S architecture i n the G S M network.  Mobile Host  INTERNET SGSN  3GSN GTP  LAN  Figure 2.8: G P R S Network Architecture  T h e Mobile Host ( M H ) accesses the G P R S network v i a the Base Station. T h e Packet Control U n i t ( P C U ) is a hardware upgrade for the G P R S to be used in the G S M . T w o service nodes are defined i n G P R S - serving G P R S support node ( S G S N ) and gateway G P R S support node ( G G S N ) . T h e G G S N acts as an interface to public networks like the Internet and contains the routing information to be used to tunnel packets from the Mobile Host through the S G S N . T h e S G S N are i n charge of one or more Base station and they do location management through the H L R and V L R and are responsible for the delivery of packets. T h e G G S N determines which M o b i l e Host the packet belongs to and the packet is forwarded to the S G S N to be delivered to the Mobile Host ( M H ) . F i g . 2.8 shows the generalized architecture of GPRS.  17  Chapter 3  A Remotely Controlled Bluetooth Enabled Environment 3.1  Introduction  Bluetooth [1],[2],[3],[4] technology's popularity is due to its low-cost, low power radio technology and operation i n the I S M band. Bluetooth devices form an ad-hoc network called piconet, provided the devices are w i t h i n the communication range (10m - 100m). A Piconet has one master and a m a x i m u m of seven slaves and the master-slave communication is based on time-division duplex mechanism. T h e master allocates the transmission slots and these slots are then used alternatively by master and slave to transmit Bluetooth frames.  Bluetooth technology employs frequency hopping, to allow for concurrent Bluetooth communications w i t h i n radio range of each other without perceptible i n terference. M u l t i p l e piconets can, thereby, coexist which can then be inter-networked. Such a system of networked piconets is called a Scatternet. A device participating in two piconets is said to form a "bridge" between them. These bridge nodes are used for communication between different piconets i n a Scatternet.  18  In this chapter, we present a simple Scatternet formation algorithm as compared to a distributed scheduling algorithm described i n [26].  Application (Remote Control) Transport Layer (TCP) IP Backbone  Access Point (Primary Master MI)  Local Bluetooth Scatternet (Bluetooth Enabled Environment)  Figure 3.1: T h e architecture of the B l u e t o o t h Remote control environment  3.2  Related Work  Earlier works i n remote control of applications include controlling a video conferencing application [27] and providing a framework for controlling.lights and stereo components [28]. In C M U ' s Pebbles project, a P D A is used to control a single P C ' s screen and various P C applications, such as PowerPoint, and Web browser [29]. However, we are focusing on controlling multiple device outputs. Also, user interaction w i t h multiple devices and sensors i n a room is being investigated i n Stanford's Interactive Workspaces project [30]. T h e y have proposed multi-device user interfaces i n which a user can "pick" an object from a P D A and "drop" it on a P C screen or digital whiteboard [31]. In our work, we are focusing on the Web, and enabling a web page to simultaneously control multiple Bluetooth enabled devices.  19  3.3  Architecture of Remotely Controlled Bluetooth Enabled Environment (RCBTEE) Master connected to thein,tarnet  B l u e t o o t h enabled, s l a v e d e v i c e s  (e. g. microwave ovens)  Figure 3.2: Piconet formation T h e bluetooth specifications specify OSI layer 1 (baseband radio) and O S I layer 2(connection set-up, link management). So we implement the R C B T E E i n O S I layer 3 as a middleware. F i g 3.1 shows the architecture of the Bluetooth Remote control environment. The Bluetooth scatternet is formed on top of the I P Backbone. F i g 3.2 shows Piconet formation i n the R C B T E E Architecture. The Master device connected to the Internet and communicating w i t h a webserver.  F i g 3.3 shows  Scatternet formation w i t h multiple piconets. A Master connected to the Internet and piconets are interconnected v i a slave bridges. F i g 3.4 shows A tree structured Scatternet like the R C B T E E formation topology.  3.4  Scatternet Formation Algorithm  We devised a simple scatternet formation algorithm so that the range of the control of Bluetooth devices can be maximized. O u r m a i n focus was to have at least one Bluetooth enabled device to act as a bridge to overcome the 10-metre radius barrier.  20  Internet  Connected to the Internet slaved  , •* slave 6  isfprP""  slave 4  (bridge):  "*. /  primary • master  f m * slave*  Figure 3.3: Scatternet formation w i t h multiple piconets. T h e proposed algorithm employs only local'information and can adapt to changes such as arrival and departure of nodes.  O n activation, the devices can issue a  page/inquiry to the master or go into inquiry scan state and wait to be discovered by the master by matching w i t h the frequency hop of the master device.  The  Inquiry Procedure systematically scans all 32 Inquiry channels i n order to discover other devices. A target detects an Inquiry while performing an Inquiry and its Scan executes an Inquiry Response. In this way, one by one B l u e t o o t h device connects to the master and forms the piconet. T h e scatternet formation algorithm is devised and implemented as follows: F i g 3.5 shows M I (Access point) is initialized. F i g 3.6 shows M I performs I N Q U I R Y procedure to discover devices i n the neighborhood. F i g 3.7 shows the case when M I discovers devices and forms the piconet, other B l u e t o o t h devices i n the neighborhood are alternating between Master and Slave mode. F i g . 3.8 shows some devices i n the neighborhood assume the role of Master and begin I N Q U I R Y , other devices perform I N Q U I R Y S C A N . Fig.3.9 shows the case when Piconets join w i t h the piconet formed by M I through slave bridge. F i g . 3.10 shows all the devices i n  21  22  BTJNode  (O) BT Access point (Ml) O BT Slave • BT Master  Figure 3.5: RCBTEE Step 1  Figure 3.6: RCBTEE Step 2  Figure 3.7: R C B T E E Step 3  Figure 3.8: R C B T E E Step 4  24  Figure 3.9: R C B T E E Step 5  Figure 3.10: R C B T E E Step 6 Let M I be the Master connected to the internet, undis is a device still not discovered by the scatternet, M L and S L are the master list and slave list respectively, which are maintained at the webserver.  25  D o W h i l e M I is connected  1. Initialize (MI); M I performs I N Q U I R Y procedure. 2. B l u e t o o t h device e M L U S L performs I N Q U I R Y S C A N periodically waiting to be discovered by new device nd (every 1.28s over a windows of 11.25 ms). 3. For any new device n d e undis nd performs I N Q U I R Y if n d < D of M L (where D = 10m, range of Bluetooth devices [1]) then connect to mj 6 M L else if n d < D of Sj S S L then connect to Sj as new Master m^ where Sj is Slave Bridge  MLi+i <= M L j U mi else nd goes to U N C O N N E C T E D 4. m i G M L performs M A I N T A I N E N C E and U P D A T E  26  UPDATE: V m 3 M L sends V s G piconet (m) messages: Master list, number of masters connected, request for parameter update. UNCONNECTED: nd goes to power save mode and performs I N Q U I R Y after certain interval. A s recommended i n specification [1], some randomization is introduced to the intervals between any two inquiries. M A I N T A I N E N C E In case of any node arbitrarily leaving the network (i.e. maybe switched off): If node was a slave, master sends message to M I . If node was a master, all slaves connected to it does step 3 of the algorithm. If node was a bridge slave, master performs I N Q U I R Y to find other slaves to use as a bridge. D A T A tuple: <message-type, message-id, source, destination, data>, message type can be data, control or broadcast. If two or more Bluetooth devices come into a piconet simultaneously, they w i l l connect to the master one by one based on success of I N Q U I R Y . In case the master fulfils its quota of 7 slaves after connected on device, the^second device w i l l form a master, connected to the piconet master by a slave bridge. In this case the bridge is chosen when the device acts as a master and performs I N Q U I R Y and discovers the first slave, device.  A n important issue is how slave devices know the direction and the nodes on the way to the p r i m a r y master and how to avoid loops;  A slave node connects to a piconet master, and sends messages to the p i -  27  conet master. T h e piconet master i n turn sends and forwards messages (with a T T L = M + l , where M is number of master devices i n the scatternet) only to the slaves which are bridge slaves. T h e bridge slaves i n t u r n forward messages to their masters and i n this way the message reaches the primary master connected to the internet. F l o o d i n g is avoided by the T T L assigned to messages at their origin.  A scatternet formation algorithm has two important performance measures: time complexity and communication complexity.  T i m e complexity is defined as the amount of time to form a scatternet. O u r algorithm is designed to work i n such an environment that nodes arrive and leave i n an incremental fashion. Instead of presenting the total amount of time used for the whole scatternet formation, we analyze the delay for a new node to connect to the scatternet successfully, which implies the waiting time for a node to join a scatternet.  F i r s t l y we consider the link formation delay Tamn- T h e link formation delay components include the inquiry procedure delay T  q  Tp: T^conn  =  and the paging procedure delay  Tg + Tp (1)  Inquiry procedure delay T q is given by [32]: T<j  =  2tT y S  where T  nc  sync  -f- Tj-;,  (2)  refers to Frequency Synchronization delay and T ; , refers to R a n d o m r  Backoff delay.  N o w consider the connection delay for a new node to join the scatternet. Assume that w i t h i n the node's radio range there exits a master or slave and thus the new node could receive at least one response from the neighbor nodes at its first round Inquiry. Ignoring the paging delay T  p  because it is typically much less than  Inquiry delay T , we can approximate the connection delay T g  28  c  using the following  equation:  Tc — Tu, + 2 T y S  n c  -|- T j (3) r  where T„, denote the amount of time consumed by the new node to discover a neighbor node that it decides to connect to. G i v e n Inquiry timer set to 10.24s i n our algorithm, T  w  and  T f, r  where  is a variable that ranges fromO tol0.24s. According to [32], T  are uniform random variables i n [0,  Tcoverage  T  c o v e r a g e  ]  s y n c  and [0, rmax] respectively,  is 10ms (20ms) for the 16 (32) hop system, and r m a x is 639.375ms.  Thus the m a x i m u m connection delay for a new node could be 10.24s + 659.375ms = 10.899375s for the 32-hop system. Such a delay can be accepted by non time-critical applications.  If a new node could not discover any neighbor nodes present i n the scatternet during the 10.24s Inquiry procedure, it w i l l give up and t r y later.  Communication complexity is the number of messages sent between the devices. Since B l u e t o o t h devices are usually small and low powered, minimizing the number of message sent would be significant for Bluetooth devices. Messages used in scatternet formation process can be categorized into two groups: 1. Messages used by link establishment between two devices, i.e. packets sent during Inquiry and Page procedures. 2. A l g o r i t h m i c messages - messages used by the scatternet formation algorithm. In our algorithm, we employ asymmetric method for link formation, that is, inquiry or scan role of the node is pre-assigned. Since a node who performs Inquiry w i l l become a master later, a newcomer would always become a master node even i f it were t r y i n g to connect w i t h a master.  29  A c t u a l l y this is undesirable.  T o solve  this problem, our algorithm employs Master/Slave role switching i n this case, which inevitably introduces overhead message exchange between two nodes.  Moreover  algorithm messages also include the message sent when the algorithm is managing to adapt to the topology changes caused by the movement of nodes. Compared w i t h some complex algorithms [33] which involve operations for optimization of scatternet topology, our simple scatternet formation has a very low communication complexity.  3.5  Simulation and Analysis of the Bluetooth Environment (RCBTEE)  Our algorithm implemented i n the R C B T E E is designed to work i n such a dynamic environment that nodes arrive and leave i n incremental fashion. To make it efficient as well as simple, the inquiry or scan role of the node is pre-assigned, that is, each new node coming to the scene would perform Inquiry, and all the member nodes of the scatternet perform Inquiry Scan periodically.  Java simulations were performed to demonstrate the feasibility of the proposed scatternet formation algorithm under the desired scenarios.  Once a piconet or a scatternet around the primary master connected to the web server is formed, the Bluetooth participants of the formed piconet/scatternet can rely on it to communicate w i t h the primary master. For these participants of the scatternet, the primary master performs like a gateway to the Internet, through whnich a remote control of local Bluetooth devices from the other side of the Internet could be realized. Another desired function for the primary master is locally controlling of the Bluetooth devices. To offer such services, primary master should have a exact connectivity list of the whole scatternet and maintain some state information in its memory for each local Bluetooth device.  30  Figure 3.11: R C B T E E Scatternet Simulation Fig.  3.11 shows Interactive simulation of Scatternet formation.  Circular  radius shows the range of each master, labeled as " M " ; slaves are labeled as " S " . Unlabelled dots are devices not connected into any piconets or scatternets.  Since a master node has information about a l l slave nodes i n its piconets, it would be responsible for sending the required information, such as the list of its connected slaves and its slaves' address, to the primary master connected to the Internet. W h e n the primary master receives information packets from a master i n the scatternet, it w i l l update corresponding data i n its memory at once. In case of any arrival or departure of nodes, the scatternet w i l l reform again according to our algorithm. T h e masters that have new nodes add to or delete from their piconets should update its connectivity list and send the update to the primary master. A n d the new selected masters during scatternet reforming process should also report their lists to the primary master. Thus the primary master w i l l have a global view of the scatternet and always hold up-to-date information of the Bluetooth devices present i n the scatternet.  31  Another issue should be addressed for our local scatternet and primary master architecture is data routing between primary master and local B l u e t o o t h devices. We employ a method similar to source-initiated on demand routing. Whenever a node i n the scatternet desires to communicate w i t h the primary master connected to the Internet, or vice versa, the source node creates a route to the destination on a demand basis. Once a route has been created, it is maintained u n t i l the destination becomes inaccessible along the path from the source or until the route is no longer needed. T h e primary advantage of this method is that nodes that are not on the selected path do not need to maintain routing information or participate i n routing message exchanges. It is particularly significant for Bluetooth devices w i t h power constraint and limited memory.  T h e master and each slave devices exist as threads. T h e state and parameters of each device are stored i n a buffer (implemented as a A S C I I text file) i n the web site. A server is kept running i n the web site, the home device connected to the internet and the web page updates are reflected on the buffer files.  A real-time update function updates any changes made to the home device or on the web page directly to the buffer files. T h e Home devices and the web page are then instantly updated from the buffer files. T h e update function only works on the webserver and the Master node connected to the Internet only when some change occurs onsite or i n the remote control page(Fig. 3.12). Hence the overhead due to updates is negligible since it does not congest the Bluetooth scatternet. A n encrypted password protection security feature is added to the web site to make it less vulnerable to misuse. Bluetooth's own protection mechanism protects the scatternet from any intruding Bluetooth enabled device from entering the scatternet. O n entering the password, the web page is instantly updated and shows the current state of the devices. Since the file updates are immediate, the probability of deadlock  32  due to multiple writes is negligibly small. Moreover, i n case of contention between onsite change of device state, and remote change request, priority is given to onsite change to avoid any deadlock or system crash.  i,  Enter Password  ON  Secu-ity  ON  Ughtirjg  It =" :  :  Password  Microwatt;  ON  . • computer  ON ON  MUSIC  DcsrLoiw  ON •  Window  ON  Bluetooth Enabled Calces control panel  BliiiBH  Figure 3.12: R C B T E E Remote Control Centre  Figure 3.13: R C B T E E Scenario  33  Table 3.1: Comparison of R C B T E E w i t h other B l u e t o o t h Scatternet algorithms A l g o r i t h m M a x . N o . A l l nodes w i t h i n communi- Support of Structure of nodes cation range of each other D y n a m i c Join [RCBTEE] No Limit Yes Yes Tree [BTCP] 36 Yes No Mesh [Bluetree] No Limit No No Tree [Bluenet] No Limit No No Mesh [LS01] No Limit Yes Yes Mesh [Bluerings] Less than Yes No Ring 40  3.6  Applications for R C B T E E  1. To remotely control home equipments, like set the microwave O N when returning home from office. F i g . 3.12 shoy/s the Remote B l u e t o o t h control centre web page. T h e web page is password protected. T h e web page allows users to remotely control the devices. 2. To remotely control office equipments.  F i g . 3.13 shows A typical scenario  of Bluetooth enabled home/office environment. Devices are connected to the master Laptop, connected to the Internet. 3. To know the status of equipments from the values of the webpage form. 4. Limitless applications on safety control. 5. Applications on process monitoring and control. 6. To give processing power to any electronic devices which are B l u e t o o t h enabled. For example a lighting system connected to the system mentioned i n R C B T E E can be given processing power, w i t h all processing done at the Internet based on the data input from the device parameters. T h e lighting system can be switched on and off depending on the time of the day.  34  7. Remote C o n t r o l of B T devices is an interesting B T and Internet application for pervasive computing and t h i n computing.  3.7  Discussions  A new prototype system is simulated for home/office networking w i t h Bluetooth enabled devices. T h e primary contribution of this system is to economically have a remote control system for home/office devices arranged i n a wireless network. T h e Scatternet algorithm presented compares well w i t h current Scatternet algorithms(Table 3.1) and shows some improvement over many algorithms.The status of the devices i n the network can be monitored by a remote web page, which can be viewed by any computer connected to the Internet. Also the devices i n the network can be controlled e.g. switched on/off, given certain inputs remotely v i a the web page. T h e possibilities and applications of such a system are tremendous.  Future work w i l l be to port the web page enable it to be opened i n any Mobile phone and thus control the B l u e t o o t h devices even from a W A P enabled mobile phone which runs J 2 M E . Also future work remains to add more functionality to the devices being controlled like adding some amount of processing power based on the input parameters. Another future direction w i l l be to m i x wireless cell phone activity (i.e. wirelessly tethered until disconnect) w i t h Bluetooth Scatternets. We also want to look at M o b i l i t y handoff as a device leaves one piconet and enters another.  35  Chapter 4  EquiBlue: A Load Balanced Scatternet formation algorithm. 4.1  Introduction  M o b i l e A d H o c Networks ( M A N E T ) using B l u e t o o t h technology has gained i m mense popularity w i t h more and more devices fitted w i t h Bluetooth. T h e M A N E T formed by B l u e t o o t h is also known as Scatternet.  It consists of connection of a  Master device with. a. few (upto 7[1]) slaves known as a piconet. Some Scatternet formation rules laid down by earlier research work [33],[9],[19] are:  1. Node type constraint: E a c h node is either a Master or a Slave, a subset of slave nodes may act as shared bridge nodes. 2. Connectivity constraints: T w o slaves cannot be connected directly [9], and two Masters should not be connected directly [19]. 3. Bridge node constraint : A bridge node must connect only two piconets [9]. 4. A bridge node must not be a Master i n any piconet i n which it is active. 5. T h e resulting Scatternet should be fully connected [33],[9],[19]. 36  In this Chapter we present a novel load balanced Access point aware B l u e t o o t h Scatternet formation protocol. F i g . 4.1 shows a M e s h structured Scatternet, as formed by the E q u i B l u e A l g o r i t h m .  Figure 4.1: M e s h Structured Scatternet  37  4.2  Related Work  In [46] we proposed a Bluetooth algorithm for a simple Scatternet formation w i t h the ability to be controlled remotely.  B T C P [19] has a two phase Scatternet formation protocol. In the first phase a coordinator is elected among the nodes and it has all the information about the other participating nodes. In the second phase the leader makes a decision about the role of each device and conveys the information to the devices. Masters P A G E the slaves which are i n the connectivity list provided by the leader and the Scatternet is formed.  Law et. al. [33], [25] propose a one phase Scatternet formation algorithm which first partitions the network into independent piconets and then elects a super master which knows about the nodes. Devices alternate probabilistically between Seek and Scan states and get the role of a Seeker or a Scanner.  Devices try to  merge(), migrate() or move() depending on the how many devices it has under the scanning device and how many slaves are made collectively (both seek and scan). W h e n a leader u running S E E K connects to a slave v running S C A N , procedure ConnectedQ is called. If v's other master is w, the piconets of u and w w i l l try to merge if possible. T h e possibility depends on whether the piconets of u and w can be accommodated i n a single piconet, then w and its devices become slaves i n the piconet of u . T h i s procedure is performed by MergeQ function. Otherwise, some slaves are moved from u to w piconet by the procedure Migrate(). A l l the communication between u and w i n Connected(), Merge(), Migrate() and Move() are v i a their common slave v.  Bluetrees [36] form a hierarchical tree structure. A n inquiry procedure is run by each device which knows about the identifier to its one-hop neighbors, before  38  the protocol for connecting devices begins. A t this stage, one node is assumed as a root. After designating a node as root, the protocol starts w i t h the root sending page messages to a l l its neighbors t r y i n g to connect. T h e connected nodes are now the slaves of the root (master) piconet. T h e loop continues w i t h the slaves, thus formed, connecting to their neighbors which form the slaves for the paging devices. T h e paging continues until the leaves of the tree are formed. T h e intermediate devices i n the final tree excluding the root and leaves act as master- cum-slaves i n two different piconets. Distributed Blue Trees is proposed as an extension to the Bluetrees [36]. In the second step where a node is chosen as a root, distributed Bluetrees chooses many nodes as roots. E a c h roots forming its own tree which i n the final step gets connected as scatternet.  Bluenet [35] algorithm employs three-phases to construct a Scatternet i n a distributed way, there is no designated root node and it can be carried out at each node, based only on the local knowledge of the node's neighbor.  Bluenet's  network is a flatter structure compared to the one formed by BlueTrees algorithm. Bluenet tries to spread the network resources as evenly as possible through out the scatternet so as to prevent communication bottlenecks. T h e concept of visibility graph is introduced i n this paper. In phase 1 of the Bluenet algorithm, a visibility graph is formed by every device collecting the information about neighboring devices in the inquiry state. Later each device pages its neighbors randomly. B y the end of phase 1, individual piconets are formed. In phase 2, each node now does I N Q U I R Y procedure again t r y i n g to connect to another device. If any device gets connected to more than one node, it then acts as bridge node. Phase 3 is used to form a connected Scatternet. A n d at the end of phase 3, a connected network is formed w i t h master informing slaves to open outgoing links. T h e disadvantages of this algorithm are that a device has to inquire twice i n order to connect to the entire set of devices, and addition of nodes into the existing structure is difficult.  39  4.3  EquiBlue Algorithm  The EquiBlue Algorithm is schematically shown in the next few pages. Fig. 4.2 shows the Access point calling S E E K and starting INQUIRY procedure. Fig. 4.3 shows other nodes perform the biased probability function to determine whether they enter INQUIRY or INQUIRY S C A N . The biased probability function calculates probability based on a random function and the weight of the device(weight symbolizes the processing power, hence higher processing power devices have a higher weight value). Connection Window of device is set at this stage. Connection window of a Master device is the number of active slaves it currently has in its piconet. Fig. 4.4 shows devices which are determined to perform INQUIRY, start the procedure to determine devices in its range to form a piconet. Fig. 4.5 shows Master's form piconets, they connect with bridge slaves to other piconets. Maximum No. of bridge slaves is one for two neighboring piconets. Fig. 4.6 shows that in the first phase, Scatternet is formed. Fig. 4.7 shows that in the Scatternet, Masters send slavelist to neighboring Masters, in case of disparity in the number of slaves between the two neighboring piconets, Masters with more slaves will disconnect slaves if it is in radio range of neighboring Master. Fig. 4.8 shows Neighboring Master connects to the disconnected slave by P A G E message, since it already got the frequency and address information from the neighboring Master, thus avoiding the time expensive INQUIRY procedure.  40  Figure 4.2: E q u i B l u e Step 1  Figure 4.3: E q u i B l u e Step 2  41  Figure 4.4: E q u i B l u e Step 3  Figure 4.5: E q u i B l u e Step 4  42  Figure 4.6: EquiBlue Step 5  Figure 4.7: EquiBlue Step 6  43  Figure 4.8: E q u i B l u e Step 7 In this section we present our load balanced Scatternet formation algorithm. T h e n we evaluate its performance at a later section. L o a d Balanced Scatternet formation Algorithm:  1. Nodes form master and slave based on a biased probability and weight. T h e biased probability function calculates probability based on a random function and the weight of the device(weight symbolizes the processing power, hence higher processing power devices have a higher weight value). Connection wind o w ( C O N W I N ) of a Master device is the number of active slaves it currently has i n its piconet. Device calls Seek when P r o b a b i l i t y > 0.4 & weight > 50 or P r o b a b i l i t y < 0.4 & weight < 50 Else device calls Scan. Access point always calls Seek.  Set C O N N E C T I O N . W I N D O W of Master proportional to weight of the device. 44  Heavyweight device: C O N W I N = 5 Lightweight device: C O N W I N = 3  2. After connection: If Master reaches C O N W I N , It sends R E F U S E message to Scanning slave U n t i l p retries A n d sends address of slave and C O N W I N to neighbor Masters through bridge slaves. • 3. If Master has finished p retries or C O N W I N of neighbor <> C O N W I N + / - 1 then C O N W I N = C O N W I N  +1  If C O N W I N of neighbor Master <> + / - 2 then C O N W I N = C O N W I N -1 Disconnect an unshared slave 4. If Master receives an address of Slave that neighbor-Master has refused or send D I S C O N N E C T to then, Master w i l l send P A G E message to Slave 5. If Undiscovered Slave or Undiscovered Master then perform step 1 w i t h changed Master/Slave state. Our L o a d balanced scatternet formation protocol can also work w i t h dynamic environments when devices join and leave the scatternet.  W h e n a new device wants to join the scatternet, it performs the biased master-slave selection of step 1 and does step 2-4 to discover other neighboring devices and join to them.  45  W h e n a unshared slave leaves the scatternet, the Master under whose p i conet the slave was connected, knows about the disconnected slave during a polling attempt and updates its slavelist and routing tables.  W h e n a shared slave leaves the piconet, b o t h Master's send P A G E message to their slaves w i t h the address and clock information of the other Master. The slaves perform P A G E S C A N and the first slave to connect to the other Master forms the shared slave. T h e other slaves t r y i n g to connect are send a R E F U S E message.  W h e n a Master device leaves the scatternet, a l l its connected slaves know about the disconnected status when their polling attempt fails. T h e slaves perform a P A G E S C A N (since the retired Master had given its neighborMaster address and clock information to its slaves. T h e Neighbour Master tries to connect to the disconnected slaves by P A G E (skipping the time expensive I N Q U I R Y ) . In case the slavelist of the Master is > 7, then the Master 'parks' some of its slaves and connects the slaves. It then sends the extra (more than 7) slave addresses to its neighbor Masters. T h e neighbor Masters try to connect to the slaves by P A G E . A s soon as the neighbor Master connects to the slave, the previous Master disconnects the slave and 'unparks' some of its parked slaves.  We do our time complexity and message complexity analysis similar to [9] and find that our algorithm has 0 ( l o g n) time complexity and O ( n ) message complexity.  4.4  Simulation Results and Analysis  In this section, we present the results of our simulation using Simjava [34], a discrete event based simulation package for Java. T h i s allowed the use of object oriented programming making each node its own entity, running on a separate thread. S i m java[34] was used to simulate the sending and receiving of messages between nodes 46  during discrete time intervals. Fig. 4.9 shows a snapshot of the Load balanced Access point aware Scatternet formation algorithm simulated in Simjava.  Figure 4.9: EquiBlue Simulation Simjava is quite a versatile tool. It is used to simulate an environment in which many objects, nodes in this case, frequently interact by sending messages to one another. Nodes are linked together by ports. These ports allow messages to be sent between connected nodes. The nodes in the environment derive from an entity class specified by Simjava. Deriving from the entity class makes each node have its own thread. A central system class is responsible for controlling the threads. This centralized system class also controls simulation time and delivers messages as appropriate to each node. It is aware of each node and can signal termination of the simulation.  The behavior of each node is implemented within the class that derives from the entity class. Simjava provides many useful actions that allow ease in implementation. Simply executing through a loop each time interval, each node performs  47  actions and changes state as necessary.  Nodes can wait for a specified amount of  simulation time, check for messages waiting, and send messages instantaneously or w i t h a delay. T h i s gives an excellent framework for communication between nodes. In combination w i t h the implemented node behavior, this framework allowed the simulation of the Scatternet formation algorithm.  A nodeGenerator class generates randomly device co-ordinates, device I D , weight (representing processing power) and device clock. A Node class handles the functionality of B l u e t o o t h nodes, it contains device states, logic for alternating between master and slave, message queues, slavelist, masterlist and neighbormasterlist, timing information and most of the logic needed for the simulation of the node as a Bluetooth node and implementing the E q u i B l u e algorithm. A Matcher class simulates lower level link control protocols. A Message class acts as a wrapper between information send between the nodes and between the node and the Matcher class. A n I n i t S i m M s g class is used to send the initial message from the Matcher to the nodes. Classes BlueFrame and B l u e D r a w are used to visually draw the workings of the Scatternet simulated as the algorithm proceeds.  20  30  40  50  60  70  80  90 100 110 120  Number of Devices  Figure 4.10: Total Number of Piconets V s N u m b e r of Nodes Our results are the averages of 10 trials for upto 120 devices. We plotted the  48  0  20 30 40 90 CO 70 80 SO 100 110 120 Nu rn be r of Devices  Figure 4.11: Scatternet Diameter Vs Number of Nodes  V" o ?  3  -  20  30 40  50  60  70  80  90 100 110 120  Number of Devices  Figure 4.12: Mean number of nodes per piconet Vs Number of Nodes results for an area of 30 X 30 metres, 40 X 40 metres, 50 X 50 metres.  Fig. 4.9 shows a snapshot of the load-balanced access point aware scatternet formation algorithm simulation. The M denotes Master, S denotes slave and A P denotes access points. The device ID is given after the ( M / S / A P ) label.  Fig. 4.10 show the number of piconets are rising linearly with linear increase of number of nodes. The number of piconets increase as the area increases for the same number of nodes, this ensures that the piconet size is kept even at the cost of 49  1 3 5 7 9 11 13 15 17 19 21 23 25 Number of Piconets  27 29  Figure 4.13: Variation in the mean number of piconets as the number of piconets increases  Number of Nod**  Figure 4.14: The total Inquiry messages send in the algorithm the number of piconets to achieve a load balance.  Fig. 4.11 shows that the number of hops from end to end (scatternet diameter) increases linearly. The Scatternet diameter increases for a larger area with the same number of nodes. The Scatternet diameter is below 20 even for 120 devices.  Fig. 4.12 shows that the number of devices per piconet is between 4 and 5. This verifies our load balanced scatternet algorithm since it works effectively to balance out the load between the piconets so that the difference in slave devices is not very large between piconets.  50  20 3D 40 50 60 70 80 90 100 110 120 number of Modes  Figure 4.15: The total Page messages send in the algorithm  20 30 40 A O 80 70 80 90 100 110 120  Figure 4.16: The total Algorithmic messages send in the algorithm Fig 4.13 shows a flat trend in the mean number of piconets as the number of piconets increase. This implies that as the number of piconets increase the network load is balanced evenly among the piconets between 4 to 5 devices per piconet.  Fig 4.14 shows the total number of Inquiry messages send as the number of nodes increases. The number of Inquiry messages increases as the area increases, since it means more piconets are formed and hence some of the Inquiry messages are rejected as the slave responds to one or two masters depending whether it is an unshared slave or a shared slave.  Fig 4.15 shows the total number of P A G E messages send increase linearly as the number of nodes increases.  51  F i g 4.16 shows the total number of algorithmic messages send increase linearly as the. number of nodes increases. M o r e algorithmic messages are send when the are of operation increases, since more piconets are formed and hence more interpiconet messages have to be send to achieve the load balance mechanism.  4.5  Discussions  Algorithm  Max. No. of nodes  A l l nodes within communication range of each other  [EquiBlue] [BTCP] [Bluetree] [Bluenet] [LS01] [Bluerings]  No Limit 36 No Limit No Limit No Limit Less than 40  Yes Yes No No Yes Yes  Support of Dynamic Join Yes No No No Yes No  Structure  Mesh Mesh Tree Mesh Mesh Ring  Table 4.1: Comparison of E q u i B l u e w i t h other Scatternet Algorithms  In this Chapter we introduced a load balanced B l u e t o o t h Scatternet formation algorithm named E q u i B l u e . We described the algorithm i n detail and d i d a simulation i n a Java based discrete event simulator named Simjava[34]. We took numerous performance metrics using our simulation and showed that the E q u i B l u e algorithm achieves a good performance i n equalizing the number of nodes per p i conet. We compared our algorithm w i t h numerous other Scatternet formation algorithms shown i n Table 4.1. O u r results are comparable to the results given i n [25] while still achieving a good load balance factor. T w o contributions of E q u i B l u e are achieving a load balanced Scatternet (where each piconet would not differ w i t h other piconets by more than one or two devices), and biasing the Master/Slave role selection so that higher processing power devices get the role of Master. T h i s would be very efficient i n applications where" a repository is kept on the Master or the Master offers a service and hence needs higher processing power.  52  Chapter 5  Blue-Fi : A Convergence Architecture for B l u e t o o t h 802.11 wireless 5.1  and  networks  Introduction  Bluetooth [1], [3] 1.1 specification grew to include the formation of Personal A r e a Networks ( P A N s ) which is narrower i n scope of operation t h a n W L A N . T h e standardization of P A N s is carried is being carried out by the 802.15 working group [21]. The  I E E E 802.11 standard [23], [22] for W L A N s is the most widely used W L A N  standard today. Co-existence between B l u e t o o t h and 802.11 is a hot topic for research since b o t h technologies have advantages and disadvantages. Co-existence of both seems to be the trend of the near future.  In this chapter we present a novel architecture for a hybrid Bluetooth- 802.11 access point and algorithms for interoperability of B l u e t o o t h and 802.11 on a software switching level. In section 5.2 we discuss some relevant research on interoperability i n hybrid networks. In section 5.3 we propose algorithms for a hybrid network  53  consisting of B l u e t o o t h and 802.11 devices. We analyse the handoff latency i n our proposed protocol i n section 5.4. We investigate Co-existence issues of Bluetooth w i t h 802.11 i n section 5.5. In section 5.6 we conclude w i t h some discussions and directions for future work on this subject.  5.2  Related Work  K a n s a l et al. [14] introduce a Handoff scheme for B l u e t o o t h devices to allow mobility of devices i n B l u e t o o t h public access ( B l u e P A C ) environments. B a a t z et al. [17] concentrates on handoff support for mobility w i t h I P over Bluetooth. Perkins et al. [16] present a handoff scheme for mobile I P ' s .  T h e paper by M i s h r a et al. [11] does a thorough analysis of the handoff procedure i n the 802.11 M A C layer. K a s t e l l et al. [12] presents security issues involved i n hybrid handover procedures. Pack et al. [15] uses a predictive authentication for fast handoff's i n 802.Ix mode.  5.3  BlueFi Handoff Algorithm  In our hybrid Bluetooth/802.11 network we have access points that have both the Bluetooth and 802.11 antennae and physical interfacing devices/network cards. T h e devices can access the backbone 802.11 network resources either through the "802.11 A P - 802.11 Client" interface or through " B l u e t o o t h ( B T ) A P - Bluetooth Client" i n :  terface. W h e n the client uses its B l u e t o o t h interface, the Access Point ( A P ) should be able to forward the B l u e t o o t h packets to the backbone 802.11 network and the incoming packets from the 802.11 to the Bluetooth interface so that they can be passed on to the client. However, when the client uses the 802.11 interface, the packets are directly forwarded to the corresponding 802.11 interface i n the A P and from there to the backbone network.  54  We propose to introduce a handoff algorithm through which the client can switch from one network to the other, either voluntarily (due to his power or bandw i d t h requirements) or because his mobility takes h i m out of the B l u e t o o t h radio range. W h e n this switching of interfaces occurs, the application layer must remain oblivious to this change and a lower software layer must be able to activate the appropriate interface that the client w i l l use. For this purpose, we propose to i n troduce a software engine or daemon which we call layer of software control ( L S C ) in between the T C P / I P and the next lower layer i n the hierarchy ( L L C for 802.11 and P P P or L 2 C A P layer for Bluetooth) that would take care of the switching between the B l u e t o o t h device and the 802.11 device both i n the client as well as at the hybrid Bluetooth/802.11 A P . Conceptually this software engine is common to b o t h the B l u e t o o t h and 802.11 physical interfaces, as shown i n F i g 5.1. T h i s layer traps a l l the outgoing and incoming T C P packets, buffers them appropriately and then releases them to the lower layers of the stack (after deciding which interface to activate) so as to facilitate smooth handoff.  The application layer can directly send commands to L S C daemon. For example, when the user wants to voluntarily switch operation from one network to the other, he w i l l simply send a specific command to L S C , which are implemented as A P I s ' and this w i l l , i n turn, activate that physical interface and divert a l l outgoing T C P / I P packets to it & listen for incoming packets from that interface. In other words, after receiving the commands from the application, it becomes the responsibility of this layer to initiate a manual handoff. In order to facilitate this, L S C must send some direct H C I commands to the B l u e t o o t h physical chip. These direct commands are Get-Address tion), Create-Connection  (for getting P H Y address and C L K informa-  (connect devive and set scan mode),  (set time spent on paging), ReadScan_Enable  55  Write-Page-Timeout  (read device configuration regard-  ing page scan),  WriteS can-Enable  Read-F'age-Scan-Activity  (enable device to enter periodic page scan),  (check page scan parameters),  Write-PageScan-Activity  (set page scan parameters).  4tinHi,Minn lava. TCP  TCP  T Layerof Software Controlfor80illBht«ooiJiHnitdoff (LSC) t RFT'flMM LLC  UCAE  MAC.  Bluetooth Layers  IEEE 802 Protocol Layeis  Figure 5.1: B l u e F i Software Layer Concept Let us take two specific cases of voluntary handoff and a single case of natural forced handoff due to disconnection. A . U s e r is i n the radio range of b o t h 802.11 &: B T and wants to voluntarily switch from his currently running B T communication to 802.11, possibly because he needs a higher bandwidth: 1. T h e L S C layer i n client receives request command from the application layer to switch to 802.11. 2. L S C then sends a control packet destined for the L S C layer i n the Bluetooth A P that this current client is initiating a manual handoff from B T to 802.11. The control packet also contains the physical address of the client machine. 3. Client L S C creates a buffer for the unsent T C P / I P packets during handoff. 56.  4. T h e L S C layer at B l u e t o o t h A P , after receiving the control packet creates a buffer for a l l unsent packets destined for the client address specified i n the control packet and acknowledges the handoff request. T h e acknowledgement packet contains the channel information about the 802.11 A P where the client w i l l listen for beacon frames (passive scanning) or send its probe request (active scanning), once it switches its interface to 802.11. Further, at A P , the address information for a l l such clients who wishes to switch to 802.11 network is kept in an address queue. For each item i n the address queue, there exists a buffer of a l l unsent data packets from A P for that client. 5. W h e n the acknowledgement packet reaches the L S C layer of the client, the client L S C deactivates the Bluetooth interface and activates the 802.11 i n terface.  T h e 802.11 interface searches for available 802.11 A P by the scan  method. Once the connection is established, all the unsent packets destined for the client physical address is sent by the A P . T h e unsent packets at the client are also sent. Reauthentication takes less time as the address of the client seeking handoff had already been sent to the A P previously by the L S C control packet. B . User is in the radio range of b o t h 802.11 and B T and he wants to voluntarily switch from his currently running 802.11-802.11 communication to B l u e t o o t h - B l u e t o o t h communication, possibly because he needs to save power: Similar steps are followed as i n Case A i n steps 1 - 4, as during switchover from B T to 802.11. In step 5, B T interface directly goes to the R 0 page scan mode (skips the time-expensive enquiry mode).Since the B T A P knows about the client address and clock information, it pages the client w i t h these information until the client responds. If the client is not i n radio range of B T , the B T A P w i l l make four page attempts to connect to the B T interface of the client before giving up. T h i s is explained below i n the case when there is a natural handoff from B T to 802.11. 57  After connection is established, a l l the unsent packets destined for the client physical address is sent by the A P , T h e unsent packets by the client are also sent. C . A client running B T connection, moving away from the B T A P so that it no longer lies in its radio range. O u r design allows to seamlessly switch to the 802.11 network so the client does not feel any break in connection.  1. B T A P constantly polls the client when the client is accessing the backbone 802.11 network through B T interface. T h e clients respond to these poll packets. 2. T h e poll packets reach the L S C layer i n both the A P and the client. Polling scheme is round robin, i n which the A P (master) polls each connected B T (slave) device. D a t a requirements may be different for different clients, and the packet duration may be adjusted for this, using single slot packets for slaves w i t h low data rate requirements and multi slot packets of length 3 or 5 for higher data rates. 3. To detect connection loss, the A P keeps a timer and if no reply occurs for the timeout period, Tpoiitimeout, connection is assumed to be broken. A t the mobile too, a similar procedure is followed, to detect loss of connection. A t b o t h the access point and the mobile clients, the timeout value, T utimeout, is po  specified to be equal to the m a x i m u m number of slots that may pass between two successive turns. One poll round'time takes s x 2 x 1 where s is the number of clients (slaves) attached to the A P (master). Assuming s = 7 (can vary from 1 to 7) and 1=5 (maximum), T im t vo  meou  = 70 slots which is the worst case  value. If the A P needs to communicate w i t h more than 7 slaves, it can do so by instructing active slave devices to switch to low power park mode and inviting other parked slaves to become active i n the piconet. T h i s can be repeated to  58  allow a master to serve a large number of slaves. 4. E a c h Bluetooth A P finishes its poll round and checks if the address queue has any pending addresses of clients trying to connect to B T from 802.11. If there is such an element i n the queue, the A P sends a H O L D message to all its connected clients to suspend their connection loss detection timers for a period of T  A P  _p  a 9 e  .  5. B T A P then pages the mobile client using the address and clock information received. The clients resume their connection loss detection p o l l timers either on the expiry of the TAP-Page-, or if the A P sends a regular poll packet before that. TAP -Page is the m a x i m u m time an access point spends on paging for a slave who switches over from 802.11 to B T . A l l incoming data packets for all the B T clients must also be buffered so as to be delivered once the H O L D stage is over which is equal to TAP_p ge-  Since we  a  configure the clients to use the RO page scan mode, each,page t r a i n needs to be attempted only once by the A P , which means that b o t h the trains can be tried out in 32 slots. Four page attempts are made for robustness, leading to TAP_p ge a  equal  to 128 slots, which is 80 milliseconds. Thus, the worst case time required to discover a break i n B T connectivity is T  p o  i  H i m e o u t  + TAP_p e ag  = 70 + 128 slots = 198 slot  time (about 124 milliseconds). Since it is possible that the mobile clients move out of the B T range during the H O L D period, we do the following: as the clients w i l l discover that they are out of range only when the H O L D period is over, they w i l l start scanning for 802.11 A P ' s beacon after the H O L D period. A t the same time, the Bluetooth A P w i l l also discover that the particular client is out of the B T range only after the H O L D stage, i.e. both client and A P discover the switchover at the same time. T h e A P keeps track of the addresses of those Bluetooth clients which are detected as lost & then looks forward for a connection request from the client.  59  W h e n a client moves away from the B T radio range, the loss of connection is detected at the first unsuccessful p o l l attempt because only one poll attempt can occur w i t h i n  T ;/ j po  t  meout  period after a successful poll. Since the round robin p o l l  always occurs w i t h i n this time, live B T - B T connections w i l l be able to refresh the timeout counter before timeout.  Once a p o l l timeout occurs, the L S C at A P immediately forwards the address of this client to the 802.11 interface A P so that when this client connects to 802.11 network, the authentication w i l l take less time. Meanwhile, loss of connection will also be detected by the client due to lack of arrival of the poll packets from the Bluetooth A P after an interval of T utimeoutpo  T h e client w i l l then activate the 802.11  interface and go to the scan mode to discover the closest available 802.11 A P . W h e n the 802.11-802.11 connection gets established, the unsent data packets from either end are sent.  One important consideration is the length of the address queue that we need to keep at b o t h the 802.11 and Bluetooth side. T h e number of elements i n this queue depends on the number of clients that switch between the networks i n a specified time interval. In order to accommodate the fact that the queue can be very large in a region where the clients move very fast or they voluntarily switch network frequently, we follow the following procedure. T h e A P completes one round of polling all the attached clients and then checks to see if the address queue has any elements. If an element exists, it pages that device. T h e A P processes a single element of the queue at a time between each round of polling. This ensures that the existing clients are not kept waiting for indefinite time while the A P pages for new devices. O n the 802.11 side, the A P ' s are discovered by the mobile clients themselves from the beacons and so there does not arise any problem if the address queue is large.  60  Since we cannot modify the existing accepted T C P / I P headers or introduce new header for L S C because that would lead to serious backward incompatibility, we need to device some technique so as to distinguish L S C control packet from ordinary data packets. For this reason, we use the 6 unused bits i n the T C P header between " T C P header length" field and " U R G " flag. W h e n a l l six of these bits are set to 1 (i.e., 111111), this signifies to the remote L S C engine that the packet is a dummy T C P packet sent by the transmitter and contains control information i n the data area of the packet for handoff. A d u m m y T C P packet looks like an ordinary T C P / I P packet, but it is not sent by any client for data transfer. It is generated by the L S C alone & actually contains the following information bits i n the data area that facilitates handoff :-  1. A single bit R Q / R E S denoting whether it's a client request packet or server response packet. W h e n set, this signifies client request. Otherwise its server response. 2. T w o bits H R E Q signify whether a switchover from 802.11 to B l u e t o o t h or vice versa is requested. 00 => Client switching off both its interfaces 01 => 802.11 to B l u e t o o t h switchover is requested. 10 => B l u e t o o t h to 802.11 switchover is requested. 11 => N o t used.  3. Bits (variable) denoting address and clock information of the client. Relevant only when R Q / R E S bit is set. It is used when the client switches over from 802.11 to Bluetooth, i.e., H R E Q bit-is 01. 4. B i t s (variable length, depending on the physical medium used) C H denoting the channel information of the 802.11 A P that w i l l be used by the clients when 61  switching over from B l u e t o o t h to 802.11. It is relevant only when R Q / R E S bit is reset. W h e n the six unused bits of the T C P header is not a l l set, it indicates that the packet is a normal T C P datagram sent by any mobile host for data communication. Table 5.1 shows the A P I ' s that are available w i t h L S C which any application programmer may use to interface his program w i t h L S C for seamless handoff.  5.4  Analysis of the Algorithm  We take up a l l the three cases discussed above one after the other. In each of these cases, we split the total handoff process into three phases, detection, search and execution. API Activate_Bluetooth() Activate_Wlan() Read_current_interface() Send_control() Read_control() Send_control() Send_Hold() Create_buffer()  Description Activates B l u e t o o t h interface Activates 802 interface Returns the current interface Sends control signal to interface Reads control signal to interface Sends control signal to interface Sends H o l d signal to interface Creates local buffer  Acknowledge_request ()  Acks request to interface  Table 5.1: A P I ' s available for the L S C for use Case 1: W h e n the client is operating using the B l u e t o o t h - B l u e t o o t h interface and voluntarily switches to 802.11.  a. Detection of Handoff:  Here, the A P detects that a handoff is requested by using the L S C control frame.  Once it receives the L S C control frame, it sends its response i n the next  slot. Assuming the length of the packet to be of 5 slots, the total delay is 10-slot 62  time, which is about 6 milliseconds. Once the B l u e t o o t h A P receives the response, it switches its interface from B l u e t o o t h to 802.11 and goes to the scanning mode. b.  Search:  Searching by 802.11 clients for possible nearest A P takes place O N L Y i n a single channel as was sent by the acknowledgement packet when the client requested a handoff. Thus, even i n the active scanning mode, the scanning time is reduced. According to the analysis done i n [37], we note that MinChannelTime — DIFS + (aCWmin + daSlotTime). According to 802.11b standard, aCWmin = 31 slots, aSlotTime — 20 sec and DIFS = 50 sec. Thus, MinChannelTime = 670 sec. Using the analysis i n [37] MaxChannelTime — 10.24 ms. Now, i n our case, the client scans only one single channel. Assuming that there is equal probability for this channel to be unused as well as to be free, Total Search T i m e , s = ( T  u  + T  e  ) / 2 where T „ = T i m e needed to scan a used  channel and Te = T i m e needed to scan an empty channel. Now, T = u  Using T  d  2T  d  + MaxChannelTime & T  = 65 ms (for 20 stations), T  u  e  = 2T  d  +  MinChannelTime  = 140.24 ms & T  e  = 130.67 ms;  So, s = 135.5 ms  c. E x e c u t i o n of Handoff: Now worst-case handoff execution time is 3 ms using a Spectrum24 card. Thus, total handoff latency: 6 + 135.5 + 3 ms = 144.5 ms  Case 2: W h e n the client is operating using the 802 interface and voluntarily switches to Bluetooth, a. Detection of Handoff:  63  Here, a control packet is sent by the LSC layer of the client to inform the 802.11 A P that it needs to initiate a handoff to Bluetooth. When the 802.11 A P acknowledges, the client switches over. If we ignore the time taken for the packets to travel, the overall delay in this case would be very low and hence we neglect the delay in this packet transmission.  b. T i m e taken to resume B l u e t o o t h connection: The time taken to resume connection depends on the number of elements in the address queue (i.e., clients who are willing to switchover from 802.11 to Bluetooth and have sent their requests). Since maximum number of active slaves in a piconet is 7, we assume that already 6 addresses are present in the queue when the 7th one arrives. Time taken to process each of the preceding 6 addresses as well one round polling through all the attached slaves is: TAP .Page + (1x2x5) + TAP _p e ag  + (2x2x5) + T  A P  _  P A G E  + (3x2x5) +  +T _Page AP  + (6x2x5)  Since one poll round = sx2xl slots where s = number of slaves, 1 = slot length of the packet and s increases as each slaves get attached to the A P (master). The above expression equals 6 * TAP_p ge a  +210 slots = 128+210 = 338 slot-time  = 212 milliseconds. But, for all practical purposes, this value would be much less as probability for simultaneous 7 handoff requests coming from the clients for 802.11 to Bluetooth switchover is very less. Now, for the current address (7th), paging takes approximately 16 slots in R0 scan mode. This is approximately 10 milliseconds. Thus, total delay in the worst case is 222 milliseconds.  Case 3: W h e n the client is operating using the B l u e t o o t h - B l u e t o o t h interface and moving away from the B l u e t o o t h radio range, a. Detection of Handoff:  64  T h e time taken to detect loss of connection is T ; / i j p o  m e o u 4  when no paging attempt  takes place. If however, paging attempt is taking place then worst case duration w i t h i n which a break i n connection w i l l be detected is polltimeout + ^AP-Page  = 70 + 128 slots = 198 slot time (about 124 milliseconds)  as was discussed before. Thus, the time to detect break i n connection is much less than that when a normal handoff between two 802.11 A P takes place using any 802.11b physical cards [37].  b. Search and E x e c u t i o n of HandofF: Search for possible nearest 802.11 A P and then finally execution of the handoff procedure takes place by normal 802.11-802.11 handoff mechanism (active scanning by 802.11 clients). Worst case time required for search and execution using D - L i n k 520 802.11 interfaces is 290 millisecond, as is analyzed i n [37]. So total handoff latency is 124+290 ms = 414 ms  HandofF Scenario  Average Delay  Voluntary B l u e t o o t h to 802.11  144.5 milliseconds 222 milliseconds 414 milliseconds  Voluntary 802.11 to Bluetooth Disconnection: B l u e t o o t h to 802.11  Table 5.2: Summary of Results of B l u e F i  5.5  Bluetooth and 802.11 Coexistance  Bluetooth and 802.11. both operate i n the same spectrum i n the I S M band. C o located operation of B l u e t o o t h and 802.11 causes m u t u a l interference and packet loss or introduction of bit errors. T h e comparison of B l u e t o o t h and 802.11 is given in Table 5.3. Table 5.4 gives the comparison of B l u e t o o t h and various 802.11 stan-  65  dards.  Various works have looked into coexistence problems and proposed some  solutions to co-existence between Bluetooth and 802.11. I E E E 802.15 [40] has created task group 2 ( T G 2 ) to look into ways to mitigate the co-existence interference between B l u e t o o t h and 802.11. T w o class of co-existence mechanisms have been defined in [40]- collaborative and non-collaborative co-existence. M o b i l a n Corporation in [39] have proposed co-location without co-existence of Bluetooth and 802.11 to avoid interference. T h e work i n [39] also proposes driver level switching and adaptive hopping that changes the hopping sequence based on interference. Chiasserini et. al. [41] have proposed two schemes V - O L A , to be applied to W L A N stations to avoid overlap between 802.11 traffic and B l u e t o o t h voice packets, and D - O L A , to be executed at the B l u e t o o t h devices to avoid overlap i n frequency between 802.11 traffic and B l u e t o o t h data packets. For B l u e F i we conclude that driver level switching is the best method to avoid Bluetooth and 802.11 interference, since while B l u e t o o t h is operating, 802.11 is i n power save mode, and while 802.11 is operating, Bluetooth is i n park mode. Parameter Access S y m b o l Rate Spread Spectrum  Bluetooth Point to multipoint 1 Msps  802.11 Point to point only 11 Msps  FSSS  Profiles D a t a Distribution  Almost U n l i m i t e d No Restriction 60mA  DSSS L A N station or Access P t Access point only 300mA  P C M Channels Serial, U S B , U A R T , A u d i o Master  Voice over 802.3 802.3 Mobile Station  Current C o n s u m p t i o n Audio Cable Replacement M o b i l i t y Management  Table 5.3: Comparison of Bluetooth and 802.11b We used the N I S T simulator [38] to measure performance of Bluetooth w i t h 802.11 interferer and performance of 802.11 w i t h a Bluetooth interferer. T h e N I S T simulator models the network i n simple manner. and outputs a complex-valued signal.  A transmitter takes input bits  T h e channel model combines the desired  66  Characteristic Spectrum M a x Data Rate Connections Frequency Selection  Bluetooth 2.4 G H z 723 kbps PTMP  802.11  802.11b  802.11a  2.4 G H z 1.2 M b p s PTP  2.4 G H z 5 Mbps PTP  5 GHz 32 M b p s PTP  FHSS Yes Any  FHSS/DSSS No  DSSS No  OFDM  Authentication F i x e d Networks CQDDR  Ethernet  Option  No  Ethernet No  Ethernet No  Encryption  40 bit R C 4  40 bit R C 4  40 bit R C 4  40 bit R C 4  No  Table 5.4: Comparison of Wireless standards. signal w i t h that produced by an interference transmitter and adds distortion to the combined signal. T h e channel outputs this noisy signal, which is then input to the desired receiver, which uses the same technology (Bluetooth, I E E E 802.11b, etc.) as the desired transmitter. T h e receiver outputs a string of bits, w h i c h is compared to the input bits, accounting for the delay characteristics of the transmitter  and  receiver. Bluetooth Transceiver with 802.11 (1Mbps) interference  30 .0E-01 4 EOE0 -1 4] 4 00E-01 | 33 .JE-01 • 30 .0E-01 \ 2 30E-01 lii 20 .0E-01 £ 1 SOE0 -1 1 OOE0-1 500E-02 00 .OE0 .0 Carrier Interference Ratio  Figure 5.2: B E R V s C I R i n a B l u e t o o t h Transceiver  We d i d detailed simulations by varying the Carrier Interference R a t i o ( C I R ) power and the frequency difference (df) measured i n M H z , and measured the B i t E r r o r Rate ( B E R ) .  Fig.  5.2 shows the B i t E r r o r rate ( B E R ) measurements while varying the  Carrier Interference R a t i o ( C I R ) and df i n a Bluetooth Transceiver w i t h a 1 M b p s  67  Bluetooth Transceiver with 802.11 (11Mbps) interference  a  COOEO -i 50 .0E-01  19 40 .0E-01 | 30 .0E-01 g 20 .0E-01 10 .0E-01 0 00E*0G N*  -•-di- 0 ... - dt- 2 di- 4  rA  A  A  ?  jk ft s> a ».  C a r r i e r Interference Ratio  Figure 5.3: B E R Vs CIR in a Bluetooth Transceiver 802.11 {1 Mbps) Transceiver with Bluetood Interference  Figure 5.4: B E R Vs CIR in a 802.11 Transceiver at 1Mbps 802.11 interferer. The Carrier to Noise (CNR) ratio is kept at 30dB. The B E R decreases when the CIR decreases for the same frequency offset. The B E R decreases when the frequency offset increases (df increases) for the same CIR. This implies that as the carrier power signal becomes stronger with respect to the interferer signal, the error rate decreases for the carrier signal. Also, the figure shows that with increase in frequency difference between the carrier signal and the interferer, the error rate is decreased.  Fig. 5.3 shows the Bit Error rate (BER) measurements while varying the Carrier Interference Ratio (CIR) and df in a Bluetooth Transceiver with a l l Mbps 802.11 interferer.  The Carrier to Noise (CNR) ratio is kept at 30dB. The B E R  decreases when the C I R decreases for the same frequency offset. The B E R remains the same for different frequency offset for the same value of CIR when the interferer  68  802.11 (11Mbps) Transceiver with Bluetooth Interference  500E41 4 50EO1 4 00E01 % 3S .DE4J1 • 30 .0E-01 £ 250E4J1 UJ 200EO1 3 1 50EO1 1B0E-01  -4-dT.O — <*-2 dl'4  is;  <*» e  -•-dr. 10  samez  - * 1 4  0OOEQ .0  Carrier Interference Ratio Figure 5.5: B E R V s C I R i n a 802.11 Transceiver at 11Mbps Bluetooth with 802.11 Interference at 1Mbps Vs 11 Mbps  BT*.th1ir*ft^8Q2 11d ,f  <b  v  O  £  >  ,N  *V  *J  Carrivf Interference Ratio  Figure 5.6: Bluetooth Transceiver w i t h 802.11 Interferer at 1Mbps a n d 11 M b p s 802.11 is at 11 M b p s .  Fig.  5.4 shows the B i t E r r o r rate ( B E R ) measurements while varying the  Carrier Interference R a t i o ( C I R ) and df i n a 802.11 Transceiver at 1 M b p s w i t h a Bluetooth interferer. The Carrier to Noise ( C N R ) ratio is kept at 35dB.  Fig.  5.5 shows the B i t Error rate ( B E R ) measurements while varying the  Carrier Interference R a t i o ( C I R ) and df i n a 802.11 Transceiver at 11 M b p s w i t h a Bluetooth interferer. The Carrier to Noise ( C N R ) ratio is kept at 35dB.  F i g . 5.6 shows the B i t E r r o r rate ( B E R ) measurements while varying the Carrier Interference R a t i o ( C I R ) and df i n a Bluetooth Transceiver w i t h a 802.11 interferer at 1Mbps and at 11 M b p s . The Carrier to Noise ( C N R ) ratio is kept at  69  802.11 (1 Mops Vs 11 Mbps) Transceiv er mth B luetooth Interference  5 OOE0 -1 «00E-01 30 .0E-01 £ 20 .0E-O1 u  a  1O . OE-01 0 XE-00  3  -80211{1Mtx»),ot = 2 ~SCC1 .1{11Mbp»), 01*2  3  Carrier Interferenoe Ratio  Figure 5.7: 802.11 Transceiver at 1Mbps and 11Mbps w i t h B l u e t o o t h Interferer 30dB. T h e comparisons show that a higher B i t E r r o r Rate is introduced when the interferer b a n d w i d t h is increased from 1Mbps to 11 M b p s w i t h the same C I R and frequency offset.  F i g . 5.7 shows the B i t E r r o r rate ( B E R ) measurements while varying the Carrier Interference R a t i o ( C I R ) and df i n a 802.11 Transceiver at 1 M b p s and at 11 M b p s w i t h a B l u e t o o t h interferer. T h e Carrier to Noise ( C N R ) ratio is kept at 35dB. T h e comparisons show that a higher B i t E r r o r Rate is introduced when the 802.11 Transceiver b a n d w i d t h is increased from 1 M b p s to 11 M b p s w i t h the same C I R and frequency offset.  70  5.6  Discussions  In this Chapter we introduced Handoff algorithms' for different scenario's of switching from a B l u e t o o t h A P - B l u e t o o t h Client connection to 802.11 A P - 802.11 Client and vice versa. W e have modified the current protocol stack of B l u e t o o t h and 802.11 to introduce a new layer L S C for interoperability. W e have designed the header for messages i n the L S C and shown the delay analysis on various handoff's (Table 5.2). We propose to implement the L S C daemon as an external kernel module that can be attached using 'insmod' command i n U N I X . T h e exact implementation and evaluation of this daemon as kernel module is left as a future extension of this work i n another project. We investigated the Co-existence mechanisms for B l u e t o o t h and 802.11 and through simulations found the different error rates while varying the Carrier Interference ratio and the frequency offset.  71  Chapter 6  BlueMobile - A Mobile IP based Handoff system for Bluetooth, 802.11 and GPRS links 6.1  Introduction  W h i l e B l u e t o o t h technology [1], [3], [4] has become popular as a market leader for short range wireless networks, T h e I E E E 802.11 standard [24], [21], [22], [23] for W L A N s is the most widely used W L A N standard today. T h e standard uses the carrier sense multiple access ( C S M A ) , medium access control ( M A C ) protocol w i t h collision avoidance ( C A ) . B o t h B l u e t o o t h and 802.11 physical coverage is limited because of the engineering constraints of the underlying radio technology. O n the other hand, G P R S (General Packet R a d i o System) [53], [54] is the packet mode extension of G S M and is a prevalent cellular technology that has a wide area of coverage.  Bluetooth, I E E E 802.11 and cellular network technology like G P R S have properties complementing one another i n different amplitudes of power consump-  72  tion, area of operation and data rate.  W h i l e Bluetooth comes w i t h low power  consumption, reliable connectivity, low bandwidth (in the order of 721 kbps) and a small area of operation (about 10 meters) w i t h only a m a x i m u m of 7 slaves per master device, 802.11 provides wider area of operation, b a n d w i d t h i n the order of 11 M b p s , coupled w i t h higher power consumption. O n the other hand, while 802.11 supports data rate from 1 to 54 M b p s and can cover upto a few thousand square meters, G P R S technology offers limited data rates from 64 kbps to 2 M b p s [44] but a much wider area of coverage w i t h all-over connectivity. Thus these three technologies if converged, can actualize a system which w i l l enable roaming users to smoothly switch between technologies and thus to use all the advantages bestowed by these three types of network.  W i t h this idea i n m i n d , we designed a  handover system called BlueMobile. BlueMobile integrates Bluetooth, 802.11 and G P R S technologies, by introducing a simple extension to the already existing M o bile I P implementation [49], [51]. Mobile I P is an extension to the T C P / I P protocol suite and takes gives the wireless access networks the provision to provide nodes the ability to roam accross multiple I P subnets while assuming the same network address and maintaining network layer connectivity.  T h e task of designing the network architecture for a handoff system [14], [15], [50], [52] switching between 3 different technologies is challenging since the aim is smooth interaction both from the end user and network operator's viewpoint.  In this chapter we describe an approach to the design of an integrated Bluet o o t h / 8 0 2 . 1 1 / G P R S network architecture.  We introduce M o b i l e I P elements to  various networks and using a simple extension to the Mobile IP, we integrate the three networks. We also present algorithms for handoff between the networks i n various situations.  F i n a l l y we analyze the performance and delay of our Handoff  algorithms.  73  6.2  Related Work  In [46] we proposed a B l u e t o o t h algorithm for fast scatternet formation w i t h the ability to be controlled remotely. In [47] we proposed an architecture for co-existance of B l u e t o o t h and other wireless networks. In [55] we presented a novel convergence protocol between B l u e t o o t h and 802.11 through the introduction of a Software Layer ( L S C ) i n the protocol stack of B l u e t o o t h and 802.11. T h e present work is i n continuation of the previous works.  In [44] Buddhikot et al. present integration of 802.11 and G P R S on seamless connectivity. M i n - h u a et al. [43] introduce a Mobile I P handoff scheme between 802.11 and G P R S . In [45] Sharma et al. bring forward a vertical handoff system between G P R S and W L A N by using extended Mobile IP. Albrecht et al. [42] present protocol concepts for an extension of I P for mobility issues i n B l u e t o o t h networks. In [37] Velayos et al. propose techniques to reduce 802.11b handoff time.  6.3 6.3.1  Mobile IP Mobile I P Architecture  Traditional I P technology can't support mobility i n the I P layer.  I E T F defines  Mobile IP. M o b i l e I P introduces two network entities: home agent ( H A ) and foreign agent ( F A ) to manage mobility. W h e n M H is i n its home subnet (its initial subnet), it uses normal I P protocol to communicate.  W h i l e it enters the foreign subnet  (other subnets except home subnet), it acquires an I P address, called care of address ( C O A ) . It. then sends registration message-to H A to inform H A its current location, C O A . T h e data packets sent by correspondent host ( C H ) to M H arrive at M H ' s home subnet by normal I P routing. H A captures these packets on behalf of M H , and encapsulates them w i t h new I P header, whose destination address is C O A , source address is H A (it is tunneling). T h e n the encapsulated packets are forwarded  74  to M H ' s C O A . F A or M H restores the original I P packets. D a t a packets from M H to C H are routed normally. T h e flow of data transmission is illustrated as F i g . 6.1.  Figure 6.1: I P datagram flow to and from a Mobile Host using M o b i l e I P W h e n M H enters new subnet, it needs handoff. It acquires a new C O A and registers it to H A again, so that H A can correctly forward I P packets to it. D u r i n g the time between M H leaving its old foreign subnet and H A receiving M H ' s new registration request message, because H A doesn't know M H ' s current C O A , it still forwards those packets whose destination address is M H to the old F A , and these packets w i l l be dropped by the old F A . It is possible that the connection w i l l be disrupted. If the distance between the M H and H A is a bit long, the disruption time w i l l be large. In this case, decreasing handoff delay and packet loss is the crucial issue for Mobile I P handoff. Mobile I P is proposed to support mobility i n computer network. B u t because of its characteristic of easy realization, Mobile I P can be used in many wireless networks to support mobility.  F i g . 6.1 shows the I P datagram flow between a mobile host connected to a foreign network and its communicating element i n the internet. Datagrams from the mobile host to the communicating element are routed v i a p a t h 1 through the Host 75  to its home network. B u t Datagrams from the Internet are tunneled by the Home Agent to the Care-of-Address of the Mobile Host through P a t h 2 v i a the Foreign Agent.  6.3.2  Mobile IP Adaptation for Bluetooth, 802.11 A N D G P R S  In order to support mobility between the two networks, we use a peer network structure.  T h a t is, G P R S and Bluetooth access Internet as peer networks, and  implement the function of Mobile I P respectively. In the B l u e t o o t h network, we assume that the existing architecture is enhanced by network elements using the concepts from the B L U E P A C I P [42], which is based on ideas from M o b i l e IP. Also, the G P R S network has Mobile I P components for supporting handoffs.  In  G P R S network, we propose to implement the H A function at G G S N . W h e n M H whose home network is G P R S moves to a foreign network (it is possibly not G P R S , such as Bluetooth), it registers to H A ( G G S N ) its current C O A through the F A at the foreign network. G G S N ( F i g . 2.8) checks a l l the I P packets that came from outside Internet. Once there are some packets whose destination is M H , it acts as H A , that is, it re-encapsulates these I P packets and forwards them to M H by tunnel.  We can also implement the F A function at G G S N (gateway G P R S support node), but we propose to implement it at S G S N . T h e n the F A function can be distributed to the SGSNs(serving G P R S support node), b u t not centralized at G G S N , which can alleviate the burden of G G S N .  W h e n M H moves to G P R S network, which is a foreign network to it, G G S N w i l l assign an I P address to it (assuming I P G ) . I P G can be a private I P address, but also can be a public one. A t this time, S G S N acts as the F A of M H , so it broadcasts the Agent Advertisement messages to M H [17]. M H registers the I P address of S G S N (assuming as IPS) as its C O A to the H A . S G S N relays this registration  76  message, and records a mapping i n its database: <MH, I P O .  W h e n H A receives the registration message, it forwards the data packets belonging to M H to S G S N . W h e n S G S N receives these packets, it looks up i n the database and finds the mapping of M H . It de-encapsulates these packets, and reencapsulates them to new I P packets, whose destination address is I P G and source address is I P S . S G S N forwards the new packets to M H using G P R S routing mechanisms. A t last, M H de-encapsulates the I P packets and restores the original I P packets. T h e packets from M H to C H are sent to S G S N firstly, and then are tunneled to G G S N . T h e y are forwarded to Internet by the G G S N at last.  W h e n M H moves i n the service area of a S G S N , it only considers handoff between different B S S s (This is a problem of link layer handoff.); when it moves between different S G S N s , it should take the Mobile I P handoff. It should register the new S G S N to its H A .  T h e mobility support i n Bluetooth is comparatively simple. B l u e t o o t h itself defines O S I layer 1 (baseband radio) and O S I layer 2 (connection setup, link management), so it only need add the layer 3-Mobile I P function to B l u e t o o t h network: adding the H A and F A module using hardware or software i n the fixed network it connects. T h e H A and F A function can be implemented i n a router or a host or an access point.  Simlarly, i n a 802.11 network, the H A and the F A module are  implemented i n an Access point, router or a Host. In our B l u e M o b i l e architecture, we formulate 802.11 as the home network w i t h the Home Agent ( H A ) .  T h e Foreign Agent (FA) i n the G P R S and B l u e t o o t h network have the functionality of a D H C P - s e r v e r [48] to assign Care-Of-Addresses ( C O A ) from a pool of locally available I P addresses. T h e C O A ' s are assigned for a period only, after that  77  they axe reclaimed by the F A for reuse. T h e Mobile Host has to renew subscription to a particular C O A if it wants to keep it for a longer time.  Figure 6.2: The BlueMobile network architecture  6.4  Mobile IP Handdoff Algorithm between Bluetooth, 802.11 & GPRS  Let us take two specific cases of voluntary handoff & a case of forced handoff due to disconnection.  78  A . User is in the radio range of b o t h G P R S &; B T and wants to voluntarily switch from his currently running B T communication to G P R S , possibly because he needs a wider area of connection (Fig.  6.2):  We introduce a polling scheme whereby the Bluetooth Access Point ( A P ) constantly polls the client when the client is using the B l u e t o o t h network. T h e clients also must respond to these p o l l packets, even when they have no data to transfer. T h o u g h the Link Supervision  timer is present on the link layer i n B l u e t o o t h protocol stack that  detects broken links, we do not depend on this timer. T h i s is because, the default timeout value specified i n the Link Supervision  Timer  is 20 seconds, which intro-  duces a very large handoff latency when considering a handoff between G P R S and Bluetooth W h e n the M H wants to switch over to G P R S , it must inform its old Bluetooth F A that it intends to switch over. It does this by sending some special control bits along w i t h these p o l l acknowledgements.  Immediately, the F A i n B l u e t o o t h  sends a control packet to the H A i n W L A N giving the current address of the client that wishes to switch over to G P R S and acknowledges the switchover to the mobile node using another control packet. T h i s sending of acknowledgement and transmission of control packets to  HAs02.11 takes  place simultaneously or w i t h i n negligible  time interval so that for all practical purposes, we may safely neglect this latency. W h e n the Host Agent receives this message, it begins to put all the unsent packets intended for this M H i n a F I F O buffer. T h e size of the buffer depends on the m a x i mum latency of the G P R S - B l u e t o o t h handoff and also on the transmission datarate.  Once M H decides to enter the G P R S network, it changes interface to G P R S and sends Host Agent i n the W L A N network the formal registration message through the G P R S Foreign Agent to confirm the Handoff. After receiving the final registration message, the H A tunnels the I P packets to the G P R S Foreign Agent from the F I F O buffer to the Mobile Host. T h e F A of G P R S then tunnels these packets back  79  to M H . Similarly, a l l packets that are sent b y the mobile node are first received by the F A of the G P R S network and is then tunneled over to the H A which then sends these packets to its true destination.  '.-7.  yV/.\-.-OVeriaiirJ  /•••••••••• ii^.^-n^^^U/  (168JrMMJ)  /  /Btoetoato^xV Hotspot \ \ (200.0,0.0) : -\ 1VU1  -S> Horn5 Address:  FAca>Rs (168.0.0.1)  .... V k  121.0.0.8 COA 200.(3^.8  _  FA Bluetooth  (200.0.0.1)  yyyyyyyyyy^-^'^  y.'.-.network.'.'.'. V.... (Honie NeWvork) \ i2i.fl.n.o  \x : : V: . :  \  :  :  \  HA  '  (121.0.0.1)  Figure 6.3: M H moves from G P R S to Bluetooth B . User is i n the radio range of b o t h G P R S a n d B T a n d he wants to voluntarily switch from his currently running G P R S communication to B l u e t o o t h - B l u e t o o t h communication, possibly because he needs to save power or G S M airtime ( F i g . 6.3):  W h e n the M H wants to switch over to G P R S , it must inform its old G P R S F A that it intends to switch over before activating its Bluetooth interface. T h e G P R S F A immediately informs this to the node's H A along w i t h its address information. The H A immediately stops sending packets to the old G P R S F A and creates a buffer  80  for all unsent packets destined for this B l u e t o o t h mobile node. T h e size of the buffer as usual depends on the m a x i m u m latency of the G P R S - B l u e t o o t h handoff and also on the transmission datarate. T h e 802 H A informs all B l u e t o o t h F A i n range that a device w i t h that address wants to register itself w i t h the B l u e t o o t h network. T h e Bluetooth F A sends control packets to the Bluetooth A P ' s i n the network which in t u r n starts paging for a device using that address. T h i s saves precious time on I N Q U I R Y procedure. T h e paging attempt is tried four times and if the device is not found, it is assumed that some other A P must have discovered the B l u e t o o t h device.  C . A client running B T connection, moving away from the B T A P so that it no longer lies in its radio range.  O u r design allows seamlessly  switching to the G P R S network so the client does not feel any break in connection.  T h i s w i l l be similar to case A . T h e only difference here w i l l be that the M H w i l l discover that it is out of the Bluetooth range only when it no longer receives the poll packets from the Bluetooth A P . T h e B l u e t o o t h A P w i l l also discover that M H has moved away from its range when it does not receive the acknowledgement packets in response to its poll packets. Immediately, the F A i n B l u e t o o t h sends a control packet to the H A i n W L A N giving the current address of the client that is missing. W h e n the Host Agent receives this message, it begins to put all the unsent packets intended for this M H i n a F I F O buffer until H A receives the registration message from M H through F A of G P R S that it has successfully registered itself w i t h G P R S network.  81  O verb M GPRS network (168.0.0,0)  FA  G P R S  0.0.1)  MH HA (121.0.0.1)  Figure 6.4: Overlapped Bluetooth and 802.11 zone  6.5 Analysis of the Algorithm In our design of BlueMobile, we have considered only standard technology features, like I N Q U I R Y and P A G E procedures i n Bluetooth.  In the following, we analyze  the handoff duration and give an estimate of the handoff delay i n two cases: of the voluntary switch from Bluetooth to G P R S or 802.11 and vice versa, a n d i n another case of the disconnection from Bluetooth hotspot due to the M o b i l e Host going away from the region of Bluetooth coverage.  Case 1: .Voluntary Bluetooth to G P R S handoff  Here, the F A i n the Bluetooth Access Point detects that a handoff is requested by using the control frame of the message sent by the Mobile Host Decision module. Once it receives the control frame, i t sends its response i n the next slot. Assuming 82  the length of the packet to be of 5 slots, the total delay is 10-slot time, which is about 6 milliseconds. Once the B l u e t o o t h A P receives the response, FA-BLU' ETOOTH forwards the Request message along w i t h the M o b i l e Host address to the HAs02.11 i n the Home network.  T h e HAs02.11 responds to the request and sends an adver-  tisement to the FAQPRS w i t h i n 2 ms of notification time [45]. M o b i l e - I P responds to this advertisement by invalidating previous agent advertisements and sending a registration request w i t h i n 2 milliseconds. T h e G P R S foreign agent responds w i t h registration reply after approximately 800 to 1100 milliseconds. T h e length of the duration corresponds to the round trip time on the G P R S link. T h e registration reply completes the handoff and further packets are sent over the G P R S network. Thus total handoff latency is = ( 6 + 2 + 2 + 800/1100) ms = 810 -1110 milliseconds.  Case 2: V o l u n t a r y G P R S to B l u e t o o t h handoff  Here, the F A i n the G P R S station detects that a handoff is requested by using the control frame of the message sent by the Mobile Host Decision module.  Once  it receives the control frame, it forwards the request to the H A o 2 . n - T h e H A o 2 . n 8  8  responds to the notification w i t h 2 milliseconds and sends the address of the M o b i l e Host to the a l l available Bluetooth Foreign Agents i n range (since the 802.11 H A would not know which B l u e t o o t h F A the current M H is close to and there can be more t h a n one B l u e t o o t h hotspots.  T h e M o b i l e I P responds to this notification  w i t h i n 2 milliseconds. T h e FABLUETOOTH PAGE (T p_p A  a g e  i n turn instructs the APBLUTOOTH to  ) the M o b i l e Host using that address; thus saving the time ex-  pensive I N Q U I R Y procedure as it already has the Bluetooth Device Address. T h e round trip time for W L A N is approximately 250 milliseconds. TAP_p ge — 128 slot a  time = 2.5 milliseconds (min) for mobile i n Scan Repition(SR) M o d e R 0 ; 1.28 seconds (average) for mobile i n S R mode R I and 2.56 seconds (maximum) for mobile in S R mode R 2 . T h e paging procedure completes the handoff and further packets  83  are sent over the B l u e t o o t h Network. So delay i n this case is: M i n i m u m delay = 2 + 2 + (250 or 2.5) = 254 milliseconds; But latency i n the G P R S links is 400 - 700 milliseconds. So the mobile node w i l l keep receiving some out of order packets upto 400 - 700 milliseconds on its G P R S interface. If the notification request is send well i n advance then there is no packet loss during the handoff. Average delay = 2 + 2 + (250 or 1280) = 1284 milliseconds M a x i m u m delay = 2 + 2 + ( 250 or 2560) = 2564 milliseconds.  Case 3: Voluntary B l u e t o o t h to 802.11 handoff  T h i s situation is shown when the Bluetooth and 802.11 coverage areas overlap(Fig. 6.4).This case is similar to the handoff from B l u e t o o t h to G P R S , the F A i n the Bluetooth Access Point detects that a handoff is requested by using the control frame of the message sent by the Mobile Host Decision module. Once it receives the control frame, it sends its response i n the next slot. Assuming the length of the packet to be of 5 slots, the total delay is 10-slot time, which is about 6 milliseconds. Once the B l u e t o o t h A P receives the response, FABLUETOOTH  forwards the Request  message along w i t h the Mobile Host address to the HA802.11 i n the Home network. T h e HA802.11 responds to the request w i t h i n 2 ms of notification time [45].  Searching by the mobile 802.11 clients (which switched over from Bluetooth) for possible nearest A P takes place O N L Y i n a single channel as was sent by the acknowledgement packet when the client requested a handoff. active scanning mode, the scanning time is reduced. According to the analysis done i n [37], we note that MinChannelTime  = DIFS + (aCWmin  +  84  aSlotTime).  Thus, even i n the  According to 802.11b standard, aCWmin  = 31 slots, aSlotTime  = 20 sec and DIFS = 50 sec.  Thus M i n C h a n n e l T i m e = 670 sec. Using the analysis i n [37] MaxChannelTime  = 10.24 ms.  Now, i n our case, the client scans only one single channel. Assuming that there is equal probability for this channel to be unused as well as to be free, T o t a l Search T i m e , s = ( T channel and T Now, T  = 2T  e  u  Using T  d  d  u  + T  e  ) / 2 where T  u  = T i m e needed to scan a used  = T i m e needed to scan an empty channel. + MaxChannelTime  &T  e  = 2T  d  +  MinChannelTime  = 65 ms (for 20 stations), T „ = 140.24 ms & T  e  = 130.67 ms;  So, s = 135.5 ms Now worst-case handoff execution time is 3 ms using a Spectrum 24 card. Thus, total handoff latency is: 6 + 2 + 135.5 + 3 = 146.5 ms  Case 4: B l u e t o o t h to G P R S handoff due to disconnection  T h i s case is similar to Case 2: voluntary handoff to G P R S from Bluetooth. The only addition is the m i n i m u m time taken to detect loss of connection is  T iiu po  meout  when no paging attempt takes place. If however, paging attempt is taking place then worst case duration w i t h i n which a break i n connection w i l l be detected is Tpolltimeout + T _ AP  Page  = 70 + 128 slots = 198 slot time (about 124 milliseconds),  since we assume that the Bluetooth A P does not send p o l l packets when it is paging for new devices to connect to the piconet. Thus total delay is 124 + (6 + 2 + 2 + 800/1100) = 934 milliseconds to 1234 milliseconds.  85  Case 5: V o l u n t a r y 802.11 to B l u e t o o t h handoff  T h i s occurs when 802.11 and B l u e t o o t h hotspot areas overlap as shown i n F i g . 6.4. T h i s case is similar to Case 1 i n which G P R S connection handoffs to Bluetooth. M i n i m u m delay = 2 + 2 + (250 or 2.5) = 254 milliseconds Average delay = 2 + 2 + (250 or 1280) = 1284 milliseconds M a x i m u m delay = 2 + 2 + (250 or 2560) = 2564 milliseconds.  Case 6: B l u e t o o t h to 802.11 handoff due to disconnection  T h i s case is similar to Case 3: voluntary handoff to 802.11 from Bluetooth. T h e only addition is the time taken to detect loss of connection is  Tu po  timeout  when no  paging attempt takes place. If however, paging attempt is taking place then worst case duration w i t h i n which a break i n connection w i l l be detected is Tpoiitimeout + TAP_Page = 70 + 128 slots = 198 slot time (about 124 milliseconds) as was discussed earlier. Thus total delay is 124 + (6 + 2 + 135.5 + 3) = 270.5 milliseconds. Table 6.1: Results of B l u e M o b i l e Handoff Scenario Average Delay Voluntary Bluetooth to G P R S 810 - 1110 milliseconds Voluntary G P R S to Bluetooth 1284 milliseconds Voluntary Bluetooth to 802.11 146.5 milliseconds Disconnection: Bluetooth to G P R S Voluntary 802.11 to Bluetooth Disconnection: Bluetooth to 802.11  86  934 - 1234 milliseconds 1284 milliseconds 270.5 milliseconds  6.6  Discussions  In this chapter we introduced Mobile-IP based Handoff algorithms' for different scenario's of switching from a B l u e t o o t h connection to 802.11 connection or G P R S connection and vice versa. W e have introduced certain elements of Mobile I P to the G P R S network. W e have shown the delay analysis on various handoff's(Table 6.1 provides a summary of our results). T h e delay parameters suggest that B l u e M o b i l e system can handle audio and video connectivity w i t h a jitter during handoff. Also, T C P / I P connection can be supported over B l u e M o b i l e since the typical m a x i m u m retransmission timeout is 1 second. Thus we see that given proper modifications to the already existing B l u e t o o t h / G P R S / W L A N architectures, we may allow any mobile device w i t h hardware interfaces for all the three types of network to seamlessly operate i n any network domain. Thus a single mobile device can be operated i n a large area depending upon the network available without loosing connectivity. Further work on the hardware and interference aspects of Bluetooth, G P R S and 802.11 would be needed for hardware interoperability.  87  Chapter 7  Conclusions 7.1  Summary  Bluetooth technology has become very popular nowadays. M o r e and more devices like cell-phones, laptops, pda's are equipped w i t h inbuilt B l u e t o o t h chips. To support 802.11, already 802.11 hotspots w i t h numerous access points are deployed extensively.  For G P R S networks, G S M cellular networks have already established  ubiquitous coverage.  We foresee that i n the near future B l u e t o o t h hotspots w i l l  gain immense popularity and widespread deployment.  In this thesis we investigated current Bluetooth Scatternet algorithms. We found some deficiencies i n the treatment of Scatternet algorithms, as the current ones were not customized i n regard to issues w i t h Bluetooth hotspots. A l s o , L o a d balancing i n Scatternet formation has hitherto not been studied i n detail. Hence we presented a load balanced Scatternet formation algorithm w i t h respect to usage in B l u e t o o t h hotspots.  In the load balanced algorithm, each B l u e t o o t h device is  assigned a weight depending on their processing power. A laptop would be assigned a higher weight than a pda, which i n t u r n would be assigned a higher weight than a cell phone. A higher weight device would be able to function as a master and accommodate more number of devices as slaves, than a relatively lower weight device.  For devices w i t h similar weights, the neighboring piconets would t r y to minimize the differences i n piconet size. We have evaluated our system w i t h detailed simulation and found that our algorithm performs well w i t h respect to the current Scatternet algorithms. Also, we proposed a novel remote control and querying scheme for Bluetooth devices arranged i n a Scatternet w i t h one or more devices having access point capability. Such a remote control system has hitherto not been investigated i n detail.  T h e n we investigated the issues w i t h interoperability of B l u e t o o t h w i t h 802.11 and G P R S technologies. T h e interoperability of Bluetooth w i t h G P R S has hitherto not been studied i n detail. W e propose B l u e F i - a convergence system for B l u e t o o t h and 802.11. B l u e F i conceptualizes a software layer i n the protocol stack of Bluetooth and 802.11. However, to keep backward compatibility by not modifying the protocol stacks of Bluetooth and 802.11, we propose implementation of B l u e F i using a system daemon that traps packets from the B l u e t o o t h and 802.11 interfaces and sends it to the protocol stack after processing it. We d i d a detailed analysis of my system w i t h various delays involved. T h e n we proposed B l u e M o b i l e , a Mobile I P based solution for interoperability of Bluetooth w i t h 802.11 and G P R S . B y introduction of Mobile I P elements to the architecture of Bluetooth, 802.11 and G P R S , these technologies can become Mobile I P compatible. W e analyzed the various situations for handover and d i d a detailed delay analysis involved i n various situations. T h e analysis demonstrates that our interoperability system helps achieve good performance and can be deployed i n current devices w i t h interactive audio, streaming video and T C P / I P data requirements.  89  7.2  Future Work  Our B l u e t o o t h Scatternet algorithms and internetworking architecture provides many issues for further investigation and research.  First, issues w i t h interoperability of Bluetooth w i t h C D M A networks should be studied for possible practical convergent systems.  Second, In E q u i B l u e , the effect of clustering should be studied w i t h respect to Scatternet formation. A n overlay clustering on top of the existing Scatternet formation would open research issues for optimization of resource and routing strategies.  T h i r d , Access point placement i n a hotspot supporting Scatternet formation is an open research issue i n Bluetooth technology. T h e placement of access points can include static placement and mobile access points to address the coverage area. Also, nodes w i t h i n one hop of an access point can be made a v i r t u a l access point and neighboring nodes of the v i r t u a l access point can get resources and a route to the access points.  Fourth, the use of Agents i n the use of Scatternet formation is an emerging research topic. Agents like Grasshopper or Wave can be used i n a Scatternet for efficiently solving many problems related to routing, resource allocation and discovery, conflict resolution i n allocation of piconet frequency.  Fifth, D u r i n g B l u e t o o t h internetworking w i t h 802.11 and G P R S technologies, the issue of security needs to be looked into. Since this thesis focuses on performance issues, security analysis.has been left out. For example, during handover's from one network to another, security authentication mechanisms should be formulated.  90  Sixth, In B l u e F i , implementation issues for a system daemon supporting i n ternetworking of B l u e t o o t h and 802.11 should be investigated.  Seventh, In BlueMobile, a prototype implementation might reveal some ext r a delays, unaccounted for, i n a theoretical analysis as done i n our thesis.  Finally, a hardware design for Mobile I P elements for B l u e t o o t h should be done, or a software module can also emulate the function of Home Agent and Foreign Agent i n a Bluetooth network.  91  Bibliography [1] The  Bluetooth  Special  Interest  Group.  Retrieved  from  http://www.bluetooth.com on J u l y 19, 2003. [2] J . Haartsen.  B l u e t o o t h - the universal radio interface for ad hoc, wireless  connectivity. Ericsson  Review, 3:110-117, 1998.  [3] J . B r a y and C . F . Sturman. Bluetooth:  Connect Without Cables. Prentice-Hall,  Inc., 2001. [4] B . A . M i l l e r and C . Bisdikian. Bluetooth Revealed: The Insider's Open Specification  for Global Wireless Communications.  Guide to an  Prentice-Hall, Inc.,  2000. [5] C . E . Perkins. Ad Hoc Networking.  Addison-Wesley, 2001.  [6] J . B r o c h , D . A . M a l t z , D . B . Johnson, Y . H u , and J . Jetcheva. Performance comparison of multi-hop wireless ad hoc network routing protocols. and Networking,  Computing  pages 85-97, 1998.  [7] S. R . Das, R . C . Neda, and J . Y a n . Simulation-based performance evaluation of routing protocols for mobile ad hoc networks. Mobile Networks and  Appli-  cations, 5:179-189, 2000. [8] G . M i k l o s , A . Racz, Z . Turanyi, A . Valko, and P . Johansson.  Performance  aspects of bluetooth scatternet formation. In Proceedings of The First Workshop on Mobile Ad Hoc Networking  and Computing,  Annual  2000.  [9] S. Zurbes. Considerations on link and system throughput of bluetooth networks. In Proceedings of the 11th IEEE International Mobile Radio Communications, [10] IEEE  802.15.2,  Symposium  on Personal,  and  pages 1315-1319, 2000.  Coexistence  task  group.  Retreived  http://grouper.ieee.org/groups/802/15/ on August 31, 2004.  92  from  [11] A . M i s h r a , M . Shin, and W . A r b a u g h . A n empirical analysis of ieee 802.11 mac layer handoff process. ACM SIGCOMM  Computer  Communication  Review, 33,  A p r i l 2003. [12] K . Kastell, U . Meyer, and R . Jakoby. Secure handover procedures. In Proceedings of CIC, 2003. [13] C . L a w , A . K . M e h t a , and K . - Y . Siu. A new bluetooth scatternet formation protocol.  Journal  on Mobile Networks  and Applications  (MONET),  Special  Issue on Mobile Ad Hoc Networks, 8, 2001. [14] A . K a n s a l .  A handoff protocol for mobility i n bluetooth public access.  In  Proceedings of the 15th ICC, 2002. [15] S. Pack and Y . C h o i . Pre-authenticated fast handoff i n a public wireless lan based on ieee 802.Ix model. IFIP  TC6 Personal  Wireless  Communications,  pages 175-182, October 2002. [16] C . E . Perkins and K . - Y . W a n g . O p t i m i z e d smooth handoffs i n mobile ip. In Proceedings of the Fourth IEEE Symposium  on Computers  and  Communications,  J u l y 1999. [17] S. B a a t z . Handoff support for mobility w i t h ip over bluetooth. In 25th Annual Conference  on Local Computer Networks  (LCN '00), Tampa, November 2000.  [18] A . Aggarwal, M . K a p o o r , L . Ramachandran, and A . Sarkar. Algorithms for wireless ad hoc networks. In Proceedings of the 4th International Discrete Algorithms  and Methods for Mobile Computing  and  Workshop  on  Communications,  pages 54-63, Boston, M A , August 2000. [19] T . Salonidis, P. Bhagwat, L.Tassiulas, and R . L a M a i r e . Distributed topology construction of bluetooth personal area networks. In Proceedings of the Twentieth Annual  Joint  Conference  of the IEEE  Computer  and  Communications  Societies, 2001. [20] Bluetooth  specification  version 1.1. Retreived from http://www.bluetooth.org  on M a y 21, 2003. [21] IEEE  802.15  Working  Group  for  WPAN  standards.  Retrieved from  http://grouper.ieee.org /groups /802/15 on June 7, 2004. [22] A . M i s h r a , M . Shin, and W . A r b a u g h . Ieee std 802.11 - wireless lan medium access control (mac) and physical layer (phy) specifications. The Institute of Electrical  and Electronics  Engineers,  Inc., 1999. 93  • "  [23] IEEE  802.11  Working  Group  Task  Group.  Retrieved  from  h t t p : / / g r o u p e r . i e e e . o r g / g r o u p s / 8 0 2 / l l / m a i n . h t m l on M a y 21, 2003. [24] M . Ergen. IEEE 802.11 Tutorial. U C Berkeley, June 2002. [25] C . L a w , A . K . M e h t a , and K . S i u . Performance of a new bluetooth scatternet formation protocol. In ACM Symposium Computing,  on Mobile Ad Hoc Networking  and  L o n g Beach, C A , October 2001.  [26] G . T a n and J . G u t t a n g . A locally coordinated scatternet scheduling algorithm. In 27th Annual IEEE Conference on Local Computer Networks  (LCN), Tampa,  F l o r i d a , November 2002. [27] T . Hodes, M . Newman, S. M c C a n n e , R . K a t z , and J.Landay. Shared remote control of a video conferencing application: M o t i v a t i o n , design, and implementation.  SPIE  Multimedia  Computing  and Networking  (MMCN),  3654:17-28,  January 1999. [28] T . Hodes and R . K a t z . A document-based framework for internet application control.  In 2nd USENIX  Symposium  (USITS),  pages 59-70, 1999.  on internet  Technologies  and Systems  [29] B . Myers, H . Stiel, and R . Gargiulo. Collaboration using multiple pdas connected to a pc. Supported [30] Interactive  In Proceedings  Cooperative  CSCW'98:  ACM  Conference  on  Computer-  Work, pages 285-294, Seattle, W A , November 1998.  Workspaces. Retreived from http://graphics.stanford.edu/projects/iwork  on January 3, 2003. [31] J . Rekimoto.  A multiple device approach for supporting whiteboard-based  interactions. In Human Factors in Computing  Systems (CHI), pages 344-351,  1998. [32] T . Salonidis, P . Bhagwat, and R . L a M a i r e . Distributed topology construction of bluetooth personal area networks. In IEEE Infocom, 2001. [33] C . L a w and K . - Y . Siu. A bluetooth scatternet formation algorithm. In  GLOBE-  COM, pages 2864-2869, 2001. [34] simjava. Retreived from http://www.dcs.ed.ac.uk/home/hase/simjava/ on A u gust 15, 2003.  94  [35] Z . W a n g , R . Thomas, and Z . Haas.  Bluenet - a new scatternet formation  scheme. In Proceedings of the 35th Annual Hawaii international  conference  on  system sciences, IEEE, 2002. [36] G . Zaruba, S. Basagni, and I. Chlamtac.  Bluetrees-scatternet  formation to  enable bluetooth-based personal area networks. I n IEEE Int. Conf.  Communi-  cations, pages 273-277, 2001. [37] H . Velayos and G . Karlsson. Techniques to reduce ieee 802.11b handoff time. In Proceeding of IEEE ICC, Paris, France, June 2004. [38] A . Soltanian and T . H a l l . Wireless Communication simulator  for Bluetooth  and 802.11b.  Technologies:  N I S T , W C T G , 2002.  Co-existence  Retrieved from  http://w3.antd.nist.gov/wctg/bluetooth/btint.html on August 20, 2004. [39] M o b i l i a n Corporation.  Wi-Fi  Coexistence Approaches,  2001.  [40] IEEE  802.15,  (802.11b) and Bluetooth:  Co-existence  Task  group.  An Examination  Retrieved  of  from  h t t p : / / w w w . i e e e 8 0 2 . o r g / 1 5 / p u b / T G 2 . h t m l on November 7, 2003. [41] C . Chiasserini and R . R a o . Co-existence mechanisms for interference mitigation between ieee 802.11 wlans and bluetooth. In IEEE Infocom, New Y o r k , June 2002. [42] M . Albrecht, M . Frank, P . M a r t i n i , M . Schetelig, A . Vilavaara, and A . Wenzel. Ip services over bluetooth: Leading the way to a new mobility. In Proceedings of the 24th Conference  on Local Computer  Networks,  pages 2-11, Lowell, M A ,  October 1999. [43] Y . M i n - h u a , L . Y u , and Z . H u i - m i n . T h e mobile handoff between h y b r i d networks. In The 13th IEEE International Mobile Radio Communications,  Symposium  on Personal,  Indoor and  September 2002.  [44] M . B u d d h i k o t , G . Chandranmenon, S. H a n , Y . W . Lee, S. M i l l e r , and L . Salgarelli. Integration of 802.11 and third-generation wireless data networks. In Proceedings of the IEEE INFOCOM,  A p r i l 2003.  [45] S. Sharma, I. Baek, Y . D o d i a , and T . Chiueh. O m n i c o n : A mobile ip-based vert i c a l handoff system for wireless l a n and gprs links. I n International on Network Design and Architecture,  August 2004.  95  Workshop  [46] S. C h a k r a b a r t i , S. Vuong, L . W u , and V . Leung. A remotely controlled bluetooth enabled environment. In 1st IEEE  Consumer Communications  and Net-  working Conference, January 2004. [47] S. C h a k r a b a r t i , S. Vuong, L . W u , and V . Leung. A remotely controlled wireless enabled environment. In 1st IEEE  Consumer Communications  and Networking  Conference, January 2004. [48] R . Droms. Dynamic  Host Configuration  Protocol. Bucknell University, M a r c h  1997. Retrieved from R F C 2131. [49] C . E . Perkins.  Tutorial on Mobile Networking  Through Mobile IP.  Sun M i -  crosystems. [50] R . Hsieh, Z . G . Zhou, and A . Seneviratne. S-ip: a seamless handoff architecture for mobile ip. In Proceedings of IEEE INFOCOM,  2003.  [51] C . E . Perkins. IP Mobility Support for IPv4- Sun Microsystems, August 2002. R F C 3344. [52] M . Stemm and R . H . K a t z . Vertical handoffs i n wireless overlay networks. In ACM [53] GPRS  Mobile Networking, Tutorial.  (MONET),  1998.  Retrieved from http://www.morgandoyle.co.uk on June 5,  2004.  *  [54] C . Bettstetter, H . Vgel, and J . Eberspcher. Radio Service GPRS:  t  Architecture,  Protocols,  GSM Phase 2+ General and Air Interface.  Packet  Technische  Universitt M n c h e n ( T U M ) . [55] S. C h a k r a b a r t i , S. Vuong, A . Sinha, and R . P a u l . Convergence i n bluetooth and 802.11 networks. In International  Conference on Software,  and Computer Networks (SoftCOM),  October 2004.  96  Telecommunications  Appendix A  Abbreviation ACL AP BD BER  Meaning Asynchronous ConnectionLess Access Point Bluetooth Device B i t E r r o r Rate  BluePAC CIR COA CSMA CA DUN DAC FIFO FA  Bluetooth P u b l i c Access Carrier Interference R a t i o Care O f Address Carrier Sense M u l t i p l e Access Collision Avoidance D i a l U p Networking Device Access Code First In First O u t Foreign Agent  FH-SS  Frequency Spectrum  Hopped  GFSK  Gaussian Keying  Frequency  GGSN  gateway G P R S General Packet Host Controller Home Agent Home L o c a t i o n  GPRS HCI HA HLR IETF LMP  Shift  support node Radio Service Interface Register  Internet Engineering Force L i n k Manager Protocol  97  Spread  Task  Abbreviation  Meaning  L2CAP  Logical Link Control and Adaptation Protocol Layer of Software Control Mobile Ad-Hoc Network Medium Access Control Mobile Host Master Connected to Internet Master Device List Personal Area Network Packet Control Unit Quality of Service A Remotely Controlled Bluetooth Enabled Environment Service Discovery Protocol Synchronous Connection Oriented serving G P R S support node Slave Device List Time to Live Visitor Location Register Wireless Local Area Network  LSC MANET MAC MH MI ML PAN PCU QOS RCBTEE SDP SCO SGSN SL TTL VLR WLAN  98  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0051058/manifest

Comment

Related Items