Data replication in mobile computing

Technicl Report, My 2010 Dt repliction in mobile computing Bchelor s Thesis in Electricl Engineering Rodrigo Christovm Pmplon HALMSTAD UNIVERSITY, IDE SCHOOL OF INFORMATION SCIENCE, COMPUTER AND ELECTRICAL ENGINEERING

Detils Nme: Rodrigo Christovm Pmplon University: Hlmstd University, Sweden Degree Progrm: Electricl Engineering Title of Thesis: Dt repliction in mobile computing. Acdemic Supervisors: Edison Pignton de Freits Wgner Ourique de Moris

ABSTRACT With the dvnces of technology nd the populriztion of mobile devices, the need of reserching nd discussing subjects relted to mobile devices hs rised. One of the subjects tht needs to be further nlyzed is dt repliction. This study investigtes dt repliction on mobile devices focusing on power consumption. It presents four different scenrios tht propose, describe, pply nd evlute dt repliction mechnisms, with the purpose of finding the best scenrio tht presents less energy consumption. In order to mke the experiments, Sun SPOT ws chosen s mobile device. This device is fully progrmmed in jv environment. A different softwre ws creted in ech scenrio in order to verify the performnce of the mobile devices regrding energy sving. The results found did not meet the expecttions. While trying to find the best scenrio hrdwre limittion ws found. Although softwre cn be esily chnged to fix errors, hrdwre cnnot be chnged s esily. The implictions for the hrdwre limittion found in this study prevented the results to be optiml. The results found lso imply tht new hrdwre should be used in further experimenttion. As this study proved to be limited, it suggests tht dditionl studies should be crried out pplying the new version of the hrdwre used in this study.

LIST OF FIGURES Figure 1: Simple scenrio schemtic... 2 Figure 2: Sun SPOT... 6 Figure 3: Solrium Sun SPOT emultor... 8 Figure 4: Alwys on... 14 Figure 5: Timer ctivted... 15 Figure 6: Motion ctivted... 16 Figure 7: Motion ctivted with timer... 17 Figure 8: Bse sttion softwre... 19 Figure 9: Bttery drin for scenrio 1 first implementtion... 21 Figure 10: Bttery drin for scenrio 2 first implementtion... 22 Figure 11: Bttery drin for scenrio 3 first implementtion... 23 Figure 12: Bttery drin for scenrio 4 first implementtion... 24 Figure 13: Bttery drin for scenrio comprison t first implementtion... 25 Figure 14: Bttery drin for scenrio 1 second implementtion... 26 Figure 15: Bttery drin for scenrio 2 second implementtion... 27 Figure 16: Bttery drin for scenrio 3 second implementtion... 28 Figure 17: Bttery drin for scenrio 4 second implementtion... 29 Figure 18: Bttery drin for scenrio comprison t second implementtion... 30

LIST OF LISTINGS Listings 1: Accelerometer clsses... 8 Listings 2: Mesure ccelertion... 9 Listings 3: Rdio clss... 9 Listings 4: Rdio receive pckges... 9 Listings 5: Rdio send pckges... 9 Listings 6: Turn off rdio... 10 Listings 7: Bttery clss... 10 Listings 8: Bttery reding... 10 Listings 9: Red nd write file on bse sttion... 11 Listings 10: Files clsses... 11 Listings 11: Reding nd writing file on Sun SPOT... 11 Listings 12: Get timestmp nd bttery on SPOT... 11

LIST OF TABLES Tble 1: Dt exmple... 12

TABLE OF CONTENT ABSTRACT... III LIST OF FIGURES... IV LIST OF LISTINGS... V LIST OF TABLES... VI TABLE OF CONTENT... VII 1 INTRODUCTION... 1 1.1 CONTEXT DESCRIPTION... 1 1.2 GOALS... 3 1.3 WORK OUTLINE... 3 2 RELATED WORK... 4 3 METHODS AND TOOLS... 5 3.1 EXPERIMENTATION... 5 3.2 SUN SPOT... 5 3.3 SUN SPOT DEVELOPMENT KIT... 6 3.3.1 Configurtion... 6 3.3.2 Environment... 7 3.3.3 API... 8 3.4 DATA ACQUISITION... 11 4 SCENARIOS... 13 4.1 SCENARIO 1 ALWAYS ON... 13 4.1.1 Specifiction... 13 4.2 SCENARIO 2 TIMER ACTIVATED... 14 4.2.1 Specifiction... 14 4.3 SCENARIO 3 MOTION ACTIVATED... 15 4.3.1 Specifiction... 15

4.4 SCENARIO 4 MOTION ACTIVATED WITH TIMER... 16 4.4.1 Specifiction... 16 5 IMPLEMENTATION AND RESULT... 18 5.1 BASE STATION... 18 5.1.1 Implementtion... 18 5.2 FIRST SUN SPOT IMPLEMENTATION... 20 5.2.1 Scenrio 1 Alwys on... 20 5.2.2 Scenrio 2 Timer ctivted... 21 5.2.3 Scenrio 3 Motion ctivted... 22 5.2.4 Scenrio 4 Motion ctivted with timer... 23 5.2.5 Scenrio comprison... 24 5.3 SECOND SUN SPOT IMPLEMENTATION... 25 5.3.1 Scenrio 1 Alwys on... 26 5.3.2 Scenrio 2 Timer ctivted... 26 5.3.3 Scenrio 3 Motion ctivted... 27 5.3.4 Scenrio 4 Motion ctivted with timer... 28 5.3.5 Scenrio comprison... 29 6 DISCUSSION... 31 6.1 PROBLEMS... 31 6.1.1 Development softwre problems... 31 6.1.2 Softwre problems... 31 6.1.3 Hrdwre limittions... 32 7 CONCLUSION... 33 REFERENCES... 34

