A distributed mobile database implementation on Pocket PC mobile devices communicating over Bluetooth

ARTICLE IN PRESS

Contents lists available at ScienceDirect

Journal of Network andComputer Applications

Journal of Network and Computer Applications 32 (2009) 96– 115

1084-80

doi:10.1

� Corr

E-m

journal homepage: www.elsevier.com/locate/jnca

A distributed mobile database implementationon Pocket PC mobile devices communicatingover Bluetooth

Hassan Artail a,�, Manal Shihab a, Haidar Safa b

a Department of Electrical and Computer Engineering, American University of Beirut,

P.O. Box 11-0236, Riad El-Solh 1107 2020, Beirut, Lebanonb Department of Computer Science, American University of Beirut, P.O. Box 11-0236, Riad El-Solh 1107 2020, Beirut, Lebanon

a r t i c l e i n f o

Article history:

Received 15 November 2007

Received in revised form

11 April 2008

Accepted 14 April 2008

Keywords:

Data availability

Mobile databases

Distributed database

Mobile computing

Bluetooth

45/$ - see front matter & 2008 Elsevier Ltd

016/j.jnca.2008.04.003

esponding author. Tel.: +9611350000; fax

ail addresses: [email protected] (H. Artail)

a b s t r a c t

This paper describes a distributed database system implementa-

tion built on top of stand-alone mobile databases found on mobile

devices. At the heart of the architecture are elected devices that

take on the role of data directories which collect the schema of the

databases and become the contact points for all nodes that wish

to submit queries against the distributed database. The system is

implemented on Pocket PCs that run the Microsoft WinCE

operating system and communicate using Bluetooth, thus limiting

the architecture to eight devices, which is a restriction imposed by

piconets. Sample databases were configured on the devices that

ran the SQL Server CE database engine, and a list of 170 sample

queries of varying complexities were designed to conduct

performance evaluation. This evaluation involved measurement

of query response time, generated traffic, and device energy

consumption. The obtained results indicated the feasibility of the

system and its potential for providing mobile users with a

framework for aggregating disparate data that are stored in

mobile databases in the wireless ad hoc network.

& 2008 Elsevier Ltd. All rights reserved.

1. Introduction

As mobile applications have become more ubiquitous, the demand for database data in mobilesettings has increased, and this has created a need for engineering database architectures that are

. All rights reserved.

: +9611744462.

, [email protected] (M. Shihab), [email protected] (H. Safa).

www.sciencedirect.com/science/journal/yjcna

www.elsevier.com/locate/jnca

dx.doi.org/10.1016/j.jnca.2008.04.003

mailto:[email protected]



ARTICLE IN PRESSH. Artail et al. / Journal of Network and Computer Applications 32 (2009) 96–115 97

suitable for such dynamic environments (Chan and Roddick, 2005). The most interesting andpromising form of such environments is the mobile ad hoc network (MANET) in which a mobile hostcan act as a source of information, destination, or a router that transfers data toward its destination.Mobile hosts are generally small computing devices with relatively limited resources that can join orleave the network unexpectedly at any time. In addition to the increasingly more complexapplications that are targeting such devices, more sophisticated mobile database managementsystems are being engineered to offer capabilities that parallel those of enterprise level databasesystems.

The ultimate goal of our design and implementation is to provide a system through which mobiledevices share data in disconnected settings (i.e., away from an access point that connects these hoststo a fixed network and through it to a central data source). That is, our work targets environments inwhich mobile hosts collaborate in answering each other’s queries. More specifically, we develop adistributed database system on top of isolated mobile databases that exist on the mobile devices thathappen to be in close proximity with each other. The protocol we consider for communication isBluetooth which is prevalent on mobile devices due to its low cost and efficient utilization of batterypower. The implementation of the system involved several issues relating to locating the datasources for the particular query, fragmenting the query among the participating mobile devices, andjoining the individual results by some mobile device before returning them to the client application.

The rest of the paper is organized as follows. Section 2 provides a survey of related work andbriefly describes the employed technologies in our implementation. Sections 3 and 4 describe thedesign and implementation of the system, respectively, while Section 5 presents the performanceresults. Finally, the paper is concluded in Section 6.

2. Literature overview

The developed application described in this paper tackles three main areas, namely, connectivityusing the Bluetooth communication protocol, collaboration between mobile devices, and distributeddatabases in MANETs. Accordingly, this section briefly discusses related work done in those areas.

A study of recent research trends and experimental guidelines in MANETs, which was presentedby Dow et al. (2005), surveyed more than 1300 MANET related papers from 1998 to 2003. It wasfound that topics like routing and power management attracted most of the attention, while issuessuch as IP addressing, fault tolerance, and collaboration were also popular among MANETresearchers. In the qualitative analysis covered by the studied papers, factors such as scalability,stability, and reliability were of primary concern in major MANET issues. The framework ofdistributed mobile databases addressed in this paper is collaborative in the sense that nodes (mobiledevices) cooperate by providing services to each other in order to answer a mobile node’s query.Therefore, the subject of this paper contributes to the thrust of MANET research, and provides anactual implementation on Pocket PCs that communicate using Bluetooth (BT) through the formationof a piconet, where one master device can connect with up to seven active slave devices. A set ofpiconets connected through sharing devices form a scatternet. Although proposed in the standards,this function is still not well-developed today. Several scatternet protocols have been proposed butthe BlueTrees (Zaruba et al., 2001) and BlueStars (Petrioli et al., 2003) are most known and have beenthe subject of further studies and comparisons (Amin et al., 2006; Basagni et al., 2004). Of concern toour work is the fact that current implementations of Bluetooth communication on mobile computingdevices, like Pocket PCs and PalmOS handhelds, do not support master–slave role switching, andtherefore scatternets. For this reason, our current implementation is limited to a wireless network ofeight or less devices that communicate and form a piconet structure. Similarly, previous works thatinvolved BT communication were limited to piconets. For example, Altundag and Gokturk (2006)developed a scatternet formation protocol and implemented a chat room application that utilizedthis protocol using J2ME. However, given the lack of scatternet and master–slave role switching onmobile phones, major features of the proposed protocol did not make it to the implementation, andas a result, the chat room application was restricted to work within a single piconet.

ARTICLE IN PRESSH. Artail et al. / Journal of Network and Computer Applications 32 (2009) 96–11598

