Handoff in Bluetooth Public Access Networks

DUAL DEGREE PROJECT STAGE 1

1

Handoff in Bluetooth Public Access Networks Aman Kansal Guide: Prof. UB Desai Abstract—Bluetooth is being used to provide access mechanisms which allow users to connect to the internet or other networks at public places and in office buildings. Users in these networks may move from the range of one access point to another. This paper addresses the problems in supporting handoff for mobility in Bluetooth based public access networks. The possibility of adapting existing handoff and mobility methods from the internet and cellular networks is first studied. Then, the properties of connection establishment and channel sharing specific to Bluetooth are described, as relevant to handoff. The contributions of this paper are twofold. First, the characteristics of an ideal handoff algorithm are proposed and the parameters on which this may be based are mentioned.Second, two new handoff protocols are proposed. The issues to be simulated and the necessary tools to be developed for simulations are noted.

fines the direction for future work. The next section aggregates the ideas in existing methods for supporting mobility in internet and cellular telephony. Comments regarding the feasibility of adapting these to Bluetooth Public Access (BluePAC) networks are made. Section III describes the specific details of connection establishment in Bluetooth which are relevant to handoff. Section IV proposes the characteristics of an ideal handoff algorithm and two new handoff protocols. Issues to be researched in these and the simulation tools required are described in section V. Section VI concludes and lays the framework for the further stages of the project.

Keywords—Bluetooth, handoff, mobility, public access.

II. E XISTING

I. I NTRODUCTION HE increasing computational power of handheld and other mobile devices has rapidly increased their popularity among users. It is now being attempted to enable these devices to connect to information networks for enabling a host of services not possible in stand alone mode or through temporary wired connectivity to a PC. Bluetooth tries to address this need by providing an open standard which is cheap and easy to implement on portable devices. To enhance the utility of handhelds, attempts are being made for providing connectivity to the internet and virtual private networks at public places. The basic usage model is that users carrying mobile devices enter or leave a public area such as a supermarket, airport, museum or railway station, and connect to certain access points using Bluetooth connectivity. These access points then allow the handhelds to use the wide area network. Public access situations may be divided into low user mobility and high user mobility scenarios. Examples of low user mobility include situations in which a person is seated most of the time, such as a train, airplane, hotel lounge or other waiting area. High user mobility may occur at supermarkets, museums and airports. In low user mobility areas a trivial way to support mobility is for the user or the application to start a new connection each time the user moves to a new location. In high mobility scenarios this becomes impractical. Thus, automatic and fast handoff is required as the user moves from the range of one access point to another. In this research, handoff protocols for achieving fast handoff without making excessive demands on the data bandwidth or computational resources are being studied. This report summarizes the first stage of the project and de-

METHODS

Mobility support is provided in cellular telephony networks and in packet networks using different means. The handoff ideas employed in these, are described below and their applicability to handoff in high mobility BluePAC scenarios is explored.

A. Mobile IP Mobile Internet Protocol (Mobile IP) [1] was designed to allow mobile nodes to connect at locations other than to which they usually connect. Connecting at a new location involves setting up a foreign agent at the new location and a home agent at the usual location. All traffic addressed to the mobile node travels to the home agent, which tunnels it to the foreign agent. The mobile device thus receives data from the network through its home agent and foreign agent. This method was intended for users traveling from one place to another and connecting their computers from multiple locations. The shift from one location is slow and infrequent. The detection of the loss of connection depends on the timeout period for route caches. The method is well suited for the internet as it supports global mobility, is simple and scalable. Using this method for supporting Bluetooth handoff in a local area would mean that each time a node moves, its foreign agent changes. The change will be affected when the route cache expires. The “handoff” will be very slow. This kind of a solution does not allow most running applications to continue oblivious to the handoff. Thus, fast and seamless handoff cannot be supported using Mobile IP alone.

DUAL DEGREE PROJECT STAGE 1

2