1 1 INTRODUCTION Mobile computing devices llow users to hve ccess to informtion t nytime nd nywhere. Mobile devices cn lso be used s routers in Mobile Ad hoc NETworks (MANET). The chllenge then is how to updte informtion crried by the mobile device while mximizing the system lifetime. This project presents different scenrios in the mobile computing domin. It lso pplies nd evlutes distinct dt repliction mechnisms in ech scenrio. At the end, it points out the best technique regrding energy sving is. In this project, the chosen mobile computing devices re SunSpots. The first step is to crry out study of these devices nd their required development environment. The second step involves the description of possible ppliction scenrios nd n investigtion of dt repliction methods used in mobile computing. In the next step, models for dt repliction re proposed nd implemented for the described scenrios. Finlly, the results re reported nd discussed. 1.1 CONTEXT DESCRIPTION In pst yers, the number of mobile devices such s mobile phones, PDA s, lptop s, mong others, hve hd such rpid growth tht they cn be esily found everywhere. With the populriztion of these devices, new pplictions tht try to find lterntive uses for them hve emerged. A new ppliction for mobile devices is tht the users could hve ccess to importnt dt nytime which would be crried by their mobile devices. The issue is finding out how this dt will be updted. The min chllenge tody is regrding how long mobile device cn be used before it needs to be rechrged. In order to study the spects discussed bove, scenrio in which voice recognition softwre is used in user s computer is proposed. This softwre needs to be trined by ech user in every computer tht will be utilized by the user. The user wnts to hve mobile device tht cn crry his updted profile from one computer to nother. Since lmost everyone crries mobile phone these dys, the logicl choice for the mobile device to be used in this context would be to choose mobile phone. But insted of choosing mobile phone the choice mde ws to use mobile device clled Sun SPOT, creted by Sun Microsystems. There re mny resons for choosing the Sun SPOT. One of them is tht the development process is esier nd it works in jv environment, which is very similr to mny of the modern mobile phones, so the solution cn be ported to mobile phone if necessry. It is importnt to sy tht the Sun SPOT should be used only s n experimentl pltform nd not s commercil product due to its vlue nd the difficulty of finding one for sle. Hving chosen the mobile device, one wy of sending the informtion to this device is through dt repliction. Dt repliction is wy of shring the sme informtion in mny devices. In order to do this, the dt is copied, which mens it is replicted, from one device to nother. The definition of dt repliction comes from dtbses which re discussed by mny uthors [5] who believe tht there re differences between dt repliction nd dt synchroniztion.

2 Besides these differences, when working with mobile devices the term synchroniztion cn be used to refer to rdio synchroniztion. To void mistkes with the terms, it is ssumed tht there re no significnt differences between dt repliction nd dt synchroniztion, nd only the term dt repliction is used here. A simple exmple to illustrte these differences is wht hppens with the contct informtion in mobile phones. For instnce, if there re 10 contcts sved in mobile phone s memory nd they re copied onto the phone crd, the dt is replicted. If there re 10 contcts sved in mobile phone s memory, nd 5 on the phone crd, there will be 15 contcts on the phone memory nd 15 on the crd when the dt is synchronized. There re different dt repliction techniques in dtbses. One of them is dtbse repliction, in which device releses copy of prt of dtbse or the entire dtbse to nother device. Another one is disk storge repliction in which two disks sve the sme informtion. And there is lso the distributed shred memory, in which one device shres portion of its memory with nother, so both cn ccess the sme informtion. When using dt repliction in mobile devices, some different techniques cn lso be used. In some more complex systems, using distributed shred memory cn be good solution. In this study, technique similr to dtbse repliction will be used. Insted of n entire dtbse, only smll portion of the dt will be replicted. When using mobile devices to replicte dt, mobile d hoc network (MANET) is creted, nd s every system tht uses wireless network, it should be designed in wy to consume s little energy s possible, extending the bttery lifetime. Different scenrios mesuring power consumption will be tested in this study. An optiml scenrio in which the device replictes the dt efficiently in bttery-sving wy, llowing the softwre to be run until the device needs to be rechrged, is expected to be found. A min scenrio is used to exemplify the use of the mobile devices. In this scenrio, user moves from one computer to nother with the mobile device, nd the dt should be replicted. This scenrio is presented in Figure 1. Figure 1: Simple scenrio schemtic The computers illustrted bove could be the user s home desktop, office desktop or lptop computers. Thus, the user crries the device from one plce to nother nd the dt replicted.

3 To study this mechnism of dt repliction, more detiled scenrios re proposed. All scenrios hve detiled specifictions on how the mobile device connects to the computer nd how they replicte the dt. The proposed scenrios re the following: In scenrio 1, which is clled Alwys on, the device is lwys connected, replicting the dt; Regrding scenrio 2, which is clled Timer ctivted, the device connects from time to time, nd replictes the dt; In scenrio 3, referred s Motion ctivted, the device turns on when moving, nd replictes the dt; Concerning scenrio 4, clled Motion ctivted with timer, the device turns on when moving or stops moving, nd mkes use of timer to sve the bttery until the dt is replicted. The first scenrio is expected to be the worst cse possible. However, it is essentil becuse it is the bse for implementing the other scenrios nd it is lso the reference for the scenrio comprison. In order to run the tests in the scenrios described bove, some vribles must be fixed, so tht the results cn be properly evluted. The chosen vribles in this study re: Time - the time during which the mobile device works; Informtion size - the sme mount of dt should be sent in ech scenrio; Bttery level - the sme bttery level must be used every time; Periodicity of repliction - the dt should be replicted t the sme time in ech scenrio. 1.2 GOALS This project ims t proposing different scenrios on dt repliction in mobile computing nd evluting their performnce in order to indicte the best technique considering energy sving, probbly those or one tht mkes less use of the rdio. 1.3 WORK OUTLINE This study is orgnized in seven different chpters. Firstly, in chpter 2 previous studies relted to this subject re discussed. In chpter 3, the description of the methodology used to build nd test the scenrios is described. In chpter 4, the different chosen scenrios re presented. In chpter 5, the results of this study cn be seen. In chpter 6, the discussion of the results cn be found. Finlly, in chpter 7, the conclusions reched throughout the experiment re given.

4 2 RELATED WORK Dt repliction is widely discussed subject, but most of the efforts on the re re focused on dtbses [3][4]. Due to the fct tht the number of mobile devices hs incresed gretly in the pst recent yers; with mobile phones, the populriztion of Bluetooth technology, new devices like tblets; the discussion of dt repliction in mobile devices is incresing, even though there re only few studies on it. There re some studies with context similr to the one described in this study. One of them [5] dels with mobile device which connects to computer in order to replicte dt, is run by softwre developed in Jv. It works with dtbse nd uses PDAs insted of Sun SPOTs, nd its im is to synchronize dt, not replicte it. One issue rised in this study is the use of more thn one dtbse. A simple solution is proposed which is to set dirty flg ech time the dt chnges. This cn be useful in systems with only one bse sttion nd one mobile device, but not with more devices. Another study which uses mobile phone [6] suggests tht mobile phone which is connected to wireless internet uses very complicted lgorithms to determine which dt should be replicted, which re bsed on the current dte nd globl position. Wht is interesting bout this study is the conclusion. It suggests tht it is very complicted to hndle lrge mounts of dt on mobile devices; therefore, this conclusion should be tken into considertion when designing mobile system for dt repliction. In nother study [7], the repliction mechnism is brodly discussed. However, this study tkes into considertion only the softwre point of view, thus it should be considered complementry study. In nother study [8], some protocols for synchroniztion of PDAs re discussed. It cn be considered complementry for this experiment due to its conclusions, which revel tht the importnt spects of synchroniztion would be the mount of dt exchnged between two devices during synchroniztion, the mount of dt stored in the mobile device nd how complex the synchroniztion is. There is no best choice for protocol, which indictes tht it would be necessry to study ech cse to determine wht the best protocol is. Dt repliction is being widely discussed nowdys, but the discussions re mostly bout protocols, synchroniztion, lgorithms, etc. Since no other study discussing the system lifetime ws found, it is impossible to compre the results obtined here with other studies, mking the present study complementry to ll the other studies crried out before.