Our work involves query processing and result coalescing. Several approaches have appearedthat discuss processing queries in distributed mobile environments. The scheme presented inKottkamp and Zukunft (1998) is one of such approaches. It aims to optimize location aware queriesfor mobile database systems, and develop a mobility-aware cost model that makes use of fuzzyinformation while trying to accommodate the limited resources of the mobile devices. Anotherapproach is the one described in Li (2004), which presents a cost evaluation model for joinoperations. It incorporates the primary parameters of wireless networks, including the size of thetransmitted data, the transmission distance, and the query cost at each node. To perform equi-joinoperations between nodes, the system executes a distributed query optimization procedure that iscomposed of two parts: distribution optimization and local optimization. The first is based onreducing the communication cost while the second can be done using centralized databaseoptimization techniques. In Epstein et al. (1978), a set of algorithms for processing databasecommands that involve data from multiple mobile nodes in a distributed database environmentwere proposed. These algorithms use mechanisms to process queries by breaking the qualificationinto separate pieces using simple heuristics. The considered cost criteria are response time andcommunications traffic. Finally, the work in Kossmann (2000) presents a ‘‘textbook’’ architecture forquery processing and discusses a series of specific techniques for distributed database systems. Itdescribes several methods for shipping data from one site to others, implementing joins, andselection of sites for executing the elements of the queries. The query processor receives an SQLquery, translates and optimizes this query in several phases into an executable query plan, andexecutes the plan in order to obtain the results. For query optimization, a plan enumeration wasdeveloped with dynamic programming to produce optimal plans given that the cost model issufficiently accurate. Such an algorithm has an exponential time and space complexity and istherefore not viable for complex queries, nor is it suitable for a distributed framework involvingmobile devices.

3. System architecture

The proposed system provides a cooperative framework that builds a distributed database out ofpossibly heterogeneous databases running on mobile devices that may be roaming in the wirelessnetwork in close proximity (within transmission range) to each other. In the following, basicconcepts are covered, followed by a description of the modules that were implemented.

3.1. Basic concepts

The system consists of moving nodes that can take one of three possible roles, as depicted inFig. 1: requesting nodes (RNs), database nodes (DBNs), and a database directory (DD). A DBNnode has its own mobile database and is willing to be part of the one large database. On theother hand, the DD stores the schemas of the DBNs in the network and serves the RNs throughfragmenting their queries so they can be processed by the individual DBNs. An RN can be any nodethat sends its request (query) to the DD for processing. The latter will look up its schema to identifyall the DBNs that will participate in answering the query and will fragment the query accordingly.Fig. 1 shows a general diagram that illustrates the elements of the system, in particular the DD andDBN nodes.

3.2. Data directory election

The task of fragmentation is independent of the location and size of the data, and thus decidingwhich DD to perform fragmentation does not influence the performance of the system. A DD nodemust meet some minimum criteria that involve expected time of staying in the network, battery life,and available memory. This translates into a score that each node must compute and updateperiodically. Nodes must communicate their scores to each other so that a DD is selected and

ARTICLE IN PRESS

DBN4

DD

DBN2

DBN1 Subquery

Subquery Processing

DBN3

RN4

QuerySubquery

Sub

quer

y

Subquery Processing

Subquery Processing

RN1

Que

ry

DBN5

Subq

uery

Subquery Processing

Subquery Processing

Subquery

DBNName DBNAddress SCN FTPSCN TableName Attributes Size DBN1 (00:12:D1:9B:E5:94) 09 03 Cinemas Cinema_Name,Mall_Name 105DBN2 (00:12:D1:9E:88:15) 09 03 Movies Movie_Name,CinemaName,Timings 588DBN3 (00:12:D1:9C:46:12) 09 03 Restaurants Restaurant_Name,Mall_Name,Specia 203DBN4 (00:12:D1:9C:BB:B9) 09 03 Restaurants Restaurant_Name,Mall_Name,Specia 290DBN5 (00:12:D1:28:06:83) 09 03 Malls Mall_Name,Address 153DBN5 (00:12:D1:28:32:11) 09 03 Stores Store_Name,Mall_Name,Products 852DBN5 (00:12:D1:9B:84:12) 09 03 Restaurants Restaurant_Name,Mall_Name,Specia 87

Fig. 1. An illustrative example of the proposed system and the schema structure.

H. Artail et al. / Journal of Network and Computer Applications 32 (2009) 96–115 99

becomes known to the rest of the network. The DD is the node possessing the maximum score, andpreferably not a DBN (for load balancing). Hence, a node, upon joining the network, sends itscomputed scores through a message to all nodes that it discovers, and similarly, receives the scores ofothers after being discovered. The message includes, in addition to the score, a flag indicating if thenode holds a database. Having the scores of all nodes in the network, a node with the highest score,announces its role as a DD to the other devices via a different message. This prompts all DBN nodes tosend the schema of their databases to the new DD which will in turn use them for queryfragmentation and building the query plan tree (QPT).

3.3. Coping with dynamic environments

Mobile devices in a mobile ad hoc network may be highly mobile, and could go offlineunexpectedly. With Bluetooth, departed or disconnected devices can be readily detected (discovered)by other devices. However, depending on the mobility behavior, a device that goes out oftransmission range of the other devices that it used to connect to may go back in range shortly afterdisconnection. Similarly, a device that becomes unavailable (appears to have been turned off) for ashort period of time (e.g., due to using it by its user) may go back online soon afterwards. These


scenarios suggest that the discovering device(s) wait a period t before an action is taken, asillustrated below.

If a DD goes offline, it gets detected shortly afterwards by all devices that had it in theirtransmission ranges. If a period t passes without this device (i.e., DD) coming back into range, areplacement DD will announce its new role to the rest of the devices in a manner similar to how thedisconnected DD was chosen. Upon learning about it, the DBNs will send it their schemas. In terms ofimpact on performance, the loss of a DD will possibly cause a delay experienced by the RN.Specifically, if a DD disconnects before it completely dispatches the query fragments to theparticipating DBNs, and does not return within the allowable time t, the overall query will be lost,and the RN will have to resend the query to the new DD after it times out. On the other hand, if theDD disconnects after the generation of the QPT and sending the queries to the participating DBNnodes, the remainder of the query processing will not be affected, and as a result, the RN will notexperience any resultant delay.