B. Cellular Telephony Mobility is well supported in cellular telephone networks and ongoing calls are maintained even as the mobile station moves from the range of one base station to another. These networks do not rely on loss of connection to initiate handoff but actively track the link quality to check when a handoff may be required. Various parameters such as bit error rate (BER), carrier-to-interference ratio (C/I), distance, traffic load, signal strength or combinations of these may be used for link quality evaluation. Temporal averaging signal strength based handoff algorithms are most common. These measure the received carrier power plus the interference (C+I), and might not be optimal for interference limited systems, but are used due to the difficulty of measuring C/I. These schemes are introduced in [2] and the references therein. These are difficult to employ in Bluetooth because: 1. The Bluetooth hardware will have to perform link quality measurements. The standard does provide the provision for Received Signal Strength Indicator (RSSI), but this is an optional feature and is currently not supported by most available hardware implementations. 2. The mobile station is required to carry out link quality measurements and assist the handoff algorithm. It is preferable if the handoff procedure be designed which does not require anything to be implemented on the mobile node, because a large variety of mobile nodes is expected to be present at a public place. Schemes based on BER may be explored. The reliability of these schemes needs to be determined. The bit errors are taken care at the lower layers of Bluetooth depending on packet type chosen and it might be necessary for the handoff algorithm to fix a particular packet type to be used. C. Cellular IP Cellular IP [3] is a protocol that allows routing IP datagrams to a mobile host. The protocol is intended to provide local mobility inside the access network. It can interwork with Mobile IP to provide wide area mobility support. Cellular IP (CIP) uses certain concepts from cellular telephony and Mobile IP to combine the advantages of both approaches. The handoff is faster and more efficient than in Mobile IP, and is based on a simpler and flexible infrastructure compared to that of cellular telephony. The handoff is not seamless and packet losses may occur during or after the handoff. C.1 CIP in BluePAC The CIP protocol has been used for BluePAC in [4] for supporting handoff. The reference architecture used in [4] is shown in Figure 1.

Fig. 1. Cellular IP for BluePAC

The BluePAC area network (BAN) shown as a cloud in the figure is the fundamental component of the network, which is accessed by the mobile Bluetooth nodes. The base stations are the access points having an interface to the BAN and atleast one Bluetooth transceiver. The BAN is connected to a public network like the internet through the BluePAC Gateway. The BluePAC agent coordinates the communication with arriving mobile nodes, and assigns them IP addresses. C.2 Mobility CIP provides fast route updates to enable mobile nodes to change their point of attachment frequently. The CIP protocol notices all IP datagrams sent by the mobile node and maps its source IP address to the base station interface from which the datagram was received. This prepares the route lookup table for reaching that mobile node. If the mobile node does not have anything to send for sometime then it must send control packets to refresh the routing caches. To enhance scalability, the routing caches for inactive nodes are separated. These are called paging caches and are updated less frequently, saving valuable wireless bandwidth. Thus, CIP solves the problem of local mobility within the BAN. Mobile IP may be used for global mobility. C.3 Comments The ideas presented above are good for applications which can tolerate certain handoff delay and packet loss. However, this method suffers from the following drawbacks: 1. The Cellular IP protocol must run on the mobile nodes as well. This is not preferable for public access networks as many different mobile devices may have to be served. 2. The handoff is not totally seamless. The handoff is based on route cache timeout. The Bluetooth link supervision timer is suggested for detecting loss of connection. This

DUAL DEGREE PROJECT STAGE 1

timeout value is 20 seconds by default. Thus packet loss and delay occur. In the simulations in [4], handoff times achieved are of in the range of 25 to 45 seconds. 3. After loss of a connection, the mobile node has to search a new access point, which will then switch role from slave to master. However, the mobile node has no previous knowledge of access point addresses and will thus have to use the time consuming inquiry procedure to obtain that information. Further, access points will periodically have to enter inquiry scan and page scan procedures, expecting new devices, even when there is no handoff taking place. 4. Applying Cellular IP to Bluetooth, without taking into account the specific features of this standard, may not lead to the best possible results. Better handoff performance may be obtained if the specific features of Bluetooth are exploited. The above discussion shows that though certain handoff methods are available, their use in Bluetooth handoff is limited and better methods, which allow faster handoff, are required. III. B LUETOOTH S PECIFIC I SSUES This section describes the channel sharing and connection establishment details in Bluetooth which are relevant to handoff procedures. These details will be used in designing suitable protocols for fast handoff. A. Connection Establishment Connection establishment in Bluetooth [5] consists of two phases: Address Discovery: This phase is required if the address of a device to which a connection is required is not known. This phase is referred to as “inquiry procedure” in the standard. This typically takes 10 seconds. Synchronization: This phase is required to synchronize the frequency hop sequences of the devices among which the connection is being set up. The device which starts the connection is called the master and the other device is called the slave. The slave’s clock and hop sequence are matched to that of the master. This process may take upto 1.28 seconds if the clocks of the master and slave were synchronized to within
   to   . Else, it may take upto 2.56 seconds. These timings are in the absence of channel errors. In the standard, this phase is referred to as the “paging procedure”. Assume that the device address is known, either through the inquiry procedure or otherwise. The issues in deciding which device should be master are discussed later. The paging procedure is described here as this is expected to be the significant cause of delay in handoff.