5 3 METHODS AND TOOLS 3.1 EXPERIMENTATION In order to chieve the gols of this pper, experimenttion ws crried out bsed on the study of the four scenrios previously discussed. These scenrios ttempted to reproduce some of the possible situtions encountered in dt repliction in mobile systems. The scenrios were modeled to evlute power efficiency. The first scenrio proposed in this study ws designed to be the worst possible in order to serve s reference for the other scenrios. This comprison ws mde nlyzing the remining bttery chrge of mobile device fter the first test. The scenrio with higher bttery chrge t the end of the test ws supposed to be ble to remin working for more time, consequently, being the one with the best power efficiency. Regrding the processes used in order to perform the experiments, some steps were followed. Firstly, the Sun SPOT ws chosen to be used s mobile device nd then its hrdwre ws studied. Hving cquired bsic knowledge bout the hrdwre, the softwre ws studied nd subsequently the writing of the codes for ech desired scenrios strted. 3.2 SUN SPOT The Sun SPOT is wireless sensor network developed by Sun Microsystems, which cn be used in wide rnge of pplictions, from hobbyists to professionl pplictions. It hs min processor running Jv VM Squwk tht serves s n IEEE 802.15.4 wireless network node. As it cn be seen in the documents from Sun Microsystems [11], The Sun SPOT is designed to be flexible development pltform, cpble of hosting widely differing ppliction modules. The Sun SPOT development kit, s supplied, contins two different configurtions. One of the configurtions includes demonstrtion ppliction module, the edemo bord. [11]. The hrdwre hs two bords, the espot min bord, lso known s processor bord, nd the edemo or sensor bord. Besides the bords, the device needs power supply, nd the most common re USB cble nd bttery, even though other sources cn be used.

6 Figure 2: Sun SPOT The processor bord contins min processor, memory, power mngement circuit, 802.15.4 rdio trnsceiver nd ntenn, bttery connector nd dughterbord connector. The sensor bord contins n Atmeg88 processor, flsh memory, light sensor, temperture sensor, n ccelerometer, eight tri-color LEDs, two switches nd I/O pins. Ech Sun SPOT kit is composed by one bse sttion nd two mobile sunspot devices. The bse sttion consists of one min bord powered by one USB cble, nd the mobile devices consist of one min bord connected to one sensor bord powered by one bttery. 3.3 SUN SPOT DEVELOPMENT KIT The softwre tht controls the Sun SPOT runs in Jv. Therefore, the development of this softwre requires some setting-up on the computer first. 3.3.1 Configurtion In order to use the Sun SPOT, it is necessry to instll the Sun SPOT Softwre Development Kit (SDK). This SDK is composed by severl progrms which re needed for communiction with the Sun SPOT nd to develop its softwre. The instlltion cn be done from the CD-Rom tht comes with the Sun SPOT kit, or on the Sun SPOT website [14]. The first step is to instll the Sun Jv Runtime Environment (JRE), which llows the computer to run softwre in Jv. After this, the SPOT Mnger strts. The SPOT Mnger is the softwre tht verifies if the computer hs ll the required softwre to use the Sun SPOT, instlls them if needed, nd puts

7 ll the informtion together, so tht ll the Sun SPOT documenttion nd softwre cn be found in specific plce. The first ction of the SPOT Mnger is to verify if the computer hs the Sun Jv Development Kit (Sun JDK). In cse it is not instlled, the SPOT Mnger instlls the Sun JDK. Secondly, it verifies if the NetBens IDE (Integrted Development Environment) is instlled. This instlltion is not obligtory since other IDE softwre, such s Eclipse, cn be used with the Sun SPOT if the correct modules re instlled. As it is necessry to hve lest one IDE softwre, nd the CD-Rom comes with NetBens, it is the choice for IDE. After checking the IDE, the Spot Mnger checks for Apche Ant, softwre used to build Jv projects. It then checks for the Sun SPOT NetBens modules, which mkes NetBens work with the Sun SPOT. Finlly, fter ll the softwre is checked, the Sun SPOTs SDK is instlled. After ll the instlltion, it is required tht the computer is restrted nd the Sun SPOT will be redy to be used. More informtion on the Sun SPOTs SDK instlltion cn be found in the Sun SPOTs documenttion [13]. 3.3.2 Environment All the softwre is developed in NetBens nd for every scenrio two pieces of softwre re necessry: one for the SPOT nd one for the bse sttion. The softwre for the bse sttion runs directly on NetBens. The fct tht the bse sttion runs directly from the computer mkes it much more powerful thn the SPOTs, due to the computer s processing cpcity. The bse sttions run the Jv SE (Jv Pltform, Stndrd Edition), the most common jv, while the SPOTs run the Jv ME (Jv Pltform, Micro Edition), specil version of jv developed for smll devices, such s cell phones, PDA s, nd in which the SPOTs re bsed. The SPOT Mnger comes with SPOT emultor, clled Solrium. In this emultor, ll the softwre developed for the SPOT cn be tested. Since this study requires the mesurement of the bttery level, the emultor ws used only in the beginning, fter which the rel devices were used in testing the scenrios.

8 Figure 3: Solrium Sun SPOT emultor 3.3.3 API The Jv API (Appliction Progrmming Interfce) is n interfce tht contins ll the jv pckges, clsses nd interfces tht cn be used. The API for the current SDK cn be found t Spot Mnger, in the section clled Docs, in the subtopic JvDoc, nd then in the subtopic index.html. The most importnt pckges used in this study re listed there, with their clsses. 3.3.3.1 Accelerometer In order to red the ccelerometer, two clsses were imported (Listings 1): 1 com.sun.spot.sensorbord.peripherl.iaccelerometer3d; 2 com.sun.spot.sensorbord.peripherl.lis3l02aqaccelerometer; Listings 1: Accelerometer clsses With these clsses, redings from the ccelerometer were obtined nd mesurements of the device s movement were tken. Listings 2 shows how this reding ws done.

9 1 privte 2 LIS3L02AQAccelerometer ccel = (LIS3L02AQAccelerometer) demo.getaccelerometer(); 3 ccel.setscle(lis3l02aqaccelerometer.scale_6g); 4 cctotl = Mth.bs((ccel.getAccelZ() + ccel.getaccely() + ccel.getaccelx())); Listings 2: Mesure ccelertion The cctotl vrible (Listings 2, line 4) obtined the totl ccelertion in ll three xes. This ccelertion should be equl to 1 when the device is resting, 1 mening tht the device hs 1 G force pplied to it. When the device moves, this totl ccelertion should be bigger thn 1. 3.3.3.2 Rdio To use the rdio, the following clss ws imported (Listings 3). 1 com.sun.spot.io.j2me.rdiogrm.*; Listings 3: Rdio clss The rdio function cn be divided in two, one for receiving pckges, nd one to send pckges. To receive the pckges, the following code ws used (Listings 4): 1 Privte RdiogrmConnection rcon = (RdiogrmConnection) Connector.open("rdiogrm://:123"); 2 Privte Rdiogrm dg = (Rdiogrm) rcon.newdtgrm(50); 3 dg.reset(); 4 rcon.settimeout(100); 5 rcon.receive(dg); 6 commnd = dg.redutf(); Listings 4: Rdio receive pckges The vrible commnd (Listings 4, line 6) would get the red informtion. To send pckges, the following code ws used (Listings 5): 1 Privte RdiogrmConnection tx = (RdiogrmConnection) Connector.open("rdiogrm://brodcst:124"); 2 Privte Rdiogrm xdg = (Rdiogrm) tx.newdtgrm(50); 3 xdg.reset(); 4 xdg.writeutf(times); 5 tx.send(xdg); Listings 5: Rdio send pckges