In case a DBN goes offline for longer than a period t, the DD will simply remove all entries in itsschema table that reference the departed DBN node. This implies that if there is a query in progressthat involves this DBN, it will simply be answered by the remaining participating DBN nodes, if any.For this to work effectively, the DD has to notify the rest of the participating DBNs and send them anupdated QPT. This will serve to inform a DBN that was supposed to receive intermediate results fromthe disconnected DBN not to wait any further, and to proceed to the next step (i.e., send its output toanother DBN in order to perform a join or a union, or to the RN). The DD notification will also informa DBN that was scheduled to send its output to the disconnected DBN to send it to the designatednode as specified in the updated QPT. It is noted that in all situations a completeness index flag will bewritten to the XML results file that will be returned to the RN to inform the user if the receivedresults are not 100% complete. This flag will have a value of 1 if the results are complete or 0 if theyare incomplete (i.e., because of the departure of one or more DBN nodes).

3.4. Query processing procedure

The task of performing query processing in a distributed database environment reduces todeciding on a strategy for executing each part of the query over the network in the most cost-effective way. The process consists of the following steps: (1) query fragmentation, (2) QPTgeneration, and (3) result generation and joining into one set. If there are unions and/or joinsinvolved, and after constructing the QPT, the DD will include in each query fragment sent to aparticipating DBN the addresses and channel information of all participating DBN nodes along withflags that specify the type of joint operation (i.e., union or join). This will imply to those DBNs thatthey must communicate to each other the sizes of their intermediate results in order to identify theone holding the largest dataset. That DBN will then be the receiver of intermediate results and thenode to actually perform the union or the join.

The decomposition of the user query into subqueries on distributed relations is accomplishedusing the information in the schema of the DD that describes the distribution of the relations amongthe DBNs. The DD uses an algorithm that recursively breaks up the query into smaller pieces: a queryis first decomposed into a sequence of subqueries each having a unique relation (monorelation) andone multirelation query. Each monorelation (Ri) and the address of the DBN that will execute it willbe added to a list of subqueries. Next the multirelation query (R0) is divided into a set of subquerieseach having only one join condition. Once the decomposition process is completed, a QPT is built thatspecifies the hierarchy of subquery execution. In a QPT, the monorelations occupy the leaf nodes ofthe tree, as illustrated in the example of Fig. 2. The procedure starts by processing all monorelations,followed by performing the union operations between similar tables, and finally the joins. Asillustrated in the figure, nodes that are involved in binary operations (unions or joins) will determineat runtime (i.e., during the execution of the distributed query) the senders and receivers ofintermediate results, with the overall objective of minimizing the amount of generated networktraffic.

ARTICLE IN PRESS

All leafnodes are

monorelations

R1

U

R2R

U

Determine at runtime:If Size(R1) < Size(R2) transfer results of DBN1 to DBN3 else transfer results of DBN3 to DBN1

DBN 1DBN 1 DBN 3

Parent

Leftchild

Rightchild

R1

U

R2

DBN 1 DBN 3

Parent

Rightchild

J

R3

Left child

Determine at runtime:If Size(IntRes) < Size(R3) transfer IntRes to DBN6 else transfer results of DBN6 to DBN1 or DBN3

DBN 6

OR

OR

Fig. 2. Building a query plan tree. The symbol U denotes a union while J signifies a join.


4. Implementation

The developed application employs Bluetooth for communication. As part of BT, the OBEXprotocol is used for transferring data objects such as XML files between devices. The application wasdeveloped using the C# language along with the .NET Compact Framework available on all newPocket PC and Smartphone device ROMs. For the database engine running on the devices, the SQLServer CE was chosen because it serves the purpose and it integrates well with the .NET CompactFramework and the Visual Studio .NET 2005 development environment.

The development environment, however, does not offer a library for BT communication support.For this purpose, Franson Bluetools (www.franson.com), implemented as a C# API and supportingthe Microsoft and Widcomm stacks, was used. Related to the choice of the programming language,C# was chosen because it is the primary language supported by the .NET Compact Framework, whichin turn represents the native development platform for Pocket PCs. Moreover, and as was justmentioned earlier, the Farnson Bluetools BT communication library is implemented using C#, whichbasically made this language the obvious choice.

4.1. Application structure

The system consists of three applications: RNApplication running on all devices since each devicecan be a RN. The DDApplication only runs on the data directory node (DD), and similarly, theDBNApplication runs on the DBNs. These applications were implemented as services (serial port type)that advertise themselves for other devices to connect to and initiate requests. Once advertised,devices can discover the services exposed and connect to them when needed. Only the RNApplication

has a Graphical User Interface, while the others only run in the background. The RN service isresponsible for creating requests while the DD service is in charge of analyzing those requests andgenerating subqueries and plan trees to be sent to the DBNs. The DBN service receives subqueriesfrom the DD service, generates intermediate or final results and sends them to another DBN or the RNservice, respectively.

4.2. Handling incoming and outgoing DBNs

The process of handling incoming DBNs in the network is described in Fig. 3. Basically, it is the DDnode that is responsible for detecting incoming and outgoing DBNs. When the DDApplication loads, it

http://www.franson.com

ARTICLE IN PRESS

Fig. 3. Process diagram for handling incoming DBNs.

H. Artail et al. / Journal of Network and Computer Applications 32 (2009) 96–115102

performs a device discovery and initiates a timer that performs the discovery process every specifiednumber of minutes to handle new comers and detect departed devices. When a new device isdetected, its name and address are stored in a NetworkDevices list on the DD, which is designed fortemporarily storing newly detected devices.

After device discovery is complete, all newly detected devices that start with the name DBN areselected from the NetworkDevices list. The DD then sends a RequestDBNSchema message to the firstDBN entry using the stored address and waits for an acknowledgement containing the name of thefile that has the DBN’s schema. Once the DD receives the acknowledgement, it deletes the DBN’sentry from the database list, extracts the name of the schema file, creates a DBNSchema database, ifone is not already created, and starts reading the records from the schema file on the DBN andinserting them into the DBNSchema database. This process repeats until all the DBN schemas areretrieved. After the insertion of all schema records is over, an XML file with all the available DBNschemas in the network is built. When this file is generated or modified, it gets communicated to allother nodes in the piconet on demand, as shall be described in the next subsection. This will allow auser who wants to submit a request to be presented with a GUI that reflects the type of data that areavailable in the network. Finally, we note that device discovery is repeated periodically so as to detectincoming and outgoing devices.