3

A.1 Paging For paging, the device which wants to initiate the connection, that is, the master, will start sending page messages. These will be sent at the page hop frequency sequence. The device which is being connected to, a prospective slave, should be scanning for page messages. The scanning device scans for page messages for a time !#" , once in every $%##&!#" . The values of these times depend on which scan repetition mode (SR) is being used, which are shown in Table I. TABLE I PAGE

SR Mode R0 R1 R2 Reserved

SCAN MODES

continuous

(')*+!#" 01  03 4 5 6

,- , no SCO ./ .12  .3 5 6

-

-

The scanning device scans for page messages at one frequency out of the page hop sequence. The 7 page hop frequencies are divided into train A and B. Train A consists of the frequency at which the paging device has estimated the scanning device to be listening and 25 other frequencies around this, in the page hop sequence. Train B consists of the remaining frequencies. Since the master does not know when the scanning device will enter page scan, it pages at the train A frequencies ,  number of times. The ,  required is shown in Table I, for different modes. For instance, in mode R1, the scanning device will listen for page messages once every 1.28 seconds. The listening duration will be long enough for the paging device to cover 6 frequencies. As the paging device pages at two frequencies in one slot and listens in each subsequent slot, 26 slots are required. So 8!#" will be atleast 10 ms ( 26 slots). This means that the paging train A should be repeated atleast 2  times, hence the value of ,9%## . It will be sufficient to scan at Train A, if the difference between the clocks of the paging and scanning devices is between
:;  and  frequency in train A. The paging device is trying 16 frequencies of train A. The page procedure will be successful as soon as a page packet is sent at the scanning frequency when the scanning device is listening. This occurs when the page and scan overlap for the second time in the figure, at %? =&> frequency of train A. In a public access network, once the connection has been established at one location, we may assume that at all other access points, the clock estimate will be such that Train A will

DUAL DEGREE PROJECT STAGE 1

4

T page scan Tw page scan

Tw page scan

f 13

f 14 Scanning Device

A

listens for packets from slaves in intermediate slots. This is shown in Figure 3.

A

A

matched at 14th member of train A A

A

Paging device Fig. 2. Paging procedure example

succeed. Paging is the main bottleneck, in terms of minimizing delay, at the Bluetooth layer to start a connection with a new access point during handoff. This was verified through actual tests on Bluetooth hardware. Experiment: An automated version of the connection establishment procedure was implementer on Ericsson’s Bluetooth modules rok 001007, attached to computers on the Universal Serial Bus (USB). It was observed that: 1. The inquiry procedure, to discover the addresses of the devices in range took approximately 10 seconds. The duration of inquiry was also reduced to 5 seconds, in which case inquiry was not always successful in the first attempt. This leads to the conclusion that if inquiry procedure is part of the handoff protocol, a minimum delay of 10 seconds should be expected in each handoff. This is certainly not desirable if the handoff is intended to be seamless for the user. Thus, a separate option should be available for discovering the address of the mobile nodes during handoff. 2. The paging procedure took 1 second on an average. This will be the minimum delay in any new connection establishment as is is necessary to synchronize to a master before any communication can take place. Apart from the time wasted, precious wireless bandwidth is consumed in paging, and the handoff procedures should be designed taking this into account. A.2 Channel Sharing This section describes the channel sharing procedure in Bluetooth. The wireless channel is time division duplex and further time shared among devices connected to one master. All these devices are synchronized to the master’s clock and following a common frequency hop sequence. The channel access is controlled by the master in each piconet. A slave can transmit only after it receives a data packet or poll packet from the master. The master sends out packets in alternate slots and

Fig. 3. Wireless medium access control within the piconet

Thus, whenever an access point has to engage itself in a page procedure, whether as a scanning device or as a paging device, it will have to sacrifice slots. The handoff procedure should be such that wastage is minimized. B. Who should be master The issue whether an access point should be a master or a slave is discussed here. As seen above, more slots are required for paging than to scan. Thus, it may be a good idea to make the access point a scanning device, as shown on the right in Figure 4. This has the further advantage that a device can connect to an access point whenever it wants. The disadvantage is that the access point has to involve itself in multiple piconets and hence its capacity goes down as time and bandwidth is wasted in switching between piconets. Further, the handoff protocol designed for this approach will be controlled by the mobile nodes and all these should cooperate for optimal and fair performance. The access point may be made the master. This sets up a single piconet consisting of the access point and the mobile nodes. This is shown on the left in Figure 4. The medium can be effectively controlled by the access point. The handoff protocol can now run on the access points and various access points may coordinate to achieve fast handoffs. The disadvantage is that the access point has to do the paging, which wastes a lot of bandwidth. A hybrid approach is suggested in [4], which makes the access point a scanning device at the start of connection. As soon as the paging procedure succeeds, a master slave switch

DUAL DEGREE PROJECT STAGE 1

5

Base Station (slave)

Base Station (master) (slave)

(master) mobile node (slave)

(master) (slave) (master) Fig. 4. Master Slave conflict

is performed. The choice of who should be master needs to be made considering the various issues involved in handoff. IV. P ROPOSED I DEAS A. Design Considerations The aim is to design a fast and seamless handoff algorithm. Taking into account the limitations of the Bluetooth layer, it is being attempted to achieve the handoff in as small a time as possible. First, the traits that should be desirable in an ideal handoff algorithm are proposed. The possible indicators that may be used to determine when a handoff is required are studied next. Finally, an attempt is made to suggest handoff algorithms that closely match the ideal characteristics. These exploit the Bluetooth specific features to optimize performance. A.1 Desirable Traits The following traits are perceived to be desirable for a handoff algorithm to be used in a public access network. 1. The handoff should take place very fast. Data applications and higher layer protocols such as the TCP, should not be affected by a handoff occurring at the wireless physical layer. Streaming data applications should require small buffer sizes. It would be excellent if real time voice or multimedia applications may be supported. 2. The handoff protocol should not consume a significant bandwidth of the wireless channel. Ideally, the data packets themselves should be exploited for its measurements and control. 3. The handoff protocol should be universal. In a public access network, it is desirable if the protocol can function through modifications to only the access points, rather than to the mobile nodes. 4. The protocol should be based on only the standard Bluetooth features. Optional features should be avoided so

that the protocol may be implemented over most available hardware modules. This enhances its usability and portability. 5. The protocol should not require excessive coordination among access points This is to save bandwidth in the network connecting the access points as they may themselves be connected wirelessly for ease of deployment. 6. The protocol should not rely on the use of a central server which tracks locations or other properties of mobile nodes as this not only reduces the scalability and robustness but also wastes bandwidth in the network connecting the access points. Apart from these characteristics, the protocol should also be simple and robust to work on handheld battery operated devices, constrained on computational power and memory sizes. A.2 Basis for Handoff Mechanisms Handoff may be initiated based on measurements of any of the following. Signal Strength: It is expected that diminishing signal strength would mean that the mobile node is moving out of range. The received signal strength indicator (RSSI) provided in the Bluetooth standard may be used by the handoff algorithm. However, RSSI is only an optional feature for the 0dBm devices, which are by far the most common Bluetooth devices today. Hence, the use of RSSI reduces the portability of the protocol. Bit Error Rate: The protocol may use data packets without lower layer error check and retransmissions and use the channel bit error rate to determine whether a mobile node is moving out of range. Cache timeout: The access point may keep track of when it stops receiving data packets from a mobile node to detect that it has moved out of its range. To allow the use of a small timeout value, control packets may be sent when a node does not have data to be sent for more than the timeout duration. Predicted movement: It may be possible to predict the motion of the mobile node in an area based on movement constraints or using past and learned mobility patterns of a user. These may be used to initiate handoff. Further, hybrid methods, based on combinations of the above criterion may be used. B. New Proposals Based on the ideal characteristics proposed for a handoff protocol, signal strength based methods are not considered for the proposed designs. The following new protocols are proposed, which may be implemented using only the standard features of Bluetooth.

DUAL DEGREE PROJECT STAGE 1

6

access point. Each of these access points pages for the mobile node using the clock record passed the old access point. The paging procedure is not reattempted and it is assumed that if the paged device is not found, another access point must have found it or the node would have moved out of the range of the public access network. As a very recent clock record is used, paging will succeed in the first attempt. Hence, the connection can be resumed within 1.28s. The neighborhood set of an access point Y is defined as the set of all access points into whose range a mobile node may have ventured after having been known to be present in the range of access point Y ,  !!@ACBEDZFHIKJ2B time units ago. The neighborhood set will depend upon the space in which the access network is deployed. Figure 5 shows the floor plan of an exhibition hall. Consider the access point Y marked in the figure. It is clear that a mobile node which was in the range of Y , 10ms ago can have moved to only the access points marked [ now. This constraint on motion posed by the space layout is exploited to optimize the handoff protocol.

B.1 Next Hop Handoff Protocol (NHHP) This protocol uses the concept of Cellular IP in determining when a handoff is to be initiated. However, it eliminates the inquiry procedure, which causes significant delay and wastes a large fraction of the wireless channel bandwidth, since the access point has to suspend data communication while in inquiry. Also, it does not requires the access points to periodically enter scan mode even when there is no handoff taking place. The description of the channel sharing scheme to be used, selection of master and scan modes to be used for this protocol are specified below. The Bluetooth access points are divided into two categories: 1. Entry Points: These are located at the boundaries of the network, where mobile nodes enter or leave the public access network. These are essentially access points but with their resources dedicated to discovering new devices through inquiry. 2. Access Points: These are located in the internal regions, where devices are accepted only through handoff. The protocol consists of two activities: Entry: The entry point constantly carries out inquiry. Whenever it detects a new device it establishes a connection with it, obtaining its address and clock information. It also informs the mobile node to use page scan mode R1, which is a mandatory scan mode and must be supported by any Bluetooth device. The entry point closes the connection and passes the address and clock information received from the newly arrived mobile node to the nearest access point. The access point temporarily suspends its data communications and pages the new device. As the address and clock information are known, the page procedure will succeed in train A itself and upto 1.28 seconds will be used. Handoff: Handoff consists of two steps: Detecting loss of connection: The cache timeout method for detecting loss of connection is suggested to be used. Timeout value,  !!@ACBEDGFHIKJB , is specified at 16 slots, or 10ms. This is to be used with round robin scheduling algorithm for polling the slaves, in which the master polls each slave one after the other regardless of the data traffic for each. If the slave does not have a packet to send, it should reply with a null packet. The rationale for choosing this timeout value and polling scheme is as follows. A piconet and hence one access point, may cater to atmost seven devices and hence by using the round robin polling, each slave will be polled atleast once every 14 slots. If the slave does not reply, it is assumed to have moved out of range. Restoring connection through new access point: Once the loss of connection has been determined, new connection must be established. The access points contained in the ,ML2NPOQ>SR#TAU >VTWTWX- 2L2= , defined below, are alerted by the old

P P

A

_ a]`_ a] `] b a] b ab a]`_ a] `_] b a] b ab `_]`_

