Paper Menu >>
Journal Menu >>
![]() Int. J. Communications, Network and System Sciences, 2010, 3, 311-320 doi:10.4236/ijcns.2010.33040 blished Online March 2010 (http://www.SciRP.org/journal/ijcns/). Copyright © 2010 SciRes. IJCNS Pu Scheduling Mobile Data Services in a Bluetooth Based Platform Xiaoyu Liu, Kin Choong Yow School of Computer Engineering, Nanyang Tec h no logical Universit y, Singapore City, Singapore Email: liu.xiaoyu.mac@gmail.com, kcyow@ntu.edu.sg Received November 4, 2009; revised December 10, 2009; accepted January 8, 2010 Abstract Public buses play an important role in public transportation in most parts of the world and it is still the dominant public transportation mode in some regions. Nowadays, as people switch to a mobile lifestyle, they spend significant amount of time on the traveling to work, back and forth. However, not much research has been done on how to provide some on-board service for those commuters in the public bus. This paper pre- sents a Bluetooth-based system which is inexpensive, yet flexible, and scalable to serve commuters in a per- sonalized manner using Bluetooth enabled mobile phones. However, from the Bluetooth specification, one Bluetooth dongle can connect to at most seven other Bluetooth devices. As we expect more than 7 users to use the services provided in the Bluetooth-based system (a full double-deck bus can carry around 100 pas- sengers), we need to work out an effective scheduler to schedule all the private services on the Bluetooth servers in the bus. This paper also describes a scheduling algorithm that exploits the park mode feature of the Bluetooth specification to allow more users to have access to the Bluetooth services on the bus. Keywords: Mobile Device, Bluetooth, Public Bus, Data Service 1. Introduction We have transited into the Information era, and most people are eager to get various kinds of information in convenient ways. However, due to the increasingly mo- bile and busy lifestyle, people are having lesser time for some daily activities e.g. reading the newspaper, check- ing online news, enriching themselves by casual chat or relax themselves with games. Moreover, due to the large distances and the increasing of mobile lifestyle, people are using public transportation very frequently. After an observation on the public bus or MRT in Singapore, we found that many passengers are killing time by playing some casual game or reading some text content with their cell phones or PDAs during the journey. Quite few peo- ple will use GPRS to browse news, download some au- dio or video clips or go for onlin e chattin g du e to the cost consideration. We can see that the on-board information and entertainment system in the public transportation system is required. Several proposed systems exist in providing integ rated support for commuters in using a public transportation system, such as e-ticketing and navigating through the complex metro system through mobile phones in Japan [1], and bus routes and schedules information display in bus stations in Mexico (EMI system [2]). Some others extend the public transportation routes and scheduling information to be included on a travel planner applica- tion on mobile phones, such as TramMate [3] in Austra- lia and Buster [4] in Denmark. These systems, although helpful for commuters, do not address the ‘idle-ty’ of commuters while on the ride. Some other systems address this issue by providing infotainment experience on-board the public transporta- tion, such as the system proposed by Lin and Chang [5], ALSTOM [6], and the system deployed on French TGV trains [7]. These systems include a LAN on-board the public transportation. This LAN is connected to the out- side world through either cellular networks or satellite connection. Although these systems are able to provide data live from the Internet while on the move, the re- quirement of direct connection to the cellular networks (3G/3.5G) or satellite network is still considered expen- sive nowa da y s . This paper presents the BlueBus System, a system which is inexpensive, yet flexible, and scalable to serve commuters in a personalized manner using Bluetooth enabled mobile phones. However, from the Bluetooth specification, one Bluetooth dongle can connect to seven other Bluetooth devices at most. In order to serve more ![]() X. Y. LIU ET AL. 312 than 7 users simultaneously, as a full double-deck bus can carry around 100 passeng ers, we need to work ou t an effective scheduler to schedule all the private services on the BlueBox side. This paper also proposes a scheduling algorithm that exploits the park mode feature of the Bluetooth specification to allow more users to have ac- cess to the BlueBus services. 2. System Design 2.1. Overview We aim to design an inexpensive and flexible system to serve the passenger at a personalized level in the bus, so we would like to develop the client system on the Blue- tooth enabled mobile phone. The project is named as “BlueBus” which indicate the bus is Bluetooth signal covered, passengers can use their Bluetooth enabled mo- bile phone as the interface to get the kinds of information. Beside the client side, BlueBus consists the other two parts that are base station on the bus and the administra- tion server at the bus terminal. The overall system archi- tecture is shown in Figure 1. The Mac mini will be in- stalled on the bus as the base station, which should be able to support multiple users on the BlueBus platform. The Mac mini will communicate with mobile phone through Bluetooth while it will communicat e with server via Wi-Fi. Administration server is connected to the base sta- tion, BlueBox, through the Wireless LAN connection. BlueBus end user, mobile phones are connected to BlueBox via Bluetooth connection. Function of the Administration server is to manage all BlueBox in the public buses parked in its located bus terminal. It is able to push updates and content synchro- nization to all BlueBox through Wi-Fi. Administration server located in the bus terminal office must have a sta- ble broadband Internet connection, in order to function well. Figure 1. Overall system architecture. BlueBox serves as the bridge in the overall system. It retrieves all contents from the Administration server and stores all contents in its local storage waiting for Blue- Bus commuters to browse or download. It also has to handheld all service requ ests from client applicatio n. Th e BlueBox must communicate with the Administration server periodically to ensure that it always carries the most recent content and services. In the scenario of the bus, the synchronization takes place when the bus arrives at the bus interchange terminal. The BlueBox will detect the availability of Administration server network and automatically start the serv ice or content synchron ization with Administration server. Client application is a Java application installed in commuters’ mobile phones or PDAs. Users in the bus will use this application to choose and enjoy th e services in the system. Figure 2 is the flow-chart on how to distribute the content to every single end user. 2.2. Hardware Selection 2.2.1. Adm inistra tion Server For Administration server, it must able to create a wire- less network or join the wireless network in the bus ter- minal in order to synchronize the content and do some administrative control to all BlueBox. It also needs a broadband Internet connection to download new contents Figure 2. Flow chat of overall system. Copyright © 2010 SciRes. IJCNS ![]() X. Y. LIU ET AL. Copyright © 2010 SciRes. IJCNS 313 Table 1. Recommended specifications for administration server. and synchronize end user’s upload content with all Ad- ministration servers in different bus terminals. It must be preinstalled Windows OS because Server side is devel- oped using SyncML under Windows platform, Windows XP would be preferred. Any hard disk which capacity is larger than 20GB should cater for this system. Specifications for a Administration Server Processor 1.5 GHz Memory 512 MB Hard Disk 20 GB(min) Local Area Network 802.11b/g (11 Mb ps/ 54 Mbps) 2.2.2. BlueBox The BlueBox serves as the access point to this BlueBus system. The domain of each of these BlueBox is the range of Bluetooth i.e. a circle radius 10–100 meters, depending on the power of Bluetooth dongle. So the BlueBox should have little processing power, certain storage capacity and both Bluetooth and wireless LAN capability, certainly, small physical size will be a bonus point. Based on a preliminary analysis, we chose Mac mini as the BlueBox whose specifications are shown in Table 2 below. Table 2. Recommended specifications for BlueBox. Specifications for BlueBox Processor Core Solo 1.5 GHz Memory 512 MB Hard Disk 60 GB Personal Area Network Bluetooth v2.0+EDR Wireless LAN Network 802.11g (54 Mbps) Battery life 1 hour (min) Physical dimensions 6.5” × 6.5” × 2” (L*W*H) The Mac mini has a built in Mac OS X which provides a stable Bluetooth framework for system implementation. Figure 3 shows the Bluetooth profiles available in Mac OS X [8]. We will use OBEX and RFCOMM for system development. Figure 3. Mac OS X Bluetooth profiles. ![]() X. Y. LIU ET AL. 314 2.2.3. J2ME Client Application The J2ME client application can run on any handheld built in JSR82 Blue- bile phone models satisfied the hardware re- qu ments ction, BlueBus serves as e platform for mobile data services that can be deliv- lication with Bluetooth enabled ha tive interface for users to connect to the sys- to add new content to the system administrator to add new ing the services provided. nal as vices on all connected Apple Mac OS X platform. The rogramming language we used is Cocoa which is a fa- Table 3. Recommended spec i fications for handheld device. When the server started, it will register a new Blue- tooth service provided to Bluetooth stack and start ac- ceptin. The sytically create the in and outp ne , the function as d the reply to client. d in groups called iconet [9]. The Piconet consists of a master and up to le slave use poi- t-to-point communication; if there are multiple slaves, cifications we know that one luetooth dongle can connect to seven other Bluetooth ct more users can use e services provided in BlueBus because a full double- device which is Java enabled and tooth API. According to our study in the market, there are more than 90 mo irement that indicates that we really got a large poten- tial user base. 2.3. System Require As described in the previous se th ered to users over Bluetooth. The requirements of the system are as follows: The system must be able to detect new users who are running the client app ndhelds. The BlueBus client application must provide a frie- ndly, interac tem and use the services provided. The Administration server must provide an effec- tive interface for content providers existing services. The system must be scalable and must provide an easy method for BlueBox to the system. The BlueBox must be able to simultaneously sup- port several users access The BlueBox must be easily deployable in static as well as mobile application scenarios, with occasio well as continuous conn ectivity. The Administration server must ensure automatic synchronization of content and ser BlueBox. If a BlueBox is temporarily disconnected, it must be updated as soon as connectivity restored. 2.4. BlueBox Design BlueBox is developed in p mous programming language in Mac OS. Because we expect an automatic working style of BlueBox (no user interference involved) it is implemented using IOBlue- tooth framework in Cocoa. Specifications for Handheld Device Display Resolution xels 176*208 pi Free Device Mein) P Bluin) JAVA M or 2.0 mory 2 MB (m hone External Storage16 MB Personal Area Ne twork etooth v1.1(m JAVA IDP 1.0 g a new connectionstem will automa put streamut stream when there is a w client wants to connect to the service. Communication is mostly bu ilt in request-reply model where client send the request to server first then server response to the client accordingly. When server receives a request message sociated with that service is called. Each service would have separate function to handle data from client. After some processing, BlueBox will sen 3. Bluebus Scheduling Design .1. Bluetooth Network Topology 3 Bluetooth enabled devices are organize P seven active slaves. A master and a sing n point-to-multipoint communication is used. The master unit is the device that initiates the communication. A device in one Piconet can communicate to another device in another Piconet, forming a scatternet, as depicted in Figure 4. Notice that a master in one Piconet maybe a slave in another Piconet: 3.2. Constraints on Bluetooth From the Bluetooth spe B devices at most. However, we expe th deck bus can carry around 100 passengers. We consider add more Bluetooth dongles on the Mac mini, but after Figure 4. Scatternet comprising three piconets. Copyright © 2010 SciRes. IJCNS ![]() X. Y. LIU ET AL. 315 trying, we found that the seven slaves limitation canno be solved by simply adding USB powered Bluet dongles. This is because the Bluetooth stack currently does not support multiple Bluetooth dongle connection Although multiple Blueto oth dongle connection is po ble in theory, so far, there is no Bluetooth stack in other platform that support this feature. 3.3. Scheduling Algorithm Design We want to create the Piconet which can serve all the Bluetooth end users. However, the Bluetooth master only can support seven active channels simultaneously which means only seven passengers can enjoy the services we provided in the BlueBus system. The additioof the Bluete as articipates in the ceiving packets. de with very little to participate s. The length of AM_ADDR is 3 bits while the length of PM_ADDR is 8 bits. So th eoretically d listen to the broad- ca - cheduling (the M ns- nnec- ections t ooth s. ssi- any one Bluetooth master can support 23-1 = 7 active Blue- tooth devices and 28=256 parked devices. Before a Bluetooth device entering Park mode, the master will give the device a PM_ADDR. Then this Bluetooth slave will give up the active member address, AM_ADDR if it already got one an n ooth dongle will not help in solving this issu previous se ction disc us sed. In order to serve more users simultaneously, we need to work out an effective scheduler to schedule all the private services on the BlueBox side. 3.3.1. Power Mode of Bluetooth Device Every Bluetooth device has four different power modes 10] shown below: [ Active Mode: The slave actively p iconet by listening, transmitting and reP The master periodically transmits to the slaves to main- tain synchronization. Sniff Mode: The slave listens on specified slots for its messages. It can operate in a reduced-power status the rest of the time. The master designates a reduced number of time slots for transmitting to a specific slave. Hold Mode: The device can participate only in SCO packet exchanging and runs in reduced-power status. While it is not active, the device can participate in another Piconet. Park Mode: It is a low power mo activity. Used when a slave does not need in a Piconet, but still is retain as part of it. The device is changing Active Mode Address (AM_ADDR) to Park Meod Address (PM_ADDR). With this mode, a Piconet may have more than seven slaves. As we see from the properties of the four different power modes, we need to switch the slaves between Ac- tivme ode and Park mode, in order to achieve our goal supporting more than seven devices simultaneously. 3.3.2. How to Switch between Active Mode and Park Mode The Bluetooth enabled device has an Active Mode Ad- dress (AM_ADDR) when it is in active status while it has a Park Mode Address (PM_ADDR) when it is in park/inactive statu st traffic in regular intervals. The park mode timing parameters should be negotiated with the master using Link Manager Protocol (LMP). Master also can send message to parked device to wake up the parked the de- ice and reassign the AM_ADDR to it [11]. v(In present devices on the market, the master will do the mode switching automatically instead of user con trolling. So we don’t know how to control the mode switching in the API level or Stack Level. If we can do that, the following will be the scheduling algorithm.) 3.3.3. Sch eduling Algorithm – First Versi o n Define Service Priority The Schedule Algorithm design is divided into two parts, one is the active Bluetooth devices s number of Bluetooth devices is less than or equal to 7) and the other part is overall scheduling (the number of Bluetooth devices is greater than 7). Active Devices only Scheduling Algorithm We had done a Bluetooth data transmitting speed test. First, connect individual Bluetooth enabled cell phone to Mac mini which served as the Bluetooth master in the Piconet and trying to download a 3.3MB size file from ac mini. Second, connect 6 cell phones to Mac mini and try to download the same 3.3MB size file from Mac mini simultaneously. We took the records of the data transmitting speed and consolidate into the table shown below. From the table, we can easily see that the data tra mitting speed drop a lot when there are multiple co tions existing. Generally speaking, the data transmission rate in single connection is two to th ree times of the rate in multiple connections in the cell phone. Table 4. Bluetooth data transmission rate of different mo- bile phones. Cell Phone Single connection 6 conn Model (4-5m) (4-5m) Nokia N-Gage QD 5 Kbps 5 Kbps Nokia 6280 104 Kbps 20-30 Kbps Nokia 3230 41 Kbps 15-18 Kbps O2 Xphone-IIm 16 Kbps 10 Kbps SonyErricson K750i40 Kbps 15 Kbps SonyErricson P910i20 Kbps 10 Kbps Motorola L7 3-10 Kbps N/A (always disconnect) C opyright © 2010 SciRes. IJCNS ![]() X. Y. LIU ET AL. 316 1) Bus Stop Alert ws 4) Enterta Onrtainwillrge size file which requires fast data transmitting speed. In thischeddownloads into serialof par becasave the tosmitting Aice ice vice A3 Service s Stop Alert Service lert Service A4 A6 A5 ce order is: In the BlueBus, we provide four basic services which are listed based on the priority, 1) indicates the highest priority. 2) Blue Bubble Chatting 3) RSS Neinment Do ly ntewnload ment download the E ina lavolve s case, we will ule the proces order instead rallel ordeuse it can tal data tran time. ctive Queue A0 Chatting Serv A1 Chatting Serv A2 RSS News Ser Download A4 Bus Stop Alert Service A5 Download Service 2 A6 Bu After the Scheduling A0 Bus Stop A A1 Bus Stop Alert Service A2 Chatting Service A0 A3 Chatting Service A1 A4 RSS News Service A2 A5 Download Service A3 A6 Download Service2 The actual servi A0 Bus Stop Alert Service ce Been processed simultaneously A1 Bus Stop Alert Servi A2 Chatting Service A3 Chatting Service A4 RSS News S er vic e A5 Download Service A6 Download Service 2 eredownload services orice d, all the rest ser- viimue to the low requHowevr, if there are more th the Active queu e, consid- ering them as d1 and d2, we will get the files’ size of each download service and current data transmitting rate of each channel. We can calculate the consuming time left to download the specific file. The less the download- ding time the higher the processing priority. We assume d1 got the higher priority, so d2 will start once the d1 finished the downloading. During d1 is in downloading status, d2 is in waiting status, it is possible that d2 will be swap into Park queue if there is another device parked with higher priority. We will talk about it in later section. Active and Parked Devices Scheduling There is a case which more than seven Bluetooth en- abled devices are willing to connect to the Bluetooth master. We will put the first seven devices into the Ac- tive queue, the eighth device and followings will be put in Park queue, PM_ADDR of them will be set. 3.lgorithm we are ab wake unation by - vicbelow. structure of a chat service use to send message whiler buffer is used to receive message from cha We l for the Chat service, each send the message to chat serversit message to the server, servery conne In the Ac tive queue, if th are no only one download servbe foun ces will being processed sultaneo usly d irement of the data rate. e an two download services in to 3.4. Improved Version of Scheduling A 3.3.4.1. Reserve Channel for a Certain Service Bus Stop Alert service is not a time consuming service, we just need to record the user’s registration and save the destination in the BlueBox database. After that, le to put it into the Park queue. We only need to p this user one stop before the customized desti ge. There is an alternative way to implement the Chat ser sending an alert messa e. The design is shown Figure 5 shows the data r. It got two buffers which is used the othe t server. reserve one active channe time only one sender can (BlueBox), after it depo begin to broadcast this new message to ever cted user who are online by swapping them one by Figure 5. Send and receive buffer of C1. sort Active queue 0-6 based on the priority level Priority high low sort Park queue 0-n (n<256) based on the priority level Priority high low compare (AQ [6], PQ [0]) if priority of AQ [6] >= PQ [0] Return; else if priority of AQ [6] < PQ [0] //swap (AQ [6], PQ [0]); set AQ [6] PM_ADDR; set PQ [0] AM_ADDR; add AQ [6] to Park queue, resort the Park queue; add PQ [0] to Active queue, resort the Active queue; compare( AQ[6], PQ [0]); Copyright © 2010 SciRes. IJCNS ![]() X. Y. LIU ET AL. 317 send a message to others. T take the active channel and communicate with server in a serial manner. C1 de- posits the message to server, then the server will broad- cast the message to C2 and C3 when they are taking the channel. C3 will not send its own message to server in this server swap broadcasting roun So after 3), every- one got be dis- one from Park queue to Active Queue. After that, the second sender will deposit its composed message to chat server, then server will do the same thing to broadcast this new message to all online users. Certainly, th e serv er is also able to send the message to the specific recipient. We will limit the message length to 160 English charac- ters which is as the same as the normal SMS length. As- sume the average Bluetooth data transmitting rate is 5Kbps, then the average time to transmit one message will cost: 160bytes / 5Kbps = 0.03s If there are 20 users using the Chat service, the server can finish the “swap broadcasting” in around 0.6s, within one second which should be acceptable for the users. We take an example of three users are using the public chat service. We use C1, C2 and C3 to indicate the three users. From Figure 6, we can see that C1 and C3 want to hey d. the message from C1. Message 1 will played on every user s’ screens , and the mes sage one will be cleared from receive buffer. Then it goes to next message deposit round, it is same as round 1. Chat server will keep all the messages. Chat (a) (b) (c) Figure 6. Swap-broadcast message from C1. server will broadcast the message based on the time stamp of message itself which will ensure the accuracy of the message received by users. As for the RSS News service, we also can use the similar mechanism, reserve one channel for RSS News service use only. We can do a calculation that, normally the size of one RSS News thread should be within 2KB which equal to 300 to 400 English words. It will cost the user less than 2 minutes to finish the reading on 176*208 sized cell phone screen, one minute is needed at least. Within 1 minute the server can send at 60 RSS News threads to users that mean it can su pport up to 60 us ers to read RSS News with one channel used (Figure 7). Download service must be processed one by one unless the download file size is small. With the above statement, we can reserve the 7 active channels for different services. Download and Bus Stop Alert services only reserve one channel for each while both Chatting and RSS News service can reserve 2 cha- nnels for each, because they are more timing issue is more critical for them. 3.3.4.2. Random channel allocation and Sub Queue Algorithm We also can split the Park Queue to several Park queues based on how many services we provided. In current stage, ws Stop e can reform 4 Park queues, which are Bu (a) ( b ) (c) Figure 7. Swap-broadcast message from C3. C opyright © 2010 SciRes. IJCNS ![]() X. Y. LIU ET AL. 318 Alert Queue, Chat Queue, RSS News Queue and Down- load Queue, listed based on the priority from high to low. Once there is an active channel is free, we will process the service queue based on its priority level. If there are more active channels are free, more service queues will be processed by serve r. Because there are 7 active channels while there are only 4 services currently, some service park queue, such as Chat service and RSS News service, can split its park queue equally into 2 sub-park queues. Each sub-park que- ue will take a channel for processing which may reduce the time consuming for one round “swap broadcasting”. 4. System Evaluation For the system evaluation, eight Bluetooth 2.0 Class 1 + EDR dongles are used. The experiments were conducted to measure the transmission rate and interference that may affect the transmission rate due to co-existing pi- conets and the effect of obstacles in-between the Blue- tooth devices to the transmission rate. Therefore, three test sets were conducted as follows: 1. Single piconet Test, 2. Multiple piconets test, and 3. Obstacle test. For every test, the experiment is conducted five times and the average is taken and plotted to a graph. the Bluetooth Specification [12], this drop is du e to the 4.1. Si This test was conducted to measure the effect of increas- ing number of slaves on a Bluetooth master to its trans- mission rate. Figure 8 shows the test result. For the transmission to on ngle Piconet Test ly one slave on a master dongle, it achieved the data rate of 1.6 Mbps, which is fairly close to the theoretical transmission rate of Bluetooth, i.e., 2.0 Mbps. However, as the number of slave increases, the total data rate drops quite significantly. With only one additional slave, the total data rate drops by 400 kbps to 1.2 Mbps. According to Figure 8. Effect of the number of slave dongles on the data rate in one piconet. ct that when there is only one slave, the master is able ionLess – User) logical link rather than ov o only 600 kbps (from 1.6 Mbps when there is only one lave) – a very significant reduction. However, on subse- quent addition of slaves, the total data rate varies only slightly from the two-slave case, where the total data rate decreases as the number of slaves increases. Although there is a dro p in th e to tal dat a rate, each slav e sti ll get s an equal share of bandwidth. At the limit of 7 slaves, each slave achieves a data rate of around 100 Kbps which is considered acceptable for the BlueBus services. 4.2. Multiple Piconets Test The Bluetooth Class 1 device could reach the range o essentially the sa fa to transport L2CAP (Logical Link Control and Adapta- tion Protocol) broadcasts over the ACL–U (Asynchro- nous Connect er the ASB–U (Active Slave Broadcast – User) or PSB–U (Parked Slave Broadcast – User) logical links. This allows the transmission to be more efficient in terms of bandwidth (if the physical channel quality is not too degraded) for the case of only one slave. Also, as only one device is allowed to transmit/receive in each 625 sec time slot of a Bluetooth transmission, the data rate of one of the slaves (in the two-slave case) drops t s f 100 m, and this is the Bluetooth device planned to be used on the Blu eBus. Since the in terior area of th e bus is less than 100 m, having four server dongles (the dis- patcher is not involved in the experiments) may intro- duce interference problem. Therefore, this test is in- tended to see the effect of the increasing number of co-existing piconets on the transmission rate. Figure 9 shows the data rates achiev ed when multiple piconets co-exist. Here, ‘m’ denotes the master dongle and ‘s’ denotes the slave dongle. In the base experiment of one server and one client (which is me as the case of only one slave in Figure 8), it can achieve a data rate of 1.6 Mbps. However, if multiple Figure 9. Effect of the number of master dongles on the data rate. Copyright © 2010 SciRes. IJCNS ![]() X. Y. LIU ET AL. 319 arry. Therefore, this test is used to find out th e influence various typical objects in between the Bluetooth transmission path on the Bluetooth’s transmission rate. In this test, the master and the slave dongle are separated 1.5 meters apart. The separation is based on the deriva- tion from Figure 7. All the obstacles are placed within close proximity to the receiving dongle (around 10 cm). If a user uses his mobile device on a bus, it will be close to the objects that he is currently holding (books, news- papers, etc) or the seat in front of him. In this test, only one master and one slave are used. Figure 10 shows the result of putting different obsta- cles in the Bluetooth transmission path. The obstacles used are representative of the objects that are typically in ious, since the bus will be packed k, the Bluetooth will perform r books or printed media. The bo t- e of water represents any liquid that a person may carry. masters exist (i.e. multiple piconets), the performance drops. It can be seen from Figure 9 that the drop is not very significant, and it is concluded that the multiple piconets interference does not affect the data rate much. 4.3. Obstacle Test Bluetooth is a wireless technology, and as such, its transmission rate may be subjected to the objects that hinder its transmission path. Inside a bus, the obstacles can be the seats or the metal poles, including the people packed inside the bus with the various objects they may c of the bus or the objects that people may carry. The obstacle of human body is obv by passengers inside. The 3.5 cm thick book used in this test represent any types of printed media of pages bound together such as text books, newspapers, magazines, etc. A thick book is used, since if the transmission rate is good on the thick boo equally well on thinn e tl The plastic glass represents materials made up of plastic such as the plastic bottles, and finally the glass represents the windows of the bus. As Figure 10 shows, different obstacles of different materials affect the data rate to different extents. How- Figure 10. Influence of different obstacles on the data rate. ever, the figure still shows acceptable performance on all the obstacles tested. Nevertheless, to minimize the im- pact of obstacles inside the bus, the master dongles s ho u ld be mounted along the ceiling of the bus and connected to the BlueBox by USB cables. As the distance limit of a USB cable is 5 m, additional USB hubs can be used to extend this distance limit. 5. Conclusions and Future Development We had designed and developed the BlueBus system which is able to provide variety information and enter- tainment services to passengers in a personalized level and give them a good user experience. We have shown that, based on the test on real Bluetooth dongles that even when a Bluetooth device is full with active connec- tions, it can still maintain relatively good data rate for each slave on 100 Kbps. The experiments conducted also shows that the interference of co-existing Bluetooth pi- conets does not affect the data rate much. This is also true for the obstacle experiment where the Bluetooth data rate does not vary widely when it is presented with dif- ferent materials. We are planning to provide more interesting services such as send birthday or greeting cards, share personal Mobile Log (similar with Blog) etc. Apart from this, we system for public transport us- ing mobile terminals,” Proceedings of the 2003 ACM nt of also aim to find a way in the Bluetooth stack level or scheduling algorithm to improve the multiple user sup- port feature. 6. References [1] K. Goto and Y. Kambayashi, “Integration of electronic tickets and personal guide SIGMOD International Conference on Manageme Data, pp. 642–646, 2003. [2] T. Y. Banos, E. Aquino, F. D. Sernas, Y. R. Lopez, and R. C. Mendoza, “EMI: A system to improve and promote the use of public transportation,” Conference on Human Factors in Computing Systems, CHI’07 Extended Ab- stracts on Human Factors in Computing Systems, pp. 2037–2042, 2007. [3] J. Kjeldskov, S. Howard, J. Murphy, J. Carrol, F. Vetere, and C. Graham, “Designing TramMateña context-aware mobile system supporting use of public transportation,” Proceedings of the 2003 Conference on Designing for User Experiences, pp. 1–4, 2003. [4] J. Kjeldskov, E. Andersen, and L. Hedegaard, “Designing and evaluating buster: An indexical mobile travel planner for public transportation,” Proceedings of 19th Australian Conference on Computer-Human Interaction: Entertain- ing User Interfaces, pp. 25–28, 2007. [5] K. D. Lin and J. F. Chang, “Communications and enter- C opyright © 2010 SciRes. IJCNS ![]() X. Y. LIU ET AL. Copyright © 2010 SciRes. IJCNS 320 ie, “Implementing passenger information, enter- , and security systems in light rail transit, Research Circular E–C058: 9th National nsit Conference, pp. 528–533, 2003. ] “French railways launch their on-board internet and mul- mentation/DeviceDrivers/Con- oth tainment onboard a high-speed public transport system,” IEEE Wireless Communications, Vol. 9, pp. 84–89, Feb- ruary 2002. [6] V. Scinte tainment” [1 Transportation Light Rail Tra [7 timedia connectivity services on TGV high-speed train,” Appear, the Context Company, 2007. http://www.appear- networks.com/French-Railways-launch-their-on.html. [8] “Bluetooth device access guide in Mac OS X.” http: //developer.apple.com/docu ceptual/Bluetooth/index.html. [9] “Bluetooth network topology.” http://developers.sun.com /techtopics/mobility/midp/articles/bluetooth1. 0] “Bluetooth power mode overview.” http://72.14.235.104/ search?q=cache:4LenKxr14d0J:www.ece.ualberta.ca/~sb ates/downloads/Mint702_PartSix. ppt+how+to+assign+th e+PM_ADDR&hl=en&gl=sg&ct=clnk&cd=3. [11] “Simple differences between Sniff mode and Park mode.” http://www.palowireless.com/infotooth/knowbase/baseba nd/78.asp. [12] “Bluetooth core specification V2.1 + EDR,” Blueto SIG, 2007. |