A device may leave the network in two scenarios: (1) when the DBNApplication running on thedevice is shut down, or (2) when the device gets out of range. In the first situation, on closing, itconnects to the DD and deletes its schema file. In the second situation, the DD detects it as lost whendevice discovery is performed. In both cases, the DD updates its DBNSchema database and informsthe remaining nodes about the existence of an updated schema file.

4.3. Data request procedure

Through the user interface, when the user taps on the ‘‘Get Available Data’’ button (Step1 in Fig.4), the RNApplication directly connects to the DD, retrieves the schema file, and generates a selectiontree with all the relation names and their respective attributes. From this tree, the user can eitherselect the relations to be retrieved fully, or can select specific attributes.

Next the user specifies the predicates by choosing the attributes (Step 2) and their correspondingvalues (Step 3). The user interface controls are dynamically generated based on the selections madein Step 2. Finally, the user taps the ‘‘Next’’ button on the ‘‘Values’’ tab. This prompts the DD to processthe query generated by the RNApplication from the user interface, and the DBN nodes to execute thequery fragments before one of them returns the results to the RN (RNApplication), which in turndisplays them in a grid (Step 4). The joins are implicitly determined from common attribute names(and types) among relations that have selected attributes. On the other hand, unions are also

ARTICLE IN PRESS

Fig. 4. RNApplication user interface.



automatically determined when there are multiple relations with identical names residing on two ormore DBNs.

4.4. Query processing by the data directory (DD) and request handling by DBNs

The request submitted by the RNApplication takes the following form:

Query-QueryID-RNName-RNAddress-RNSCN-RNFTPSCN-Relations-Attributes-Values-Selections

where Query is a header that informs the DD that the incoming message is a query request, QueryID

is a unique id that bears the device’s ID plus a monotonically increasing sequence number, RNName

is the name of the RN device, RNAddress is the RN address that references an entity within aBluetooth network (e.g., 00:12:D1:28:06:83), RNSCN is the RNApplication service channel number ofthe service advertised by the RN, RNFTPSCN is the RNApplication FTP service channel number (usedby the DBNs to connect to the FTP service on the RN and send the results file of the query), Relationsare the selected relations that the user wants to query, Attributes� Values represent the conditionsand the corresponding specified values (including any AND or OR operators), and finally Selections,are the attributes that should be retrieved by the query, separated by commas.

A DD that receives the request will tokenize it into its elements and then send aQUERYRECEIVED message to the RN. The DD, next, checks for the number of relations in thequery. If this number is one, two cases are considered: single relation single DBN, and single relationmultiple DBNs. On the other hand, if more than one relation was found in the query, then three othercases are considered, as will be discussed below. Fig. 5 summarizes the processing occurring at theDD node, while Fig. 6 depicts the actions taken by a DBN node participating in executing andanswering the user’s query. The text that follows will detail the processing occurring at the DD andparticipating DBN nodes for each of the above cases, and will describe the communications as well asthe messages exchanged between them.

Tokenize request from

RN

Schemas of DBNs

in network

Number of distinct relations?

One Two or more

No

Multiple DBNs?

Build corresponding SQL query

Send to concerned DBN

Yes

Build corresponding SQL queries

Send to participating DBNs

Types of joins (and

unions)

Joins on a single DBN

Joins between relations on ≥ 2

DBNs

Joins and unions between relations on ≥ 2 DBNs

Request from RN node

To involved

DBN

…

To involved DBNs

Fig. 5. Processing at the data directory (DD) node.

ARTICLE IN PRESS

Localdataset is largest?

Execute received

query

Retrieve results into a dataset

Exchange dataset size info with other

participating DBNs

To/From other participating DBNs

Sizeinfo

No

Yes

Send intermediate results in XML to participating DBN

with largest size

To DBN with largestresults size

Receive intermediate results from other participating DBNs

Perform unions and /or joins

SQL query from DD

node

Send final results in XML format to RN

Query part of a larger

query?

Yes

No …

…

From

oth

er

DB

Ns

To RN node

Fig. 6. Processing at the database (DBN) node, accounting for all possible scenarios.


4.4.1. Single distinct relation

In the single relation single DBN case, the DD generates the SQL query statement from thesubstrings obtained after tokenizing the RN’s query, gets the address of the DBN from the DBNSchema

database, connects to it, and sends it the query. The format of this query is:

Query-QueryID-RNName-RNAddress-RNSCN-RNFTPSCN-QueryType(0)-SqlStatement

The QueryType field is used to determine whether the query is answerable from one DBN, from theunion of multiple DBN relations, containing a join, or containing a join and a union. In the case of asingle relation–single DBN, once the DBN receives the request it processes SqlStatement, retrieves theresults in a DataSet, stores them in an XML file, and then sends it to the RN using the RNAddress,RNSCN and RNFTPSCN found in the request. If no records are found, the DBN sends to the RN anEMPTY message informing it the query cannot be answered.

In the case of a single relation multiple DBNs, the same query will be sent to all the participatingDBNs. The selection operations will occur in parallel, but the union occurs after the intermediateresults have been generated and the DBN with the smaller intermediate dataset has sent its data (asXML) to the other DBN, which will in turn perform the union with its own results before sending thecombined results to the RN. The query request in this case appends to the previous formatinformation about all the participating DBNs (Address, SCN, FTPSCN) so they know about each other.This is needed in order for all such DBNs to communicate to each other the sizes of their intermediateresults, and for the DBNs that hold the smaller results to send their output via FTP to the DBN withthe largest intermediate results. The format of the query is:

Query-QueryID-RNName-RNAddress-RNSCN-RNFTPSCN-QueryType(1)-QueryStatement-DBN1Address-DBN1SCN-DBN1FTPSCN-y-y-y- DBNnAddress-DBNnSCN-DBNnFTPSCN

Note that the QueryType in the union case has the value of 1, and that the above query implies theexistence of n participating databases (nX2). In our implementation, the participating DBNs that donot hold the largest intermediate results will send their output to the one with the largest results,which was found to generate the least amount of traffic. The DBN holding the largest intermediatedataset will perform the unions and then send the combined results to the RN. The size updatesexchanged between DBN nodes have the following format:

Query-QueryID-SourceDBNAddress-DBNResultsSize