P

P

\] ^^ \\^^ \]\] \]

P Entry Point Access Point

Fig. 5. Sample arrangement of access points and entry points in a Bluetooth access network running NHHP

One disadvantage of this protocol is that it produces a hard separation between entry points and access points. So, if a mobile node originates within the interior of the network, say because of a user switching on a handheld after entering the region, special connection initiation is required. B.2 Path Controlled Handoff (PCH) This is an intelligent handoff protocol which predicts the sequence in which a mobile node will require the various access points in the access network, and initiates handoff based on its

DUAL DEGREE PROJECT STAGE 1

7

estimates of the time durations the mobile node will spend at each access point. This protocol is expected to be faster and more bandwidth efficient that the NHHP. The protocol consists of two activities: 1. Prediction of the access sequence and durations. 2. Executing connection transfer between two access points in the sequence. The second activity may be executed in a fashion similar to NHHP. When the mobile node is to be transferred to a new access point, The current access point sends address and clock information to the next access point. The new access point pages the mobile node and starts a connection. The first activity is non trivial. PCH requires the access point to determine the sequence c$d=&>egf2YihAjkYml jkYmn j%GZZo in which the access points will be accessed. Further the times spent at each access point in that order, denoted by the sequence XpmLAqrq =!NCstLW meuf2=hAjK=l jK=n j%GGvo , need to be determined. Assuming that the access points are installed in such a fashion that for the fastest moving user, it takes time  to cross the region where the ranges of two access points overlap, and the acceptable handoff delay is > , the the maximum tolerance w in the predicted values of the various = D ’s is constrained by the equation:

xe1>yzw Assume that the sequences c$d=&> and XpmLAqrq =!NPstLW

(1)

are available. Then the protocol specification is as follows. Mobile nodes enter the access network as per NHHP. When a mobile node is accepted at access point YD , it starts a timer initialized at =D{
w . At timeout, Y-D sends the address and clock information regarding the mobile node to the access point Y DZ| h . Connection transfer is conducted as per NHHP, except that instead of all access points in the neighborhood set, only Y}DG| h is involved in paging. Path Prediction Algorithm: The two input sequences c$d=&> and XpmLAqrq =!NPstL required by PCH for each mobile node may be generated in various ways. Learned path: The mobility patterns of the mobile node may be tracked each time the node enters the network. When a large number, , , of mobility patterns have been recorded, they may be matched to determine if they are similar. If they are, then the common pattern observed may be used for handoff in the future. The pattern observed may also be sorted by the time of arrival of mobile devices. For example, it may happen in a hospital, that a particular doctor always follows a particular round. Or, all doctors entering the premises at a given time may be following the same route. Constrained path: The space may be such that only a fixed path of motion is allowed and at a constrained pace. This may happen in guided visitor galleries, where the visitor

group is required to follow a known path after entering the premises. Described path: It may be possible in certain cases for the mobile nodes to inform their intended path at the entry point. One instance of a situation where this may happen is when the user asks the network to assign him a path for reaching his destination, say a particular terminal at an airport. The network may then verify if the user is following the advised path for the first few access points using NHHP and then switch to PCH. NHHP may be again be resorted to at certain points where users are expected to deviate from the path, like shopping or waiting areas. One disadvantage of PCH is that the sequences cSd=&> and X p~L2qq =!NCsL for each mobile node need to be stored. Either these will be stored at a single location and shared as and when a mobile node shows up at an entry point. Or, they have to be stored at each access point. This reduces the scalability and robustness. Another disadvantage is that because the mobility pattern of a mobile node corresponds to the mobility pattern of its user, the network running the PCH protocol may be considered to be violating the privacy of its users. In practice, it may be very difficult to predict the mobility sequences with complete accuracy. A combination of NHHP and PCH may be used. NHHP will be useful in the learning phase for PCH and for those devices whose mobility pattern does not conform to the prediction. V. S IMULATION W ORK A. Survey of Available Tools The following Bluetooth simulation tools are available in the public domain. 1. Baseband Simulator, developed at Isreal Institute of Technology, Technion. This tool simulates only a limited set of functionality from the lower layers of Bluetooth. It does not use a standard interface and might be difficult to adapt source code prepared for it to an actual hardware API. 2. NIST’s Baseband simulator and Protocol Modeller. This tool simulates the baseband layer of Bluetooth standard and aims at verifying the protocols defined in the standard. 3. Bluehoc. This is a simulation tool developed at IBM Research Labs, based on the Network Simulator (ns). Apart from baseband, it also provides simulation facility for the higher layers. The €) tools can be further used for visualization of results. The interfaces are standardized. There is no support for mobility however. B. Developing Handoff Support Tools The tools described above are not sufficient to test handoff protocols. Modules for simulating mobility of nodes need

