00905527

Embed Size (px)

Citation preview

  • 7/28/2019 00905527

    1/6

    Performance Evaluation of theBluetooth-based Public Internet Access PointY ujin Limt, J esung Kim, Sang Lyul Min, and J oong So0MatDEPARTMENTF L IECHANICAL ENGINEERING,NIVERS ITY OF SEOUL , SEOUL , KOREAt

    SCHOOL OF COMPUTER SCIENCE A N D ENGINEERING,E O U L NATIONAL N I V E R S I T Y , SEOUL, KOREAI N F OR M A T I ON A N D C O M M U N I C A T I O N S U N I VER S I T Y , TAEJON,

  • 7/28/2019 00905527

    2/6

    asingle or multiple radio units. -41~0,he radio units mayact as a master or a slave. This gives us a design spaceencompassing four possible combinations: (1)single slaveunit, (2) single master unit, (3) multiple slave units, (4)multiple master units. In tlie first combination: the Inter-net access point acts as a slave while each user device actsas amaster establishing it's own piconet to connect to tlieInternet access point. In this setup, the total baridwidthof the radio link is shared by all of the user devices. How-ever: this design requires the slave unit to switch from onepiconet to another, which takes up to one frame. This over-head is significant wheri switching occurs frequently: e.g.,in the order of a few frames.

    The second design choice is the Internet access point witha single radio unit that acts as a master of a piconet withall user devices as slaves. When the radio is in the mastermode, i t controls all the slaves participating in the picorietby determining which slave exchanges data with the mas-ter. This design is more efficient than the first design sincethe overhead of piconet switching is not present.

    The remaining two designs are extetisioxis of the two ixii-tial designs with additional radio units in the Ititernet ac-cess point. This allows load-sharing between radio unitsand hence improves both the total bandwidth and the max-imum number of users, at the costs of additional radiounits. However: multiple radio units may interfere eachother by occasionally collidirig at the same frequency barid:whose performance impact is analyzed in Section I V .

    In the simulation, we assume the second design. Wealso assume that the number of slaves is limited to sevenin order to remove the effect of parking that is requiredwhen more than seven slaves are to be connected to a mas-ter. We focus on the throughput and delay per user in asteady-state environment where no users join or depart thepiconet. For the evaluation, we have developed ax1event-driven, packet-level simulator using P.4RSEC developed atUCLA as a successor to Maisie [5].4s for the Internet access model, weuseaclosed queuingsimulation model that processes Internet web surfing trafficas shown in Figure1. In this model; auser with anotebookgenerates traffic by clicking on the screen after consuminga UserThinkTime. The user's request is inserted into aup-load queue in which the transmission is delayed until theInaster's polling is received. This delay is called a Bluetoothupload scheduling delay and dependent on the schedulingpolicy of the master. .4fter the upload scheduling delay:the notebook that ispolled by the master sends the user'srequest to the Internet -4ccess Point(AP) axid the 4P for-wards the request to the Internet. I7iter~retAccessTiniesthe time for the AP to receive the user-requested data fromthe Internet since the request is submitted. When the re-quested data is ready, the data is inserted into the down-load queue and stays there until the corresponding note-book is polled. This delay is called a Bluetooth downloadscheduling deluy and also affected by the scheduling policyof the master. At this time, .4P performs segmentation ifIiecessary based on the length of the message.

    The packets used in the experiments include NULL arid

    Fig. 1. Bluetooth simulation modeTABLE I

    PARAMETER VALUES FO R EXPERIMENTParameter I Average Vaues 1I M essage L ength I [5Kbytes,50 Kbytes, 25 0 KBytes I

    POLL packets for control data transmission: and DHl!DH3, and DH5 packets for user data traiisriiissiori. Weassume fixed-length upload data ai d variable-length dow~-load data reflecting the asyrrirnetric nature of the Ii iternettraffic. The parameter values used in the simulation areshown in Table I. The Inter7cetAccessTirne and the User-TliinkTinie are raiidorri variables distributed expoiieritiallywith averages shown in the table. The message length isalso a raxidom variable; distributed uniforxrily. Each sirriu-latiori is perfornied for a window of 24hours.

    We measure the perfortriarice by throughput and delay.The throughput is defined as the rate of data transmitted toa slave in a time unit. -4s for the delay, two measureinexitsare considered: conipletion delay and usev delay. The userdelay is defined as the time between the user's click andthe arrival of the first packet of the requested data. Itis equal to the sum of Bluetooth upload scliedulirry delay,I7ite7rietAccessTirne, and dowr i load scheduling delay. Thecortipletion delay is defined as the time between the user'sclick and the arrival of the last packet of the requesteddata. The completion delay represents the time until therequested service is completed.

    -4s riieritioried before: the Bluetooth upload axid down-load scheduling delays are affected by the schedulitig policyof the master. I n Bluetooth specification 1.0,a round-robin(RR) is implicitly assumed as the utiderlyirig schedulingpolicy. 111an RR policy: a master polls its slaves one byone in a fixed order. -4 slave is allowed to traIisIriit a Ixies-sage in a designated slot oxily when it has beexi addressedby the master in the preceding slot. Thus the polling se-quence of the master is critical to the Bluetooth schedulingdelay. TheRR policy is fair in the sense that each user re-ceives the same Iiuniber of polls. .4lthough it seems fair: aslave with download data should wait for other slaves evenwhen the other slaves do not need to be serviced.

    111 this paper, we consider two other scheduling poli-cies to improve the delay: weighted round vobin (weightedRR) and multi-level round r o bi n (Iriulti-level RR). In tlieweighted RR: the master polls a slave up to n times suc-cessively when there is data that needs to be transmittedto the slave! while slaves with 110 data is polled only once.

    644

  • 7/28/2019 00905527

    3/6

    3530

    % 2520$ 15

    05 50

    -9 i o

    , 800 rUTT=O.ls + 00Okbyte

    *500kbyte

    1 2 3 4 5 6 7 1 2 3 4 5 6 7number of users number of users

    (a) Message length=5 Kbytes (b) Various message lengthFig. 2. Throughput per user

    This policy improves the completion delay as we will seein the next section. On the other hand, the multi-level RRcan improve the user delay, as well as the completion delayby grouping the slaves into two classes, one consisting ofslaves with download data and the other consisting of slaveswith no data. In this policy, the master polls all the slavesbelonging to the first class up to ri times successively, priorto polling the slaves belonging to the second class: whichare polled only onceas in tlie case of the weighted RR.

    111. PERFORMANCEVALC'ATIOKThis section presents the simulation results based on the

    Internet access model described in the previous sectiou.Figure 2-a shows the throughput per user for various num-bersof usersand UserThinkTinres(denoted as U T T ) n theInternet access model where the average message length is5 Kbytes and I nternetAccessTime is 1second in average.As we can see from the figure, the throughput is largelyindependent on the number of users when the piconet isnot overloaded. Figure 2-b sliows sirnulation results wherethe average message length is varied from 5 Kbytes to 1000Kbytes while UserThinkTimes is fixed to 2 seconds. Incontrast to the previous results, when the average messagelength exceeds 250 Kbytes, throughput per user decreasesby up to the ratioof 1/71 as tlie number of users increases ton. However, it still outperforms the fastest dial-up rI iodem(56Kbps) in the marketplace even wlieu a single Internetaccess point is shared by seven users.

    Figure3 shows the performance in terms of delay. Fig-ure 3-a shows the coIripletion delay for various messagelengths ranging from 5 Kbytes to 1000Kbytes. The COIII-pletion delay increases up to 50 seconds as the number ofusers increases when the average message length is 1000Kbytes due to the heavy traffic. However. when the av-erage message length is below 5 Kbytes, the cornpletiondelay is less than 5 seconds regardless of the number ofusers. Figure 3-b shows the measureIrient of user delay inthe same environment. In contrast to the corripletion de-lay, variation of user delay is very small for the range ofmessage lengths we consider. Moreover. most of the userdelay is due to the I riter7retAccessTirriewhich is fixed to 1second in the simulation. The above results indicate thatthe Bluetooth-based Internet access service is feasible inter m of delay as wel as throughput.

    111 the previous experiInents, it is assumed that tlie

    5mw, , 1400 I,wwo . lOWkbyte- *5OOkbyte

    0 ' "" '1 2 3 4 5 6 1 1 2 3 4 5 6 7number of users number of users

    (b) User delaya) Completion deayFig. 3. The variation of deay for the message length

    I

    , ,1 2 3 4 5 6 7 1 2 3 4 5 6 7

    number 01 usersnumber of users(a) Message length=5 Kbytes (b) Message length =50 KbytesFig. 4. Completion deay in weighted RR

    round-robin is the uriderlying scheduling policy. 111 thefollowing, we present the simulation results for the othertwo policies relative to the round-robin assuming I nterrre-tAccessTime and UserThinkTime are 0.5 sec and 1sec inaverage, respectively. Figure 4 shows the completion de-lay of weighted RR normalked to RR for various nunibersof successive polls for each user: denoted asn. The resultsshow that the weighted RR policy improves the completiondelay by up to 15% when the traffic is low, as shown iri Fig-ure 4-a. When the traffic is heavy, the improvement is evenmore evident as shown in Figure 4-b: where improvementis by up to 20%. Similar results are observed for other val-ues of parameters, although they are riot iricluded ir i thispaper.

    However, weighted RR increases the user delay althoughit improves the completion delay. Figure 5shows the mea-suremerit of the user delay as wel as the corripletiori delay,both of which normalized as the conipletion delay of RR.U'hen the load is low, increase in tlie user delay is rriargiIia1as shown in Figure 5-a. However: when the picoriet is over-loaded, the user delay increases by up to 24% compared toRR as shown in Figure 5-b. Note that the increase of theuser delay is relatively small compared to the reduction inthe corripletiori delay. Overall: weighted RR policy givesperforrriaIice iniprovernent of up to 20% compared to RR.

    The delay of weighted RR can be improved by givingpriority to the users with download data as explained inSection 11. Figure 6shows the completion delay of themulti-level RR normalized to the delay of RR. The figureshows that weighted RR improves the corripletion delayby up to 25% when the load is high, and by up to 15%even when tlie load is low. From the results, wecan noticethat multi-level RR is even more efficient than weightedRR

    645

  • 7/28/2019 00905527

    4/6

    1 2 3 4 5 6 7number 01 users

    1 -

    0 8-B2 0.61

    0.8

    -$ 0.6-b 0. 40.2

    0

    1 -

    - 0. 8 -B +RR3 . +=2 comple l lon de layF" 0.6 - + n = 8+R R Completion de lay*n=2. -

    +R R Completion de lay*n=2+n =88 " - 3 2* n =6 4*"=,Pa- ..

    1 2 3 4 5 6 7I of users

    (a) Message length=5 Kbytes (b)Message length =50 KbytesFig. 5. User deay in weghtedRR

    -7. 6 ' ' ' ' 0.6' " ""1 2 3 4 5 6 7 1 2 3 4 5 6 7

    number 01 use is number of users(a) Messagelength =5 Kbytes (b) Message length =50 Kbytes

    Fig. 6 . Completion delay in multi-level RRespecially in an overloaded situation. The results also showthat the best performance is achieved when the parametervalue of n is set properly based 011 the trarisaction unit.

    Figure 7shows the results of the user delay along withthe completion delay. Siriiilarly to weighted RR, when theload is low: difference in the user delay is niargixial. How-ever, when the load is high, the user delay increases byup to 15%. Note that this number is much smaller thanthe case of weighted RR: where the increase is by up to24%. The results show that the multi-level RR irriprovesthe completion delay better than weighted RR with smallerincrease in the user delay. Thus, in the Iiiterriet web surfingenvironment with burst traffic: scheduling policies based011a transaction unit such as the weighted RR and the multi-level RR are better than policies based on a frarrie unitsuch as the pure round robin.

    IV. ANALYSISN INTER-CHAKKELNTERFERENCEIn the previous sections, a single Bluetooth unit in the

    Iiiterriet access point is assumed to service several users byforrriiiig a piconet consisting of all the users and the Iriter-net access point. In this setting, all piconet members sharea single Bluetooth channel under the control of the mas-ter of the piconet. .4 Bluetooth channel follows a uniquefrequency hopping sequence deterInined by the Bluetoothaddress of the master. Sirice different Bluetooth chariI ielsuse different frequency hopping sequerices, more than one

    +n =88 =32t - "=16 1 - 0.2 10 ' ' " " 1 01 " ""

    2 3 4 5 6 7 1 2 3 4 5 6 1number o usm number of users

    (a) Message length=5 Kbytes (b) Message length =50 Kbytes_. -_ ____. . .Fig. 7. User deay in multi-levelRR. -

    Bluetooth channel can co-exist in a single Bluetooth cell.This gives a design choiceof facilitating multiple Bluetoothunits in a single Internet access point. However, multiplechannels interfere with each other by occasionally usingthe same frequency band. Specifically, there are 79 differ-ent frequency bands defined in the Bluetooth specification[6] axid the probability of two independerit chaiinels us-ing the same frequency band at any given time is 1/79.If both channels transmit a message simultaneously whenthis happens, acollision occurs and eventually the messageis garbled.

    Of course, Bluetooth has a mechanism to detect if amessage is garbled and retransmit i t if so. On the receiptof a message: the recipient sends the acknowledgement tothe sender, usually piggybacking on the next message. Ifthe sender does not receiveaproper acknowledgement, themessage is retransmitted, usually at the next hop. Notethat Bluetooth does not require a back-off mechaxiisxntoavoid repetitive collisioris on retransmission, in contrast toother M AC protocols such as -4L OH.4 since the probabilityof collisionat the next hop is independent of the collision.This also simplifies the probabilistic model of collisions asgiven in the following.We begin our analysis with the probability of a messagetransmitted in a channel being garbled by another chan-riel. For simplicity, we assume that each message occupiesa single Bluetooth slot and all channels are aligned eachother so that the start of each slot is synchronized. Un-der this assumption, the probability of a message beinggarbled by another chamel is the product of two probabil-ities, the probability of two chaliriels hopping onto the samefrequency band and the probability of amessage being car-ried inaslot. The latter can be thought of as a normalizedload carried over a channel including both new messagesand retransmitted messages. If we denote this term as G,the probability of a message being garbled is given asG/79.Then the probability of a message not being garbled whenthere areN channels with the same characteristic, isequalto the probability of a message not garbled by any of N -1channels. Hence, weget

    In addition to the Inessage, the corresponding ackxiowl-

    646

  • 7/28/2019 00905527

    5/6

    1

    0 8

    0 2

    0

    +N 32- t N 40+N =64

    0 0 2 0 4 0 6 0 8 1S ( Ihrouohpul)Fig. 8. Throughput characteri stic

    edgement also needs to be transmitted without being gar-bled iri order that a message is regarded as transmittedsuccessfully by the sender. If weignore the case of possibleforward error correction and assume that the probabilityof an acknowledgement being garbled is the same as a riles-sage being garbled: the probability of a transmission beingsuccessful is:

    (a) Carried load (b)Maximum throughputFig. 9. Maximum throughput analysis

    Id

    Fig. 10. Alignment of channels

    P(N)=Pnocolljsjon(N)'=(1-G/79)'("-') (2)Given the probability of a transmission being successfulP ( N ) and the carried load G, we obtain the ratio of Ines-sages transmitted successfully on a chanriel; i.e.: through-put, by Inultiplyiiig G by P(N).

    when N increase beyond 40. From the results, we canconclude that the perforniance of the Internet access pointimproves as the number of Bluetooth units increases upto 40 although the improvement becomes smaller due tointer-channel interference.

    The previous analysis assunies that each message occu-pies a single slot and the channels are aligned with eachother as shown in Figure 10-b (CaseB). 111this subsectioii .=GP(N)=G(l - G/79)2(N-1) (3)

    The aggregated throughput of all of N channels, i.e.: thethroughput o the Internet access point: is given simply asS multiplied by N :S(N)=NGP(N) =NG(l - G/79)'(N-') (4)

    The relationship between S and G for variousN is shownin Figure 8. The figure shows that for smaller N thethroughput S increases almost linearly as the carried loadG iricreases. However, for large N, throughput does riotincrease beyond certain points, similarly to -4LOH.4 [7].For example, when N is 128,S increases towards the max-imum value until G reaches about 0.3and drops beyondthis point. Such threshold can be obtained by differentiat-ing S by G.

    &? = &G(1 -G/79)2(1v-l)dG (5)(1 -G/79)?(N-1)-1(1- m G )79-By setting Equation 5 equal to zero: weget G =79/(2N -1). Since G 5 1by definition, wegetN >40. This iIripliesthat such threshold exists only when Ai is greater than 40.Thus the threshold G,,, is represented as follows:

    G,,, for ranges of N is plotted in Figure 9-a. Replacing Gin Equation6 with G,,,, we obtain the IIiaxiinurn through-put S,,,(N) as shown in Figure 9-b. The figure clearlyshows that the maxiI riuni throughput does not improve

    wetry to relax the second assumption. When channels arenot aligned as in the case shown in Figure 10-c (Case C),amessage can collide by either of two messages in a chan-nel; increasing the probability of a collision. On the otherhand: Figure 10-a shows the case where the acknowledge-ment cannot be garbled by the other channel, improvingthe probability of a transmission being successful. Assurn-ing that the three cases are generated randomly and thatall the messages are carried over DH1 packets, the proba-bility of each case is given as follows:

    = 0.2128,pa - 6, , = 0.6160,P3 = -j-,- l = $ = 0.1712

    = 1-m-h - -33- l - - r ; ~ +h = -%- (7)where pi p3:and p3 represent the probability of two chan-nels being in Case- 4: aseB: and Case C: respectively, andh: m: and 1 represent the length of the header of a DH1packet (126 psec): the length of a DH1 packet includingthe header (366 psec), and the length of a slot (625 psec),respectively.

    .4pplying binomial twice, we obtain the norirializedthroughput S'(N)as follows:

    647

  • 7/28/2019 00905527

    6/6

    1

    (a) aligned-channel model (b) unaligned-channel modelFig. 11. Comparison of both models (DH1)

    ,be, 01ohann.s(a) DH3 (b) DH5

    Fig. 12. Throughput in on unaligned channels

    Figure11compares the previous model (aligned-channelmodel) and the relaxed model (unaligned-channel model).The figure shows that the difference between two models ismarginal. I t is due to the fact that the Case .4(probability:0.2128) and Case C (probability: 0.1712) offset each otherand Case B (probability: 0.6160) doIriiI iates, which is thesame case as the previous model.

    In the case of DH 3 or DH5, the equation remains un-changed but the probability p l , p2?arid p3 are computedin a slightly different manner:

    P f H 3p p 3PPH3P f H 5pf H 5P,DH5

    31-mDH3-h31- m gH 3 +h2mDa3-31

    51-mgH5 -h51-miJ H5 +h2mDV5-51

    51

    15118754031875132118751373125389312525993125

    ------0.0806,0.2149,0.7045,0.0438,0.1565,0.8317

    (9)

    wheremDH3 nd 7rlDH5 are the size of aDH 3 packet (1598psec) and the size of a DH 5 packet (2862 psec), respec-tively. The results are shown in Figure 12. Since p3is greater compared to the case of DH1, the nornializedthroughput is reduced due to a larger collision probabil-ity. Note that this does not imply that the performanceis reduced by using DH 3 / DH 5 instead of DH1, sincethe throughput shown in the figure is iiorrrialiiied by thethroughput of a single channel using DH3 arid DH5, re-spectively. In fact, the use of DH 3 / DH5 improves theperformarice since the overhead of packetization is muchless than DH1. From the results: wecan notice that bothmodels show similar characteristics and reflect the rela-tioriship between the number of channels and the resultiiigaggregated throughput.

    V. C O K C L C S I O KToday, access to the Internet is esseiitial in everyday life.

    It ishard to think of business, research, and entertainIiientwithout the Internet. Therefore, it is a requirement, ratherthari an option, to facil itate functionality of Internet accessin hand-held devices such asPDA for eve7ywhela-lntemetservices. Since hand-held devices require low cost and lowpower consumptioI1, Bluetooth has been regarded as oneof the most promising solutions for a wireless connectionbetween the user devices and the wired network irifrastruc-ture.In this paper, we have presented preliminary results onthe performance of a Bluetooth-based access network. Inthe performance evaluation, wehave modeled a simple In-ternet access scenario and simulated while varying the val-uesof various parameters including users think times, mes-sage lengths, and Internet access delay. The simulationresults indicate that the Bluetooth-based access networkprovides performarice of tens of Kbps to hundreds of Kbpsdependingon the number of users. This result is ericour-aging since the Bluetooth-based access network gives per-formarice significantly better than the traditional dial-upnetwork without the tedious wire connection. The perfor-mance can be improved if riiultiple Bluetooth radio unitsare used in the Internet access point. We have shown thatthe performance improves as the number of Bluetooth unitsincreases up to 40 based on an analytical model..4s a future work, we plan to develop a more generalBluetooth simulation package including a traffic generatorthat reflects a variety of traffic such as ftp, e-mail, andname-card exchange. We expect the siniulation packagewill allow us to evaluate various aspects of Bluetooth sys-terns including issues on scheduling policies, segmentationand reassembly, parking of user devices that are largely ig-nored in this paper. We also expect thorough evaluationwith the new simulation tool would reveal possible causesof performance bottlenecks in the Bluetooth system.

    RE FE RE NCE S[l ] . Haartsen, M. Naghshineh, J . Inouye, 0. . J oeressen, andW. Allen, Bluetooth: vision, goals, and architecture, MobileComputing and Communications Review, vol. 2, pp. 38-45, Oct.1998.[2] P. Bhagwat, . Korpeoglu, C . Bisdikian,M . Kaghshineh, andS. K .Tripathi, Bluesky: A cordless networking solution for palm-top computers, in Proceedings of the 5th International Confer-ence onMobile Computing and Networking (ACM Mobicom 99),[3] M . Albrecht, M. Frank, P. Martini, M . Schetelig, A. Vilavaara,and A . Wenzel, IP services over Bluetooth: Leading the way toa new mobility, in Proceedings of the 24th Conference on LocalComputer Networks, pp. 2-11, 1999.[4] J . Haartsen, The bluetooth radio system, IEEE Personal Com-munications, vol. 7, pp. 28-36, Feb. 2000.[5] The Parallel Simulation Environment for Complex Systems,http://pcl . cs.ucl a.edu/ proj ects/parsec/. 16) The Bluetooth Special Interest Group,http: //www.bluetooth.com/techn/index.ap, Feb. 1999.[7] bl.Schwartz, Computer-communication network design and anal-

    y s i s . Englewood Cliffs, NJ : Prentice-Hall, 1977.[8] P. ohansson, K. ohansson, U. Korner, J . Elg, and G . Svennarp,Short range radio based ad-hoc networking: performance andproperties, in Proceedings of the I E E E International Conferenceon Communications ( ICC 99), vol. 3, pp. 1414-1420, 1999.

    pp. 69-76, 1999.

    648

    http://pcl/http://www.bluetooth.com/techn/index.aphttp://www.bluetooth.com/techn/index.aphttp://pcl/