Once a DBN determines that it has to forward the output of its query to another DBN, it sends thatDBN a notification message to inform it about the XML file name that it should expect. Such amessage has the following format:

uery-QueryID-SourceDBNAddress-DBNResultsFileName

4.4.2. Multiple distinct relations

In situations in which the number of distinct relations is two or more, three cases are considered:Join between relations on a single DBN, Join between relations on separate DBNs, and a combinationof unions and a join. The first thing that the DD performs once it gets two distinct relations is to checkfor common join attributes between them using common attribute names. If no join attributes arefound to link the relations, the DD connects to the RN and sends it an EMPTY message informing itthat its query cannot be answered.

In the case where all relations coexist on the same DBN, the DD constructs a single join query andtreats it as a QueryType ¼ 0 request with the following format:

Query-QueryID-RNName-RNAddress-RNSCN-RNFTPSCN-QueryType-JoinQueryFile

The second case of multiple distinct relations is when the query specifies distinct relations on atleast two different DBNs. This involves sending intermediate results between DBNs via QueryType 2,where afterwards, intermediate results will be joined at one of the participating DBNs. The queryfragments sent from the DD to the DBNs have the following format:

Query-QueryID-RNName-RNAddress-RNSCN-RNFTPSCN-QueryType(2)- QueryStatement-DBN1Address-DBN1SCN-DBN1FTPSCN-y-y-y- DBNnAddress-DBNnSCN-DBNnFTPSCN

The DBN that generates the results of a query knows that it should send the XML results file toanother DBN if the size of its intermediate results is not the maximum. Note that for a join to occur,the data from the received XML file are temporarily imported to the database of the receiving node,but get deleted after the join is performed.

The third case to be considered is a combination of unions and a join. This query is aheterogeneous one comprising two query types, with the relation that exists on multiple DBN nodesassigned a QueryType 1 (union) while the other that will be associated with a join, has a QueryType 2.The process of executing this query simply builds on the previous cases while keeping in mind thatthe union occurs first and then the join occurs at the DBN that carried out the union (call it DBNu), orat the DBN that holds the different relation (call it DBNd). This decision can be made withoutadditional size updates since DBNu can compare the size of the combined results that it holds to thatof the intermediate results reported by DBNd. Similarly, DBNd, which knows that it is DBNu thatexecuted the union since it held the largest individual intermediate dataset, can compare the size ofits output to the sum of the reported sizes by the other participating DBNs. Lastly, given that thisquery scenario is hybrid, the DD specifies the type of the joint operation at the DBN level so that aDBN knows if it is engaging in a union or a join. The format of the query fragment in this case is asfollows (the value of i is either 1 or 2).

Query-QueryID-RNName-RNAddress-RNSCN-RNFTPSCN-QueryStatement-DBN1Address-DBN1SCN-DBN1FTPSCN-QueryType(i)-DBN2Address-DBN2SCN-DBN2FTPSCN-QueryType(i)-y - y-y- DBNnAddress-DBNnSCN-DBNnFTPSCN- QueryType(i)


An extension to the third case above is where there are two or more joins and possiblyone or more unions. This case can be thought of as a generalization of the previous cases. Theunions, if they exist, occur first, followed by the joins that are performed sequentially.For intermediate results handling, a similar approach to the third case is taken in that the DBNholding the largest intermediate dataset among those that have the distinct relations will performthe joins.

For added illustration, Fig. 7 shows an example depicting the query processing procedure.In Fig. 7, DBN1 and DBN2 have different instances of the same relation while DBN3 has a totally

different relation. Given this and that all three DBN nodes know about each other (i.e., with respect tocollectively answering this particular query), they exchange the sizes of their intermediate results,and accordingly perform the union and join at the shown nodes.

DBN Node 1

User wants to submit query

Request schema xml file

Generate GUI

User makes selections and sets conditions

Xml file

Query

Fragment query and generate query plan

RN Node DD Node DBN Node 2

Query fragment

DBN Node 3

Query type 1

Selection results

Generate selection results

Generate union results

Union results

Generate selection

results

Generate selection

results

Query type 2

Generate join results

Display resultsFinal results

Exchange result sizes

Query fragment Query fragment

Fig. 7. Sequence diagram of a scenario with a union and a join involving three DBN nodes.


5. Experimental results

The applications described above were implemented on seven HP iPAQ hx2790 Pocket PCs(see Fig. 8), running Windows CE 5.0. Each application has its own setup procedure whichwill be elaborated in the coming section. After describing the system setup, we present and discussthe results obtained through implementing various scenarios and running sample queries.

5.1. System setup

The RNApplication was installed on one PDA, and so was the DDApplication. On the other hand theDBNApplication was installed on the remaining five PDAs along with associated SQL Server CEdatabases. The RNApplication was configured with four variables that are device-specific. They storethe name of the device, its address, its Service Channel Number (SCN), and its FTPSCN. As was seenabove, they are used by other devices that want to connect to the RN and exchange messages andfiles with it. A similar setup is done for the DD after installing the DDApplication. For setting up thefive DBNs, the DBNApplication on each device was identified with a single variable that indicatesthe device name, which in turn is used to name files that are sent over the network, and refers to thename of the database configured on that device.

The SQL Server CE database on each DBN supplies the needed functions to build relationaldatabases and answer SQL queries. To create the databases, a small application that executes aseries of SQL statements was written and installed on the DBNs. Fig. 9 shows an instanceof the databases in the network, where as implied, simple joins on separate DBNs can occurbetween Movies and Cinemas, and between Cinemas, Restaurants, and Stores on one hand, and Malls

on the other hand. Additionally, a union can occur between separate DBNs having the Restaurants

relation.The same application also creates a DBN schema of the relation(s) in the form of a DBNSchema.

sdf database, and then imports its records into an XML file ready to be shipped to a DDwhen requested. With the design as shown in the table at the bottom of Fig. 1, the attributes

Fig. 8. A view of the Pocket PCs on which the experiments were performed.

ARTICLE IN PRESS

Cinemas Cinema_Name Mall_Name

armHedrocnoCarmaHeliotEnudreVenuD

kuoZecapsEheinuoJetiCaL

elhaZjarbAkuoZetenalP