DUAL DEGREE PROJECT STAGE 1

to be incorporated. The Bluehoc tool seems to have the best set of features for adding mobility support, and is also preferable as it allows certain existing ns tools for visualization of results. Thus, to test the simulation procedures proposed, simulation tools will be built based on Bluehoc. Tcl and C++ programming environments will be required in developing the simulation platform. The platform thus developed should have the following characteristics:  Description of mobility scenarios. The simulation will require a mobility pattern to be defined so that the motion of mobile nodes in an access network may be simulated.  Testing of handoff protocols. The simulation will require the handoff protocol to be run above the baseband/L2CAP layers of the Bluetooth stack. The tool should accurately simulate the coordination among access points and the behavior of mobile nodes. These will be used to simulate and compare the performance of proposed methods. The results will be used to modify and redesign the protocols. This work is part of the next stage of the project. C. Issues for testing The following are the important issues to be tested in the proposed protocols. C.1 NHHP In the Next Hop Handoff Protocol, the main issues to be tested are: 1. Validity: It is to be determined whether the problem of handoff is completely solved and no exceptional situation may cause an anomaly. 2. Success rate: The protocol relies on finding a mobile node which has just lost connection in one attempt within the region covered by neighboring access points. This assumption needs to be tested. The success rate achieved is to be measured through simulations. 3. Efficiency: The round robin polling scheme has been fixed and scan mode has been specified to be R1. The bandwidth efficiency attained through this choice should be tested and the possible trade-offs in bandwidth efficiency and handoff time should be explored by varying these parameters. C.2 PCH In the Path Controlled Handoff, the following simulation work is required. 1. Practical mobility scenarios that emulate the motion of mobile nodes within the environments of interest, such as museums, airports, supermarkets and hospitals, need to be generated. These will then be used in simulating the performance of PCH.