10 In some moments it ws necessry to turn the rdio off. In order to do tht, the connections needed to be closed nd the following code ws used (Listings 6): 1 tx.close(); 2 rcon.close(); Listings 6: Turn off rdio 3.3.3.3 Bttery To red the bttery, the following clss ws imported (Listings 7): 1 com.sun.spot.peripherl.ibttery; Listings 7: Bttery clss After doing tht, the bttery could be red nd its sttus ws printed out, or sved into vrible (Listings 8). 1 IBttery bttery = Spot.getInstnce().getPowerController().getBttery(); 2 Bt = bttery.getbtterylevel(); 3 System.out.println("Bttery Level fter write " + bttery.getbtterylevel()+"%"); 4 System.out.println("Avilble Cpcity " + bttery.getavilblecbttpcity()); 5 System.out.println("Mx Cpcity " + bttery.getmximumcpcity()); Listings 8: Bttery reding 3.3.3.4 Files Reding nd writing files work in different wys on the bse sttion nd on the Sun SPOT. On the bse sttion the following code is used (Listings 9).

11 1 File myfile = new File( "C:\\textfile.txt" ); 2 timestmpbse = myfile.lstmodified(); 3 FileInputStrem fstrem = new FileInputStrem("c:\\textfile.txt"); 4 DtInputStrem in = new DtInputStrem(fstrem); 5 BufferedReder br = new BufferedReder(new InputStremReder(in)); 6 filestring = br.redline(); 7 FileOutputStrem fstrem2 = new FileOutputStrem("c:\\textfile.txt"); 8 DtOutputStrem out = new DtOutputStrem(fstrem2); 9 BufferedWriter bw = new BufferedWriter(new OutputStremWriter(out)); 10 bw.write(file); 11 myfile.setlstmodified(timestmpspot); Listings 9: Red nd write file on bse sttion 10). To work with the files on the Sun SPOT, the following clsses were imported (Listings 1 com.sun.spot.flshmngement.flshfile; 2 com.sun.spot.flshmngement.flshfileinputstrem; 3 com.sun.spot.flshmngement.flshfileoutputstrem; Listings 10: Files clsses The following code ws used to work with the files (Listings 11): 1 FlshFile dtf = new FlshFile("dtfile"); 2 FlshFileInputStrem ffidt = new FlshFileInputStrem(dtf); 3 DtInputStrem indt = new DtInputStrem(ffidt); 4 dtf.cretenewfile(1020); 5 dter = indt.redutf(); 6 indt. close(); 7 FlshFileOutputStrem ffodt = new FlshFileOutputStrem(dtf); 8 DtOutputStrem outdt = new DtOutputStrem(ffodt); 9 outdt.writeutf(file); 10 outdt.close(); Listings 11: Reding nd writing file on Sun SPOT 3.4 DATA ACQUISITION The Sun SPOT hs the cpcity of printing out informtion to the console. In this cse the following line ws dded to the code (Listings 12): 1 System.out.println("minutes," + c.get(clendr.minute) + ",seconds," + c.get(clendr.second) + ",bttery," + bttery.getavilblecpcity()); Listings 12: Get timestmp nd bttery on SPOT

12 With this code, one timestmp (minutes nd seconds only) nd the current bttery chrge in millimps ws printed in the system. One exmple of dt collected (Tble 1): Time stmp Bttery Chrge Minutes Seconds A 6 2 712,231194 6 2 712,23284 6 3 712,234076 6 3 712,223382 6 3 712,210986 6 4 712,198965 Tble 1: Dt exmple As the tbles collected during the experiment re fr too big, contining more thn 500 points ech, they will not be presented in this study. Insted, grphic mde with these points will be shown. For ech tble collected, the point where the dt will cross the x xis ws clculted, using the Excel intercept function. This function uses one interpoltion method with ll the collected points, nd its result is importnt s it shows the expected lifetime of the device, until the bttery remins out of chrge. To red this dt on the computer the Sun SPOT needs to communicte with the computer. There re two options vilble in order to do tht. One is using n USB cble nd the other is by using the bse sttion nd enbling the OTA (over the ir) function. As the Sun SPOT is chrged by the USB cble, there is no use in mesuring bttery consumption while chrging. Thus, the OTA function ws enbled on the Sun SPOT nd used to red the print outs. It ws lter understood tht this ws not the best solution. The problems with the OTA will be discussed in the results.

13 4 SCENARIOS Four scenrios were used for the testing in order to find out which one would be the most effective considering the bttery lifetime s the min issue. Detils such s which kind of dt ws used were irrelevnt to this study. The bsis for ll the scenrios is mobile Sun SPOT device, which ws progrmmed in such wy tht when it cme close to bse sttion connection ws estblished between them. If necessry, the dt contined in one of them (the most updted dt), would be replicted to the other device. The I/O pins, light sensor, nd switches were not used t ll in the scenrios, nd were turned off ll the time. For this study, other prts of the SPOT re implied s being off, unless it is specificlly mentioned s being on. 4.1 SCENARIO 1 ALWAYS ON In this scenrio, the mobile device ws lwys looking for the bse sttion nd if connected to it, kept trying to replicte the dt ll the time. This scenrio ws not expected to be the most effective one, but it ws the first to be implemented for its simplicity. It ws lso used s model to compre to the other scenrios. 4.1.1 Specifiction The softwre for this scenrio runs on n infinite loop. After strting, it keeps trying to find connection. When connected, the bse sttion sks the remote sttion which version of the dt the remote sttion hs, nd two nswers re llowed. One with the version of the dt, nd the other with null version, which mens tht the remote sttion does not hve ny dt. When the bse sttion receives the remote sttion s version, it compres it with its own version, nd tkes the ction to synchronize the versions, replicting the newest version. A digrm for this scenrio is shown in Figure 4. As cn be seen in this digrm, fter the beginning of this scenrio, the softwre goes into n infinite loop. In this loop the softwre is lwys trying to connect to nother device. When one connection is estblished, the device requests the version of the other device, nd then updtes the oldest one. After this, it goes bck to the beginning nd tries to estblish new connection.

14 Figure 4: Alwys on 4.2 SCENARIO 2 TIMER ACTIVATED The connection ws periodiclly ctivted, nd if the bse sttion ws found, the dt ws synchronized. This scenrio ws smll modifiction from the first one: with timer now dded. Different vlues for the period of time could be tested. The bttery lifetime ws expected to be much higher thn in the first scenrio, but might not be the optiml. The device ws on, trying to updte the dt from time to time, nd during the witing time the device ws on deep sleep mode. 4.2.1 Specifiction After strting the softwre, the on timer is set. The system tries to mke connection nd replicte the dt exctly the sme wy s in the first scenrio. Once the timer ends its counting, the system goes into sleep time. The digrm for this scenrio is shown in Figure 5. Anlyzing the digrm, it cn be seen tht there is timer in the scenrio tht is strted just in the beginning of the softwre. This timer puts the Sun SPOT in sleep mode from time to time. When the Sun SPOT is not sleeping, it works exctly in the sme wy s the first scenrio, estblishes connection, verifies which device hs the newest dt, nd updtes the oldest dt, in continuous loop.

15 Figure 5: Timer ctivted 4.3 SCENARIO 3 MOTION ACTIVATED Using the Sun SPOT pltform s built-in ccelerometer, it ws possible to determine when the device ws moving, nd trying to mke the connection with the bse sttion. As the device turned on only when moving, significnt mount of bttery could be sved during the time it ws not moving. 4.3.1 Specifiction Once the softwre strts, it reds the ccelerometer. If the device moves, it follows the sme reding procedure s in the first scenrio. When still, the device only reds the ccelerometer, witing for the device to move. The digrm is shown in Figure 6. Insted of hving one timer in the beginning of the softwre, like in the previous scenrio, this scenrio strts reding the Sun SPOT S ccelerometer. When it senses motion, it strts the routine to connect, requests dt version nd updtes the dt.

16 Figure 6: Motion ctivted 4.4 SCENARIO 4 MOTION ACTIVATED WITH TIMER This ws the most complete scenrio; it used the ccelerometer nd the timer between the redings. 4.4.1 Specifiction This scenrio strts by reding the ccelerometer in the sme wy s in the third scenrio, but fter moving, it strts timer in the sme wy s in the second scenrio, nd then reds the dt s in the first scenrio. After sleeping, it goes bck to reding the ccelerometer. The digrm is shown on Figure 7. This digrm is mix of the two previous ones, it strts reding the ccelerometer, nd then the timer. When the device is moving, nd it s not sleep time, it tries to estblish connection, requests dt version, nd updtes the dt.

Figure 7: Motion ctivted with timer 17

18 5 IMPLEMENTATION AND RESULT Two different types of softwre were needed in order to implement the scenrios, one for the bse sttion nd one for the Sun SPOTs. 5.1 BASE STATION Most of the work nd logic is done on the bse sttion softwre. A choice ws mde to develop ll the hrd work on regulr PC becuse the bse sttion runs on regulr PC. From there, commnds tht the Sun SPOT would recognize nd respond to were sent. All the work on the bse sttion begn when the bsic softwre for the Sun SPOT ws done. After it run successfully, there ws lmost no chnge. 5.1.1 Implementtion In order to mke the tests relible, some chnges were mde in the bse sttion softwre. One of the chnges ws to control some of the environment vribles so tht the softwre worked in specific wy. A digrm of the bse sttion softwre cn be seen on Figure 8. After getting reply from one Sun SPOT, the softwre for the tests sends 10 bytes to the device, then sleeps for 60 seconds; sends 100 bytes, sleeps for 30 seconds; sends 1 byte, sleeps for 180 seconds; sends 50 bytes, sleeps for 90 seconds; send 500 bytes.

19 Figure 8: Bse sttion softwre This softwre ws used with no modifiction when chnging the scenrio in ll the tests performed. To compre ech scenrio, the Sun SPOT bttery ws fully chrged nd then the softwre run for 600 seconds. At tht time the bttery level ws mesured.

20 5.2 FIRST SUN SPOT IMPLEMENTATION At first, the cretion of one generic scenrio softwre ws done, on which the other scenrios were implemented. In the first version this scenrio ws identicl to scenrio 1. 5.2.1 Scenrio 1 Alwys on 5.2.1.1 Implementtion In this scenrio, two bsic pieces of softwre were mde, one for the bse sttion nd one for the SPOT. The first version of the softwre sent only one vlue from the bse sttion to the SPOT, nd turned led on in the SPOT when the vlue ws received. Even though the led ws not used in the scenrios, it helped during the implementtion, due to the fct tht is mde it possible to verify if the device ws working. As the bsic send nd receive structure ws working, it ws time to mke the SPOT send the informtion to the bse sttion. When it received the correct informtion, it replied to the bse sttion. Hving the bse sttion nd the SPOT sending nd receiving the dt (Listings 9, Listings 11), the prt tht verified who hd the newest dt ws ccomplished. In the end, the file ws red with the time stmp. After ll this ws done, this scenrio s specifictions were fulfilled. 5.2.1.2 Scenrio 1 First result In this scenrio, the system ws lwys on, with the softwre running, so this ws the worst cse for the system power. During 600 seconds, the bttery level went from 720 A to 703,62 A. Bsed on the collected points tble from this experiment, grphic ws mde. The grphic cn be seen in Figure 9 which shows the bttery level in A.

21 725 B t t e r y C h r g e m i l l i m p s 720 715 710 705 Alwys on 700 0 100 200 300 400 500 600 Time - Seconds Figure 9: Bttery drin for scenrio 1 first implementtion The result for bttery lifetime (7h 12min 28s) should be used to compre with the other scenrios. This vlue ws clculted using excel intercept function: 25948,61s = 7h 12min 28s. This grphic shows n lmost liner behvior of the bttery level. 5.2.2 Scenrio 2 Timer ctivted 5.2.2.1 Implementtion Using the first scenrio s model, it ws just mtter of dding timer to the code, so tht fter the device turned on, timer ws set, nd fter files were updted or if the device did not find connection in 1 minute, the device slept for 1 minute. 5.2.2.2 Scenrio 2 First result Even though there ws some improvement when compring the bttery lifetime with the first scenrio, the difference ws miniml, in 600 seconds the bttery went to 704 A. Figure 10 shows the grphic of the bttery level in A.

22 Timer ctivted B t t e r y C h r g e m i l l i m p s 725 720 715 710 705 700 0 200 400 600 Timer ctivted Time - seconds Figure 10: Bttery drin for scenrio 2 first implementtion Bttery time, clculted using excel intercept function: 27943,17s = 7h 45min 43s. 5.2.3 Scenrio 3 Motion ctivted 5.2.3.1 Implementtion Using the first scenrio s model once gin, the ccelerometer reding ws implemented, the ccelertion t the three xes (Listings 2) ws red, nd the bsolute vlue ws tken with totl ccelertion = bs (ccelx+ccely+ccelz). By doing this, when the device ws not moving the totl ccelertion hd to be equl to 1. When the device moved, its vlue rose nd fter some testing the vlue of 1.5 ws defined s good vlue to ensure if the device ws moving. Therefore, if reding for ccelertions of more thn 1.5 G occurred, the sme softwre of the first scenrio strted running. 5.2.3.2 Scenrio 3 First result This result ws even worse thn in the first cse. The reson is tht the system kept working in the sme wy s in the first scenrio, with the ddition of the built-in ccelerometer tht ws now on ll the time. In 600 seconds the bttery went to 701,65 A. Figure 11 shows the grphic of the bttery level in A.

23 Motion ctivted B t t e r y C h r g e m i l l i m p s 725 720 715 710 705 700 0 200 400 600 Motion ctivted Time - seconds Figure 11: Bttery drin for scenrio 3 first implementtion Bttery time, clculted using excel intercept function: 23515,42s =6h 31min 55s. 5.2.4 Scenrio 4 Motion ctivted with timer 5.2.4.1 Implementtion This scenrio ws mix of the previous scenrios. After reding move with the ccelerometer, the device strted timer, nd then looked for file to updte. 5.2.4.2 Scenrio 4 First result This result ws very close to the first one, blncing the gin of lifetime from the timer nd the loss of lifetime from the ccelerometer. In 600 seconds the bttery went to 703,75 A. Figure 12 shows the grphic of the bttery level in A.

24 B t t e r y C h r g e m i l l i m p s 725 720 715 710 705 700 Motion ctivted with timer 0 200 400 600 Time - seconds Motion ctivted with timer Figure 12: Bttery drin for scenrio 4 first implementtion Bttery time, clculted using excel intercept function: 25815,64s =7h 10min 15s. 5.2.5 Scenrio comprison By nlyzing the dt, it could be observed tht the bttery run time is very similr in ll scenrios, which is n indiction of n error in the softwre. In the first Alwys On scenrio the bttery level ws 703,625 A. In the Timer Activted scenrio, the bttery level ws 704 A. In the Motion Activted scenrio the bttery level ws 701,65 A. In the Motion with timer scenrio the bttery level ws 703,75 A. Figure 13 shows grphicl comprison of ll scenrios.

25 Scenrio comprison B t t e r y C h r g e m i l l i m p s 725 720 715 710 705 700 0 200 400 600 Timer ctivted Motion ctivted Motion ctivted with timer Alwys on Time - Seconds Figure 13: Bttery drin for scenrio comprison t first implementtion Bttery time: 25948,61s = 7h 12min 28s. Alwys on. Bttery time: 27943,17s = 7h 45min 43s. Timer ctivted. Bttery time: 23515,42s = 6h 31min 55s. Motion ctivted. Bttery time: 25815,64s = 7h 10min 15s. Motion with timer. 5.3 SECOND SUN SPOT IMPLEMENTATION After the first implementtion s bd results, n nlysis of the softwre ws conducted. The sleep function ws first checked. The Sun SPOT hs two wys of sleeping: regulr sleep mode nd deep sleep mode. Both modes re strted the sme wy, but when some requirements re fulfilled, the Sun SPOT enters the deep sleep mode, otherwise it just sleeps. After some reserch in the officil forum, it ws discovered tht there re two common mistkes tht do not llow the Sun SPOT to enter in the deep sleep mode: one is to leve secondry thred running, nd the other is to leve the rdio on. As one thred ws running while trying to red the rdio, it ws determined tht the problem ws with this thred. First the thred ws stopped, nd the rdio ws turned off inside this thred. Even then, the Sun SPOT did not enter the deep sleep mode. After reserching in the officil Sun SPOT forum more extensively, some discussion bout using threds ws found. Other people hd experienced the exct sme problem with Sun SPOT nd threds, so decision to rewrite the whole softwre without the use of threds ws mde. With the new softwre ll in one thred, the rdio ws turned off, nd the Sun SPOT entered the deep sleep mode. Insted of creting generic softwre with the bsic functions nd then dding the dditionl needed functions, the opposite ws done. Thus, softwre tht runs scenrio 4 ws creted nd it served s the bse for the other scenrios.

26 5.3.1 Scenrio 1 Alwys on 5.3.1.1 Implementtion For the bse softwre to remin running ll the time without interruptions, the ccelerometer nd the timers were disbled. 5.3.1.2 Scenrio 1 Second implementtion result This result ws 5% worse thn the sme scenrio in the previous implementtion. However, s the experiment ws conducted two weeks fter the first implementtion, no comprison cn be mde, becuse even though the sme device ws used, the bttery cn behve differently on different dys. Therefore this result ws used in comprison with the other results of this implementtion. In 600 seconds the bttery dropped from 720 A to 702,64 A. Figure 14 shows the grphic of the bttery level in A. Alwys on B t t e r y C h r g e m i l l i m p s 725 720 715 710 705 700 0 200 400 600 Alwys on Time - Seconds Figure 14: Bttery drin for scenrio 1 second implementtion Bttery time: 24888,31s = 6h 54min 48s. Alwys on. 5.3.2 Scenrio 2 Timer ctivted 5.3.2.1 Implementtion In other to fulfill the requirements of the scenrio 2, the bse softwre ws used with the timer enbled nd with the ccelerometer disbled. It run for 60 seconds, nd entered the deep sleep mode for 60 seconds.

27 5.3.2.2 Scenrio 2 Second implementtion result With the deep sleep mode working, n expressive result with 202% more bttery lifetime thn in the first scenrio ws chieved. The bttery chrge fter 600 seconds is 714,23 A. Figure 15 shows the grphic of the bttery level in A. Timer ctivted B t t e r y C h r g e m i l l i m p s 725 720 715 710 705 700 0 200 400 600 Timer ctivted Time - Seconds Figure 15: Bttery drin for scenrio 2 second implementtion Bttery time, clculted using excel intercept function: 75366,95s = 20h 56min 6s. 5.3.3 Scenrio 3 Motion ctivted 5.3.3.1 Implementtion Using the bse model with the ccelerometer enbled, nd the timer disbled, the specifictions for scenrio 3 were completed. When the device moves, it turns on nd keeps on until the file is replicted. 5.3.3.2 Scenrio 3 Second implementtion result This result ws not very expressive, with only 15% improvement. When the device ws witing for movement the rdio ws off, which cused some improvement. However, the device ws still running, which did not occur when it entered in deep sleep mode. In 600 seconds the bttery level ws 705,055 A. Figure 16 shows the grphic of the bttery level in A.

28 Motin ctivted B t t e r y C h r g e m i l l i m p s 725 720 715 710 705 700 0 200 400 600 Motin ctivted Time - Seconds Figure 16: Bttery drin for scenrio 3 second implementtion Bttery time, clculted using excel intercept function: 28698,83s = 7h 58min 18s. 5.3.4 Scenrio 4 Motion ctivted with timer 5.3.4.1 Implementtion This softwre ws the full version of the bse softwre which ws used in the second implementtion hving ll the functions enbled. 5.3.4.2 Scenrio 4 Second implementtion result In this scenrio the result ws once gin mix of the improvement from the timer, nd the verge result from the ccelerometer. The bttery level in 600 seconds ws 712,47 A. Figure 17 shows the grphic of the bttery level in A.

29 B t t e r y C h r g e m i l l i m p s 725 720 715 710 705 700 Motion ctivted with timer 0 200 400 600 Time - Seconds Motion ctivted with timer Figure 17: Bttery drin for scenrio 4 second implementtion Bttery time, clculted using excel intercept function: 62066,54772s = 17h 14min 26s. 5.3.5 Scenrio comprison Since the best results were obtined with the timer only, the motion ctivted scenrio must be studied, since it should offer better result thn the ones found. The bttery level for scenrio Alwys On ws 702,64 A. In the Timer Activted scenrio, the bttery level ws 714,23 A. For the Motion Activted scenrio, the bttery level ws 705,055 A. In the Motion with timer scenrio, the bttery level ws 712,47 A. Figure 18 shows grphicl comprison of ll scenrios.

30 Scenrio comprison 2 B t t e r y C h r g e m i l l i m p s 725 720 715 710 705 700 0 200 400 600 Alwys on Motin ctivted Timer ctivted Motion ctivted with timer Time - Seconds Figure 18: Bttery drin for scenrio comprison t second implementtion Bttery time: 24888,31s = 6h 54min 48s. Alwys on. Bttery time: 75366,95s = 20h 56min 6s. Timer ctivted. Bttery time: 28698,83s = 7h 58min 18s. Motion ctivted. Bttery time: 62066,54772s = 17h 14min 26s. Motion ctivted with timer.

31 6 DISCUSSION When implementing mobile device, both softwre nd hrdwre should be nlyzed to chieve the best results. The softwre cn be esily chnged to fix errors or follow better result wheres the hrdwre cnnot be chnged s esily. In this cse, the hrdwre used in the tests ws the Sun SPOT. Becuse it is well-known device, it ws thought tht it would be the perfect hrdwre for the tests due to the fct tht it contined the qulities required for the experiment. These qulities cn be described s: First, it is mobile device. Secondly, its softwre is implemented in JAVA. Also, it offers rdio communiction nd hs n ccelerometer to mesure whether it is moving or not. 6.1 PROBLEMS Some problems were found when the development of the softwre nd the experimenttion begn. These problems re discussed below. 6.1.1 Development softwre problems There re mny versions of the Sun SPOTs SDK. The version chnges depending on the hrdwre version, so it is recommended tht the softwre from the CD-Rom is instlled if the version to be used in not known. In this study, the SDK V4.0 Blue ws used first (the version tht comes with the CD-Rom), but fter some problems with the SDK, n updte to the SDK V5.01 Red ws done, nd ech Sun SPOT firmwre ws updted s well. With the SDK working, some time ws spent trying to red the bttery level from the emultor. After filing on doing it, some reserch ws crried out nd the following nswer ws obtined from the officil Sun SPOT forum: Sorry, it is n issue with Solrium. When the Emultor ws written SPOTs did not support the bility to red the vilble cpcity of the bttery. All tht ws vilble ws the current bttery voltge & the chrge/dischrge rte, so tht's why the Sensor Pnel in the Emultor hs sliders for those two vlues. I'll dd it to the list of requested fetures, but do not expect tht it will be done nytime soon. As it ws impossible to work with the emultor, the experimenttion continued with the rel Sun SPOT. 6.1.2 Softwre problems The first implementtion did not work well, becuse the softwre did not chieve the hrdwre requirements to enter the deep sleep mode. Reserching the officil Sun SPOT forum, much divergence bout how much current the device uses in the deep sleep mode ws found, so the idel cse would be to mesure the consumption physiclly, not only by mens of softwre s occurred in these experiments. Unfortuntely, due to lck of time, this mesurement ws not done, nd the only conclusion tht cn be possibly extrcted from the discussions in the forum ws tht when the device is ctive or

32 in regulr sleep, the system drins current in A from the bttery, nd when in deep sleep mode, this current flls to A. Even without knowing the exct vlue of the currents, the difference between the regulr sleep mode nd the deep sleep mode could be observed when compring the first nd second implementtions. Thus, it cn be sid tht this prt of the experiment ws successful, s the system lifetime ws drsticlly improved only by using timer nd the deep sleep function. 6.1.3 Hrdwre limittions The results with the motion ctivted scenrio were not s good s expected, so n explntion hd to be found. After serching the Sun SPOT forum, some discussions bout the ccelerometer nd one of the Sun SPOT limittions were found: One explntion is tht it cnnot red the ccelerometer while in deep sleep mode, so when the device ws witing for some movement, it ws drining current from the bttery in A, not in A like when in deep sleep. There were some discussions bout how to mke some modifictions to the Sun SPOT to llow it to red the ccelerometer in deep sleep mode, but the only solution found ws to use nother kind of sensor, insted of the ccelerometer, connected to the I/O pins of the Sun SPOT to mesure the movement. Thus, it cn be ssumed tht the bd results of the motion ctivted scenrio were cused by hrdwre limittion. And then no more experiments were conducted due to time nd resources constrints. After the experimenttion prt finished new version of the Sun SPOT ws relesed, which confirms the limittions found in this study. Consulting the relese notes of this version [23], the following lines cn be found: The SPOT sensor bord hs been redesigned. New fetures include: New MMA7455L ccelerometer replces LIS3L02AQ ccelerometer. New ccelerometer hs three scle rnges: 2/4/8G. By defult sensor bord ATmeg microcontroller now stys wke when min processor bord is powered down for deep sleep, nd cn generte interrupts to wke SPOT up on pin chnges, switch presses, etc. Hd the sme experiment been done with the new hrdwre, results even better thn those obtined with the timer could be expected, s now it is possible to red the ccelerometer while the min bord is in deep sleep. However, it is believed tht the results obtined re vlid nd my be used by nyone when designing mobile device or choosing hrdwre for system.

33 7 CONCLUSION Mobile devices re becoming everydy use devices for people. With the recent growth nd development of devices such s mobile phones, PDAs, PADs mong others, it is nturl tht more reserch bout these tools is crried out. New uses nd new pplictions creted for these devices re found every dy, nd dt repliction is one subject tht is being more nd more discussed. The mjority of dt repliction discussions focus exclusively on the softwre, discussing protocols of communiction, lgorithms nd other softwre specific detils bout dt repliction. In ddition to this softwre discussion, it is fundmentl to discuss the hrdwre, especilly in mobile devices tht hve limited system lifetime before their bttery needs to be rechrged. Some softwre nd hrdwre limittions were found in this study which led to some unexpected results. The chosen hrdwre in this study ws the Sun SPOT. This device uses free softwre, nd seems perfect for testing purposes only, s it is expensive for lrge scle uses. At first, the importnce of the softwre in system ws demonstrted. The first implementtion of the softwre ws not useful. Due to bd softwre development, it ws not possible to utilize the full hrdwre potentil, creting very limited system. Even in these simple tests, there ws gret difference in the results with the improved softwre. The second result occurred when the hrdwre did not meet the softwre expecttions. The system ws expected to be ble to wit for long time for movement, drining just few A, but this did not hppen. From the experiments results with ech scenrio, the best result ws chieved using simple timer, nd putting the device in sleep stte tht drins some A while in wit. Tking into considertion the results obtined in the scenery tests with the softwre nd hrdwre limittions, it is sfe to sy tht both cn contribute significntly to the results. When developing system, the person who cretes the softwre must know every detil of the hrdwre used, otherwise some hrdwre resources tht could improve the system might not be used. In the sme wy, when choosing or creting hrdwre, ll the required resources must be evluted, or the system my not work s expected. Although the best scenrio for these softwre nd hrdwre ws found, it is believed tht better result could hve been chieved if different hrdwre hd been used. Another fctor is tht there is very little discussion bout hrdwre in mobile devices compred to wht cn be found bout softwre. It is much esier for n independent resercher to run experiments only with softwre, using limited hrdwre, but s it ws seen in this study, when finding hrdwre limittion the resercher does not hve the mens to fix the limittion nd continue running the experiments. As suggestion for future studies, n experiment cn be conducted with the new Sun SPOT hrdwre, or with nother hrdwre tht solves the limittion tht ws found. Another suggestion is to crete simple repliction softwre tht could work on mobile phones.

34 REFERENCES [1] CHI CORPORATION. Repliction. Avilble t: <http://www.chicorportion.com/index.php?option=com_content&tsk=view&id=98&it emid=136>. Accessed: 18 Mrch 2010. [2] DERBY PROJECT. ReplictionWriteup. Avilble t: <http://wiki.pche.org/dbderby/replictionwriteup>. Accessed: 28 April 2010. [3] MICROSOFT. Dt Repliction. Avilble t: <http://msdn.microsoft.com/enus/librry/ms978671.spx>. Accessed: 18 Mrch 2010. [4] TECH-FAQ BY TOPBITS. Dtbse Repliction. Avilble t: <http://www.techfq.com/dtbse-repliction.html>. Accessed: 28 April 2010. [5] GREHAN, Rick. Simplify device dt repliction, synchroniztion. Avilble t: <http://www.eetsi.com/art_8800463789_499495_nt_f57fe0f1.htm>. Accessed: 18 Mrch 2010. [6] SCHANDL, Bernhrd; ZANDER, Stefn. Autonomous RDF Repliction on Mobile Devices. Wien, Austri: University Of Vienn, 2009. Avilble t: <http://www.cs.univie.c.t/uplod//223/ppers/2009/iswc2009-schndl.pdf>. Accessed: 18 Mrch 2010. [7] BELOUED, Abdelkrim; GILLIOT, Jen-Mrie; SEGARRA, Mri-Teres. Dynmic Dt Repliction nd Consistency in Mobile Environments. Frnce: Get-enst Bretgne D Eprtement Informtique Technopole Brest Iroise, 2005. Avilble t: <gttp://middlewre05.objectweb.org/wsproceedings/doctorlsymposium05/1- beloued.pdf>. Accessed: 18 Mrch 2010. [8] AGARWAL, S.; STAROBINSKI, D.; TRACHTENBERG, A. On the Sclbility of Dt Synchroniztion Protocols for PDAs nd Mobile Devices. Boston: Deprtment Of Electricl And Computer Engineering, Boston University, 2003. Avilble t: <http://citeseerx.ist.psu.edu/viewdoc/downlod?doi=10.1.1.12.5572&rep=rep1&type=pd f>. Accessed: 18 Mrch 2010. [9] GOLDMAN, Ron. Using the SPOT Emultor in Solrium. June 2008. [10] SUN LABS. Sun SPOT Owner s Mnul Blue Relese 4.0. August 2008. [11] SUN LABS. Sun Smll Progrmmble Object Technology (Sun SPOT) Theory of Opertion. August 2008. [12] ALHIR, Sinn Si. UML in Nutshell. Sebstopol: O reilly, September 1998. [13] SUN LABS. Getting Strted With Sun SPOTs. Avilble t: <http://www.sunspotworld.com/gettingstrted/>. Accessed: 10 Februry 2010.

35 [14] SUN LABS. Sun SPOT Mnger. Avilble t: <http://www.sunspotworld.com/spotmnger/index.html>. Accessed: 10 Februry 2010. [15] BUTRICO, Mri A. et l. Gold Rush: Mobile Trnsction Middlewre with Jv- Object Repliction. Yorktown Heights, NY: Ibm Thoms J. Wtson Reserch Center, 1997. Avilble t: <www.reserch.ibm.com/people/n/ncohen/goldrush.pdf>. Accessed: 21 Mrch 2010. [16] SCHANDL, Bernhrd; ZANDER, Stefn. Context-driven RDF Dt Repliction on Mobile. Wien, Austri: University Of Vienn, 2010. Avilble t: < http://semnticweb-journl.org/sites/defult/files/swj130.pdf>. Accessed: 10 Jnury 2011. [17] BURROWS, Mike. The Chubby lock service for loosely-coupled distributed systems. Settle, W: Google Inc., 2006. Avilble t: <http://lbs.google.com/ppers/chubby.html>. Accessed: 24 April 2010. [18] TRENCSENI, Mrton; GAZSO, Attil. Keyspce: A Consistently Replicted, Highly- Avilble Key-Vlue Store. Sclien. Avilble t: <http://sclien.com/pdf/keyspce.pdf>. Accessed: 28 April 2010. [19] TRENCSENI, Mrton; GAZSO, Attil; REINHARDT, Holger. PxosLese: Diskless Pxos for Leses. Sclien. Avilble t: <http://sclien.com/pdf/pxoslese.pdf>. Accessed: 28 April 2010. [20] ANDREOU, Pnyiotis et l. Perimeter-Bsed Dt Repliction in Mobile Sensor Networks. Nicosi, Cyprus: Deprtment Of Computer Science, University Of Cyprus, 2009. Avilble t: <http://www.cs.ucy.c.cy/~dzein/ppers/senseswrm-mdm09.pdf>. Accessed: 10 Jnury 2011. [21] SUN LABS. Sun Smll Progrmmble Object Technology (Sun SPOT) Theory of Opertion. August 2008. Avilble t: <http://sunspotworld.com/docs/blue/sunspot- TheoryOfOpertion.pdf>. Accessed: 19 April 2010. [22] SUN LABS. SunSPOT API V5.0. Avilble t: <http://www.sunspotworld.com/docs/red/jvdoc/>. Accessed: 12 April 2010. [23] SUN LABS. Sun SPOT SDK Relese Notes: This is relese 6.0 of the Sun SPOT SDK (.k.. Yellow). Avilble t: <http://www.sunspotworld.com/docs/yellow/relesenotes.html>. Accessed: 31 My 2011.