MoviesMovie_Name Cinema_Name Timings Pirates of the Caribbean Concorde 2pm,4pm,6pm,9pm,11pmShrek3 Concorde 2pm,4pm,6pm,9pm,11pmLord of the Rings Concorde 2pm,4pm,6pm,9pm,11pmTroy Concorde 2pm,4pm,6pm,9pm,11pmSimba Etoile 3pm,5pm,7pm,9pm,11pmPirates of the Caribbean Etoile 3pm,5pm,7pm,9pm,11pmTroy Dune 2pm,4pm,6pm,9pm,11pmShrek3 Dune 2pm,4pm,6pm,9pm,11pmPirates of the Caribbean Dune 2pm 4pm 6pm 9pm 11pm

MallsMall_Name Address Verdun Kantari, Beirut Jounieh North district hill, Jounieh Zahle Downtown city center, Zahle Zouk 1200 main highway, Dbayyeh Hamra Ras Beirut area, Beirut

RestaurantsRestauarnt_Name Mall_Name Specialty Phone Mcdonalds Verdun Burgers 09876234 Dunkin Donuts Vardun Donuts 06728393 Burger King Verdun Burgers 05888333 KFC Verdun Chiken 01838373 Starbucks Hamra Coffe 04999333 Burger King Hamra Burgers 01333333 Dunkin Donuts Hamra Donuts 01234567

RestaurantsRestauarnt_Name Mall_Name Specialty Phone Burger King Jounieh Burgers 01333333 Starbucks Jounieh Coffe 01234567 KFC Jounieh Chiken 01987654 Dunkin Donuts Jounieh Donuts 07222222 Mcdonalds Jounieh Burgers 09876234 Starbucks Zouk Coffe 06728393 Mcdonalds Zouk Burgers 05888333 KFC Chik 01838373

StoresStore_Name Mall_Name Products Batta Verdun Shoes Batta Jounieh Shoes Red Shoes Hamra Shoes Takbir Hamra Women’s clothes In Style Vardun Men’s clothes In Style Zahle Men’s clothes Al Matbakh Zouk Kitchen ware Khoury Home Zouk AppliancesRestaurantsRestauarnt_Name Mall_Name Specialty Phone Mcdonalds Zahle Burgers 0987623Dunkin Donuts Zahle Donuts 0672839Burger King Zahle Burgers 0588833

DBN1 DBN2

DBN3

DBN4

DBN5

Zouk

Fig. 9. An instance of the databases on the five DBN nodes (DBN 5 has three relations).


of the schemas at the DD are: DBNName, DBNAddress, SCN, FTPSCN, TableName, Attributes, and Size

(number of bytes).

5.2. Query response time

The experiments involved 170 queries of various complexities (combinations of selections, unions,and joins) that are described in Table 1 and concern a varying number of DBNs (up to 5). Whenmeasured across all submitted queries, the average selection ratio, which is determined by thepredicate in the query (i.e., WHERE conditions), was very close to 0.3. In other words, the size of thedataset returned by a single selection is 30% of the size of the relation, on average.

The reported response time is the time difference between when the results are received by theRN and when the query was submitted. The left graph in Fig. 10 shows the components ofthe response time (delays) for each query type in Table 1. Generally speaking, the various delaysincrease with the increase in query complexity (a larger query type corresponds to a more complexquery). The processing component includes query fragmentation, query plan generation, and resultswrapping into and unwrapping from XML. Therefore, it correlates with the size of the data and that ofthe query itself. The middle graph depicts the correlation of the total response time (the sum of allthree components) with the number of participating DBNs. The illustrated relationship is logicalsince an increase in the number of involved DBNs indicates additional joins and/or unions, which inturn implies more processing and more traffic. Finally, the right graph shows the direct relationshipbetween the query response time and the size of the total traffic generated. This relationship isbasically linear and suggests a growth in the response time by 2 s for each additional kilobyte oftraffic.

ARTICLE IN PRESS

Table 1Types of queries used in the evaluation of system performance

Query type # Queries # DBNs No. of operations Involved relations

Selections Unions Joins Malls Stores Cinemas Movies Restaurants

1 3 1 1 0 0 p1 3 1 1 0 0 p1 4 1 1 0 0 p1 10 1 1 0 0 p2 12 2 2 0 1 p p2 4 2 2 0 1 p p2 8 2 2 0 1 p p3 4 3 3 2 0 p4 10 3 3 0 2 p p p4 12 3 3 0 2 p p p5 6 3 4 2 1 p p5 7 3 4 2 1 p p6 9 3 4 0 3 p p p p7 10 3 5 2 2 p p p8 5 4 4 2 1 p p9 6 4 5 2 2 p p p9 11 4 5 2 2 p p p

10 13 4 6 2 3 p p p p11 7 5 5 2 2 p p p12 8 5 6 2 3 p p p p12 12 5 6 2 3 p p p p13 6 5 7 2 4 p p p p p

0

2

4

6

8

10

12

1Query type

Indi

vidu

al d

elay

s (s

ec)

Communications

Processing

DB operations

0

3

6

9

12

15

1Number of participating DBNs

Tota

l del

ay (s

ec)

Total response time

02468

101214161820

0

Generated total traffic (KB)

Que

ry re

spon

se ti

me

(sec

)

3 5 7 9 11 13 2 3 4 5 1 2 3 4 5 6 7 8

Fig. 10. Query response time: individual elements (left) and total time (middle and right).


5.3. Generated traffic

The size of traffic accounts for the exchanged messages between the devices as well as the resultfiles (intermediate and final), and was calculated from the number of incoming and outgoingmessages on each node. From this, the number of bytes sent and received by the applications wascomputed. Given that the applications use the Asynchronous Connectionless Link (ACL) of Bluetoothfor data communication, and that the data packets Bluetooth uses for ACL include, in addition to thepayload, 142 bits of encoding information (access code, header, and CRC), we computed the totaltraffic by multiplying the 142 bits by the number of packets and added the results to the

ARTICLE IN PRESS

0.0

0.4

0.8

1.2

1.6

2.0

2.4

2.8

3.2

1Query type

Ave

rage

traf

fic p

er q

uery

(KB

)

RN DD DBN

0.0

0.4

0.8

1.2

1.6

2.0

2.4

2.8

3.2

1Number of participating

DBNs

Ave

rage

traf

fic p

er q

uery

(KB

)

RN DD DBN

0.0

0.2

0.4

0.6

0.8

1.0

Number of participatingDBNs

Traf