8

2. The success of path prediction algorithm in determining the sequences c$d=&> and X p~L2qq =!NCsL , defined in section IV-B.2, needs to be tested. The values of w achieved for various mobility scenarios need to be observed. Simulations may be carried out for varying  and > . 3. The improvements in bandwidth efficiency and handoff delay should be compared to those of NHHP. These should be substantial enough to justify the increased capacity. The next stage of the project aims at building the simulation tools required to test the various issues in NHHP. These will be used to simulate the above mentioned issues. The tools required for PCH may be explored in further stages. VI. C ONCLUSIONS The first stage of the project consisted of familiarizing with the Bluetooth specifications, experimenting with the connection establishment procedures on actual hardware and designing an efficient handoff algorithm. Ideas from Mobile IP, Cellular telephony, and Cellular IP have been explored and their applicability to Bluetooth has been studied. The characteristics of an ideal handoff protocol have been proposed. Two new handoff protocols have been suggested. A path prediction algorithm is also proposed, which may be useful for purposes other than the ones for which it is designed here. The shortcomings of the proposed protocols were also mentioned. These seem to be tolerable, compared to the gains promised by these protocols. The next stage will consist of testing out the NHHP issues. Validity of the protocol will be established and performance will be measured. The expected number and location of access points required for a given usage pattern will be attempted to be derived analytically using the parameters determined to be of significance through simulations. R EFERENCES [1] editor Charles Perkins, “Ip mobility support,” Internet RFC 2002, October 1996. [2] Gordon L Stubor, Principles of Mobile Communication, chapter 10, Kluwer Academic Publishers, 1996. [3] A Campbell, J Gomez, C-Y Wan, and S Kim, “Cellular ip,” Internet draft, draft-ietf-mobileip-cellularip-00.txt, December 1999. [4] Simon Baatz, Matthias Frank, Rolf Gopffarth, Dimitri Kassatkine, Peter Martini, Markus Scetelig, and Asko Vilavaara, “Handoff support for mobility with ip over bluetooth,” in Proceedings of the 25th Annual Conference on Local Computer Networks (LCN’00), Tampa, FL, USA, November 2000. [5] “Bluetooth specification version 1.1: Core,” Bluetooth SIG, http://www.bluetooth.com.