fic o

verh

ead

ratio

Overhead Ratio

3 5 7 9 11 13 2 3 4 5 1 2 3 4 5

Fig. 11. Average traffic transmitted and received by each node type.


applications-generated bytes. The average total traffic generated for every query type is plotted in theleft two graphs of Fig. 11. It includes the query sent from the RN to the DD, the query fragments sentby the DD to the DBNs, the intermediate results sent between the DBNs, and the final resultstransmitted to the RN. The right graph depicts the overhead ratio, which is computed by dividing thetotal size of the query fragments and intermediate results by the size of the total traffic sent over thewireless network. As seen, this ratio is close to 50% when the number of participating databases istwo or more.

The graphs of Fig. 11 show that even for small relations (as indicated in the schema of Fig. 9), thegenerated traffic can be relatively significant. In this regard, the type and size of data that we chose totest the system with may be typical for general information like the ones we used (i.e., data that mayconcern the general public). However, specialized mobile applications may entail much largerrelations and therefore larger traffic to be put on the radio link. In all, the relationship between thedelay and traffic volume, as depicted in Fig. 10 (right), still holds.

5.4. Power measurement

The power measurement setup is illustrated in Fig. 12 and consists of an Agilent DSO3062Aoscilloscope connected to a PC that runs a data acquisition software for capturing instantaneousbattery voltage values at a rate of 200 samples per second. To measure the voltage, the batteryhad to be connected to the PDA externally. After examining the external wires, it turned out that,of the seven pins that connect the battery to the device, only two have non-negligible currentflowing and both are used to provide power to the processor, the memory interface, as well asto the Bluetooth and WLAN communication interfaces. A 0.375O resistance was placed inseries between the PDA and the battery for each of these two pins, thus allowing for measuringthe voltage drop across the two resistors. The oscilloscope computes the sum of the two voltagesand feeds the data into the PC, which in turn computes the current by dividing the measuredvoltage by the resistance, and then the power by multiplying this current by the battery’s voltage(3.7 V).

In this study, the idle power, the processing power, and the communication power of theBluetooth interface were isolated. Additionally, the power consumed by transmission and thatconsumed by reception were also differentiated. To obtain the average power value, theinstantaneous powers were averaged over the measurement duration and then the idle power(discussed next) was subtracted. Getting the actual energy spent in Joules was simply a matter ofmultiplying the average power by the process duration in seconds.

ARTICLE IN PRESS

Fig. 12. An illustration of the power measurement setup.


5.4.1. Idle power

PDAs consume power even when no processing seems to be involved. This power is used torefresh the 32 MB of RAM and the LCD screen, and process some kernel events. We measured thefollowing values with the PDA in idle mode: 463 mW without the Bluetooth (and WLAN)communication interface ON, and 507 mW with Bluetooth ON. Hence, the power increased by44 mW due to turning the Bluetooth interface ON. It should be mentioned here that all themeasurements were taken with the screen backlight off (it automatically goes off after 30 s ofinactivity). The left graph of Fig. 13 shows the captured waveforms which yielded the average powervalue. The graph illustrates the random pattern of the idle power, where it rises for few hundredmilliseconds every once in a while, in a random way.

5.4.2. Communication power

Power consumption due to Bluetooth communication can be divided into three parts: powerconsumed during peer discovery, power consumed by the communication interface during reception,and that during transmission. After being turned on, a device tries to discover other Bluetoothdevices in the vicinity. This process lasts between 5 and 12 s, depending on the number of peersdiscovered. In this phase, the device broadcasts packets at the maximal transmission power, whichwas measured to be 1083 mW (1590–507), where 1590 was the measured average power.

Transmission power over any wireless interface includes the baseband processing, the actual RFtransmission, and some connectivity-related processing. During the measurement process, thepower consumed due to transferring the query from the RN to the DD was identified with the aid ofthe log file that noted the exact time of the occurrence of this event. The same was also done withregard to the power consumed by transmitting the query fragments, and transferring the XML filescontaining the intermediate results and the final results. The peaks that showed during themeasurements (e.g., middle graph of Fig. 13) and corresponded to these events had nearly the sameamplitude for a given setting, but varied from a setting to another according to the distance and the

ARTICLE IN PRESS

0

0.5

1

1.5

2

2.5

Time (sec)

Pow

er (W

atts

)

Idle Power

Bluetooth ON

0

0.5

1

1.5

2

2.5

Time (sec)

Pow

er (W

atts

)Transmission

0

0.5

1

1.5

2

2.5

0Time (sec)

Pow

er (W

atts

)

Processing

50 100 150 200 250 3000 50 100 150 200 2500 50 100 150 200 250 300

Fig. 13. Sample power measurements: idle (left), transmission (middle) and processing (right).


number of obstacles between the devices. The latter condition can be attributed to associatedpathloss, forcing the sender to accordingly increase its power when needed to overcome theattenuation. The middle graph of Fig. 13 depicts the instantaneous power with a good coverage at a60 cm separation, where the average power is equal to 523 mW (1030–507). It should be mentionedthat an estimate of the bit rate employed by Bluetooth was obtained by dividing the total number ofdata bytes transferred by the total duration. More specifically, first, for each query submitted, thetotal number of bytes corresponding to all XML files transferred (intermediate and final) was dividedby the sum of file transfer durations (obtained from the log files). Next, an average was taken over allqueries to yield 294,764 bps. By referring to the Bluetooth specification (Bluetooth Specifications,2003), we find that a device transmitting data using DM3 packets (occupy three transmission timeslots) over an asymmetric connection-oriented link (ACL) can reach a bit rate of up to 387 kbps inasymmetric mode, while the lower rate DM1 packets allow for up to 108 kbps. This suggests that thePDAs were sending data using DM3 packets. The reception power was computed in the same mannerwhile receiving the same files that were transmitted. The average power was found to be slightlyhigher: 613 mW.

5.4.3. Processing

Power measurements were done for 80 queries that were randomly and uniformly selected fromthe list of 170 possible queries that belong to the 13 types listed in Table 1. The measured values wereaveraged across all queries of the same type for each type of activity (i.e., query fragmentation,database processing, and XML serialization and deserialization). A snapshot of the power measuredduring query fragmentation at the DD is seen in the right graph of Fig. 13.

The most power consuming activity was database processing (selections, joins, and unions),which includes the power used up by the SQL CE database engine itself. It was found to be 323 mW.The average power spent by fragmenting the queries and building a query plan was measured at151 mW, while XML serialization (wrapping the database dataset into an XML file) anddeserialization (extracting the results from the XML file) both measured at 155 mW.

Fig. 14 shows the consumed energy in milli-Joules for each type of activity and for every nodetype. Although the transmission and reception powers are higher than all types of processing power,the durations of data transfer are very short. That is, a DM3 Bluetooth packet can carry 121 bytes ofpayload and only occupies 1626 ms of the radio link time. This explains the relatively small amount ofenergy spent during transmission and reception of queries, query fragments, intermediate results,and final results. As shown in the right graph, database operations are the most expensive (power-wise), which is attributed to both the higher average power level during such operations and to thelonger durations that such operations take.

The average energy consumption at each node across all 80 queries is depicted in the left graph ofFig. 15. The DBN nodes spend the largest amount of energy per query, followed by the RN, which hasto parse the XML results and display them to the user. It is important to note that the reported

ARTICLE IN PRESS

RN Energy Consumption

0

60

120

180

240

300

360

420

1Query type

Ave

rage

ene

rgy

(mJ)

CommunicationsResults processing

DD Energy Consumption

0

60

120

180

240

300

360

420

Query type

Ave

rage

ene

rgy

(mJ)

CommunicationsQuery processing

DBN Energy Consumption

0

60

120

180

240

300

360

420

Query type

Ave

rage

ene

rgy

(mJ)

CommunicationsResults to/from XMLDatabase operations

3 5 7 9 11 13 1 3 5 7 9 11 13 1 3 5 7 9 11 13

Fig. 14. Aggregate node energy (in milli-Joules) consumption for each query type.

0

50

100

150

200

250

RNNode type

Ave

rage

ene

rgy

cons

umpt

ion

TX/RXXML ProcQuery ProcDB Ops

8.0

8.5

9.0

9.5

10.0

0.2Request rate (queries/min)

Expe

cted

bat

tery

life

(hr) RN DD DBN

DD DBN 0.5 1 2 3 4 5 6 7

Fig. 15. Average energy consumption (left) and expected battery life (h) for iPAQ hx 2790.


average DBN energy is taken over all the five DBNs in the piconet, and not just the participating onesin the different queries.

Finally, we computed the total energy for every node type and divided by it the capacity of the HPiPAQ hx2790 Pocket PC, which is specified at 1440 mA h. Moreover, we varied the request ratebetween one request every 5 min and seven requests per minute, and computed the associatedexpected battery life in hours. The results are illustrated in the right graph of Fig. 15, where it is seenthat the request rate impacts the DBN nodes the most. These results convey an important point: withcontinuous participation in the limited distributed database framework (i.e., in a piconet), the mobiledevice is not penalized significantly in terms of consumed battery power as suggested by thedifference between the maximum and minimum values seen in the right graph of Fig. 15 (i.e., slightlyabove 0.5 h).

6. Conclusion

In this paper, a distributed mobile database system was proposed for implementation onBluetooth-enabled mobile devices. The architecture calls for three types of nodes that work togethertoward answering the user’s query. Details of the implementation on iPAQ Pocket PCs were providedand the mechanisms for processing the submitted queries and coalescing intermediate results wereelaborated. A significant part of the paper was dedicated to describing the performance evaluation ofthe system that involved measurements of query response time, generated traffic, and consumedbattery power. The response time was in the order of seconds, with up to 18 s for a fairly complex


query that involves four joins and two unions. The consumed battery energy did not greatly reducethe battery life. It was shown that on average a continuous stream of queries at a rate of seven perminute will only reduce the battery life by a little over half an hour for a DBN. For other types ofnodes, the effect is even less.

As was described, the system is limited to eight mobile devices, which is the constraint imposedby the Bluetooth piconet. It is natural to extend the implementation to a scatternet that includesmore than just eight devices. In that case, the performance study would also examine the effect ofthe scatternet structure (i.e., number of piconets and how they are interconnected) on the delay,communication traffic, and energy consumption. Another future work involves studying the effect ofdata caching on reducing delays, traffic, and power consumption.

References

Altundag S, Gokturk M. A practical approach to scatternet formation and routing on Bluetooth. In: Proceedings of internationalsymposium on computer networks, 2006. p. 23–9.

Amin M, Bhuyan F, Rahman M. Bluetooth Scatternet Formation Protocol: a comparative performance analysis. In: Proceedingsof Asia-Pacific conference on communications, 2006. p. 1–5.

Basagni S, Bruno R, Mambrini G, Petrioli C. Comparative performance evaluation of scatternet formation protocols fornetworks of bluetooth devices. Wireless Networks 2004;10(2):197–213.

Bluetooth Specifications Version 1.2, vol. 2. Available online at: /http://www.bluetooth.comS; November 2003.Chan D, Roddick J. Summarisation for mobile databases. J Res Pract Inf Technol 2005;37(3):267–84.Dow C, Lin P, Chen S, Lin J, Hwang S. A study of recent research trends and experimental guidelines in mobile ad-hoc networks.

In: Proceedings of 19th international conference on advanced information networking and application, vol. 1, no. 28–30,2005. p. 72–7.

Epstein R, Stonebraker M, Wong E. Distributed query processing in a relational database system. In: Proceedings of the ACMSIGMOD international conference on management of data, 1978. p. 169–80.

Kossmann D. The state of the art in distributed query processing. ACM Comput Surv 2000;32(4):422–69.Kottkamp H-E, Zukunft O. Location-aware query processing in mobile database systems. In: Proceedings of 1998 ACM

symposium on applied computing, Atlanta, GA, 1998. p. 416–23.Li J. Query processing in mobile ad hoc wireless networks. In: Proceedings of the fourth international conference on computer

and information technology, Wuhan, China, September 2004.Petrioli C, Basagni S, Chlamtac I. Configuring BlueStars: Multihop scatternet formation for Bluetooth networks. IEEE Trans

Comput 2003;52(6):779–90.Zaruba G, Basagni S, Chlamtac I. Bluetrees-Scatternet formation to enable bluetooth-based ad hoc networks. IEEE Int Conf

Commun 2001;1:273–7.

http://www.bluetooth.com

Documents

A distributed mobile database implementation on Pocket PC mobile devices communicating over Bluetooth