Performance Evaluation of Web Services Invocation over Bluetooth Vincenzo Auletta
[email protected]
Carlo Blundo
[email protected]
Emiliano De Cristofaro
[email protected]
Guerriero Raimato
[email protected]
Dipartimento Informatica e Applicazioni Universita` di Salerno I-84081 Baronissi (SA) Italy
ABSTRACT
few years ago dedicated applications were limited to the device environment. In the last years, we have witnessed a mutation of users’ needs. This leaded to an evolution of the technology, intended to provide interaction and interconnectivity. Mobile devices have been affected by this evolution, as showed by the introduction of new protocols for wireless communications, such as IRDA, WLAN, and GPRS. Since IRDA connections are limited to two devices with a direct line of sight, IRDA is not practically useful for a real intercommunication scheme. On the other hand, WLAN has been designed as a powerful technology to support multipoint connections, though diffusion on mobile devices and particularly on smartphones is still low. GPRS is widely supported but provides connectivity at modest speed and requires a personal account with a phone company. At the same time, we witnessed the growth of a low-cost, powerful and standard technology, namely, Bluetooth [4]. This technology is a versatile and flexible short-range wireless network technology with low power consumption. It operates in a license-free frequency, so that user is not charged for accessing the network nor needs an account with any company, thus allowing a relevant decrease of communication costs. Nowadays Bluetooth technology is used in many widespread different devices, such as handhelds, mobiles, smartphones, laptops, PDAs. A thorough overview on Bluetooth is given in [6] and [23]. Several research groups are proposing frameworks for developing applications over Bluetooth-based networks (for instance, [21] and [26]) and evaluate the possibility of using this technology for building ad-hoc networks suitable for dedicated applications, such as voice transmission [24], audio streaming [27], context-aware applications [22], and internet access point [25]. Within a few years, most of the devices accessing the Web and the Web Services will be mobile. Therefore, we need solutions that encompass networking, systems, and applications issues involved in realizing mobile and ubiquitous access to the services. In this paper, we analyze how Bluetooth can be used to design, develop, and deploy Web Services-based applications. In fact, we propose and evaluate a framework that allows the interaction of mobile devices with Web Services using Bluetooth as communication
Mobile devices should allow users to exploit services anytime, without any place restriction and in a transparent way. The Bluetooth technology achieves this feature, by providing services at a low cost and with a low power consumption. In a few years, most of the devices accessing the web services will be mobile. In this paper, we evaluate performance of a framework allowing a Java application programmer to directly interface Web Services from a mobile device using a Bluetooth connection. Our work focuses on enhancing Web Services’ range of action, presenting a proof of concept of how Web Services-based application can use Bluetooth technology as communication channel. Furthermore, our work is also dedicated to allow the framework to use all the different settings and connection modalities provided by Bluetooth technology. This paper evaluates the usability and efficiency of the framework in a real scenario using mobile devices with limited resources.
Categories and Subject Descriptors D.4.4 [Operating Systems]: Communications Management—Network Communication
General Terms Measurement, Performance, Design
1. INTRODUCTION In the last years, mobile devices such as smartphones or PDAs have enhanced their range of action, turning into fundamental working instruments. Nowadays, mobile devices are able to provide powerful and useful features. Up to a
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. PM2 HW2 N 2006, October 2, 2006, Torremolinos, Malaga, Spain. Copyright 2006 ACM 1-59593-502-9/06/0010 ...$5.00.
1
built on top of the Connected Limited Device Configuration (CLDC) [11]. This layout allows to hide physical details and to create an abstract environment for heterogenous devices, achieving a high degree of interoperability, that perfectly suits our goal of invoking Web Services from mobile devices over a Bluetooth connection. Indeed, Bluetooth allows a wireless interaction among strongly diversified devices (mobile phones, printers, notebooks, PDAs, computers, ...). Within this technology, communications can take place by mean of integrated and cheap devices with small energy consumption. This technology achieves its goal by embedding tiny, inexpensive, short-range transceivers into the electronic devices that are available today. When two Bluetooth products come within their ranges, address and capability details are automatically exchanged. Bluetooth devices operate in a licence-free frequency (starting from 2,4 GHz). Using version 1.2 one can establish a 1 Mbps link (a 2 Mbps link is supported by Version 2.0) [4]. Moreover security and error support allows to assure efficient and reliable connections even in environments with a strong presence of interferences, electromagnetic fields, i.e., electrosmog. The Bluetooth standard allows the creation of WPAN (Wireless Personal Area Networks). Bluetooth-enabled devices communicate among each other building and dynamically setting up the network. This is based on SDP (Service Discovery Protocol), that allows Bluetooth devices to discover services exposed by the others, and the instauration of a real communication channel between each pair of devices. The protocol that provides data exchanging services is the Logical Link Control and Adaptation Layer Protocol (L2CAP). It handles multiplexing and segmentation, through the use of the PSM (Protocol and Service Multiplexing) and SAR (Segmentation And Reassembly). Group abstractions and Quality of Service (QoS) features are supported as well. Higher level protocols are built over this basic layer, like RFCOMM or OBEX. Figure 1 presents an overview of the Bluetooth stack. RFCOMM provides emulation of serial connections,
channel. The proposed framework permits application programmers to directly interface Web Services environment establishing a new policy that is totally transparent to programmers. In this way, application programmers can easily deploy Web Services-based applications using a mobile and completely free communication technology, such as Bluetooth, that is widely supported by smartphones that nowadays are in very spread use. Within this scope, many applications can be designed, such as information retrieving (eg. train timetables in a station) or micropayment applications (eg. buying ticket in a cinema or on a bus). A different implementation of the framework is provided in [20]. It is based on an implementation of the JSR-82 API that provides a high level access to the Bluetooth stack implementing only the RFCOMM communication protocol. In this paper, we permit a lower-level access the Bluetooth stack through a software layer we developed. In this way, we give application developers the possibility to set the connection modality used by Bluetooth and adopting the modality that better suits application requirements (i.e., setting different error correction features, different use of time slots). Performance experiments were useful for evaluating the real applicability and lightness of the deployed framework. Test-bed experiments confirmed the correct behavior of the proposed framework and showed that Bluetooth is well suited for the physical layer of Web Services access. The rest of this paper is structured as follows. In Section 2, we recall some general concepts about the endorsed technologies, such as Java and Bluetooth. In Section 3, we present and motivate our design choices with respect to the technologies employed in the framework. In Section 4, we describe the architecture of our framework, which enables programmers to design client applications accessing Web Services over a Bluetooth channel. Finally, in Section 6, we present the results of our experiments.
2. ENDORSED TECHNOLOGIES The goal of this paper is to design a framework that allows Java programmers to easily and directly invoke Web Services from mobile devices over a Bluetooth connection. The basis for our work are Java 2 Micro Edition (J2ME) [9] and the Standard Bluetooth Technology [4]. The former describes how to write Java applications on mobile devices, while the latter defines details for the communication between devices. The advantages of using Java as programming language are the code portability and an increase of the mobile devices flexibility. J2ME defines a standard environment targeted to mobile devices. In particular, it provides the support for deploying dedicated applications, named MIDlets. These allow programmers to increase available features and capabilities of mobile devices, turning them into a complete and powerful tool. J2ME was designed as a collection of configurations, where each configuration is tailored to a class of devices. Each configuration consists of a Java Virtual Machine and a collection of classes providing a programming environment for the applications. Configurations are completed by profiles, which add classes to provide additional features suitable to a particular set of devices. The MIDP (Mobile Information Device Profile) [15] is a set of Java libraries that permits to create powerful applications for mobile devices with limited resources. This profile is
Figure 1: The Bluetooth Stack it supports framing and multiplexing and achieves all the required functions for serial data exchange. OBEX is built on top of RFCOMM to implement object exchange, such as files and vCards. From a connection point of view, Bluetooth distinguishes two different links: ACL (Asynchronous Connectionless) and SCO (Synchronous Connection Oriented). The former sup-
2
• Broadcom BTW (not free): it is addressed to PC OEMs and accessory manufacturers to quickly and easily add Bluetooth wireless technology to desktop and notebook PCs running Windows [7].
ports packet-switched, point-to-multipoint connections and is typically used for data transmission over L2CAP. The latter supports symmetrical, circuit-switched and point-topoint connections and is typically used for 64-Kbps voice transmission, for which a minimum granted bandwidth is required. Currently, SCO is not supported by the L2CAP layer. At the application level, Bluetooth profiles describe several scenarios where Bluetooth technology is responsible of transmission. Each scenario is described by a user model and the corresponding profile provides to the application a standard interface to interact with the Bluetooth protocols. Although the synergy between MIDP and J2ME technologies supplies a large number of communication schemes, it does not provide support for the Bluetooth technology. Therefore, it has been introduced the Java APIs for Bluetooth Wireless Technology (JABWT) proposed by the Java Expert Group JSR-82 [12] that provides a standard and high-level support for handling Bluetooth communications in Java applications. These APIs operate on top of CLDC to extend MIDP functionalities. They are still in progress, but around twenty leading companies have adopted them in their devices. The last released version, Version 1.1, provides support for:
• BlueZ (free): it is the official Linux implementation of Bluetooth standards specifications; the code is licensed under the GNU General Public License and is included in the Linux 2.4 and Linux 2.6 kernel series; it provides a direct access to the transmission layer and allows developers to set several parameters of the communication [14]. • Microsoft (Windows XP SP2 embedded): it provides the support for most of Bluetooth profiles, essentially the ones based on the RFCOMM protocol [18]. • Mobile devices vendors’ embedded stacks: vendors providing Bluetooth-enabled devices have to build their own Bluetooth stack; the most famous ones are Nokia’s and Ericsson’s. The most common implementations of JSR-82 APIs are: • Atinav aveLink suite (not free - 15 days trial version): it offers both a standard implementation of the Bluetooth stack and the implementation of all the standard profiles for ANSI C, JSR-82 for J2SE, JSR-82 for J2ME (Sun KVM and J9 CLDC VM), Windows, and Windows CE [5].
• Data transmission on the Bluetooth channel (audio and video are not supported). • Protocols: L2CAP, RFCOMM, SDP, OBEX. • Profiles: GAP, SDAP, SPP, GOEP.
• Rococo (not free): it is a complete product that provides the Bluetooth Stack and the integration layer, the JVM and the JSR-82 implementation layer both for J2SE and J2ME [8].
The architecture of J2ME environment and the Bluetooth API interaction is showed in Figure 2.
• Avetana (not free - 14 days trial version): it enables writing J2SE Java-Applications to access the Bluetooth layer; it is available for Windows, MacOS X, and Linux platforms [2]. • Blue Cove (free): provides the Java JSR-82 support for J2SE applications over the Windows XP SP2 Bluetooth stack [3]. Since we want our framework to operate in a free and open environment, we have chosen the Linux and the BlueZ stack solution. Choices made in [20] brought to the use of a not free environment, such as Windows. Moreover, with the use of BlueCove [3] the framework is bounded to establish only RFCOMM connections and it is inhibited to access and manage settings of communication layer. On the other hand, our choice permits a complete and transparent management of underlying layers. Since we want our framework to be transparent to programmers, we need to use the JSR-82 API standard both on client applications and server ones. This allows server applications to run both on mobile devices with limited computation power, using J2ME as environment, and on more powerful devices, using J2SE environment. Finally, with respect to the Web Services invocation we have considered both the XML-RPC [19] and the JAX-RPC [10] solutions. To have a complete data independent infrastructure, we have chosen JAX-RPC. In fact even if XMLRPC is lighter, easier to use for developing purposes, and more suitable to the bandwith limitation of the Bluetooth
Figure 2: J2ME - Bluetooth API interaction architecture Using JABWT, it is possible to interact with the Bluetooth stack in a Java application. In particular, it is possible to call services such as device and service discovery, establishment of RFCOMM, L2CAP, and OBEX connections.
3. DESIGN ANALYSIS In order to interface applications with the physical layer, we need a Bluetooth Stack that is responsible of implementing the Bluetooth wireless standards specifications. In order to use the Java APIs for Bluetooth, a real implementation of the JSR-82 specification is necessary on the device. There are several different Bluetooth stacks targeted to different devices, applications, and operating systems. The most common ones are:
3
• WSC: Web Services Container, it replies to client requests communicating through the PROXY. The interaction between these three components is described in Figure 5.
Figure 3: Our Scenario channel, the JAX-RPC solution provides more powerful features. Namely, exchanging user defined data types, naming structures and arrays, and specifying message processing instructions. Moreover, the use of JAX-RPC in the framework allows developers to achieve a full and powerful compatibility in Web Services invocation without any limitation of the XML-RPC solution.
4. ARCHITECTURE OVERVIEW In this section we will present a lightweight framework that allows application programmers to design client applications running on mobile Bluetooth-enabled devices that invoke remote Web Services. Physical details and ad-hoc data management must be hidden to users and developers, as showed in Figure 3. The architecture of the framework follows the one presented in [20]. We assume a client-server interaction, where client and server communicate using SOAP [16] as messaging system. As described in the previous section, client applications work in the J2ME environment, using the JSR-82 APIs to access the Bluetooth channel. However, JSR-82 APIs do not provide the required support in order to address a Web Services Container and make an invocation of a Web Service. To overtake this limitation, our framework introduces a middleware entity that acts as a distributed proxy to interface client entities to the Web Services Container (see Figure 4).
Figure 5: Architecture
5. 5.1
PROXY IMPLEMENTATION SLAVE Implementation
To allow client applications to invoke Web Services over a Bluetooth channel, our framework provides a dedicated API, called WSBT (Web Service over Bluetooth), running on the mobile client applications. This package encapsulates all the details related to data management and to the communication over the Bluetooth channel. The API is modeled on the Axis Client [17] APIs, and thus it is JAX-RPC compliant [10]. The core class of the API is the Call class and the invocation of the Web Service is implemented by its method invoke. This guarantees the portability of applications based on Axis Client on a mobile Bluetooth-enabled device, provided that the applications are J2ME-compatible. The client side of our framework is implemented by our Java package WSBT (Web Service over BlueTooth). To port the application on the mobile device it is sufficient to import our package instead of the Axis one. In this way, we still maintain the same server-side architecture and guarantee the interoperability of the application running on the mobile device with any Web Service. Client applications must have the capability to serialize data before executing the Web Service request and deserialize after receiving the response. Moreover, since we have chosen to exchange data over L2CAP Bluetooth connections (see Section 3), messages travel over the Bluetooth channel as byte arrays. Thus, the WSBT package is in charge of serializing the SOAP request message into a byte array before sending it over the channel to the MASTER counterpart and of deserializing the SOAP response message from the byte array received from MASTER. To guarantee the interoperability with any Web Service messages must be formed according to the SOAP specification. Thus, we need a J2ME-compatible library that can be used in a MIDlet to serialize messages according to the
Figure 4: Proxy invocation scenario Therefore, our framework is composed by the following entities: • CLIENT: it runs on a mobile devices and uses Web Services. • PROXY: it interfaces clients with the Web Services Container. It is a double-sided entity: – SLAVE: one side lies on the client, taking care of data serialization/deserialization, and of communication over the Bluetooth channel. – MASTER: the other side lies at end of the Bluetooth channel, acting as master device to receive requests, posting them to the Web Services Containter, and sends back the responses received from the WSC.
4
SOAP specification. Our framework uses the kSOAP library [13] to serialize/deserialize the messages on the client side. The kSOAP library provides high-level classes to construct the envelope, the body, and the header of the SOAP message and to specify their elements. The library supports only simple data types such as strings, integers, etc. However, it is possible to extend these basic functionalities to insert into the SOAP message any complex datatype by simply providing custom classes for these data types that implement the Java KvmSerializable interface. The use of the WSBT package allows developers to discard management and details of Bluetooth connection, allowing the programmer to invoke a Web Service in the Axisstandard style.
Figure 7 shows the sequence diagram of the messages exchanged between the components of our framework. 1. CLIENT uses the normal Web Services mechanism by using the Call class. 2. Through the use of the WSBT package, SLAVE serializes data to prepare SOAP requests for a remote web service, without taking care of the physical detail. 3. SLAVE discovers MASTER, establishes a Bluetooth Connection at a L2CAP level and sends SOAP requests as a byte stream. 4. MASTER receives requests and transforms byte streams into SOAP requests, posting them to WSC.
5.2 MASTER Implementation
5. WSC elaborates SOAP requests and returns SOAP responses.
As previously discussed, we need the MASTER side of the PROXY to act as Bluetooth master device, waiting for client connections, receiving their messages containing SOAP requests and sending back responses. As a result of our design choices (see section 3), the implementation of MASTER must satisfy three requirements at the same time: to be based on the Linux BlueZ stack; to be Java JSR-82 compliant; to work over L2CAP connections. With respect to the L2CAP communication protocol for the server side, BlueZ provides only the appropriate interface but not a real implementation of the connection management. For this reason, in our framework we implemented all the low-level interaction operations, such as listening, accepting incoming connections, sending and receiving bytes, setting connection parameters, handling multiple connections, managing errors. In fact the BlueZ stack only provides C-socket interfaces for the interaction with the Bluetooth channel. Since the goal is to provide to developers a Java API (JSR-82 compliant), it was necessary to develop an interaction interface between the C BlueZ stack and the Java API, available at the front end. We used JNI (Java Native Interface) to allow Java code to call the native applications provided by BlueZ stack. An overview of the implementation is given in Figure 6.
6. MASTER forwards back responses. 7. SLAVE receives SOAP responses as byte streams over the Bluetooth connection and deserializes them to return the results to CLIENT.
6.
EXPERIMENTAL RESULTS
We ran some experiments to evaluate the performances, the real applicability, and the lightness of the deployed framework. To do that, we have set up the following small testbed: • Server-side: Workstation HP XW6000, Xeon 2,8 GHz Dual-Processor, 2 GB RAM, with Trust BT 180 Bluetooth USB dongle, running Fedora Core 4 with 2.6.11 Linux Kernel. • Client-side: Nokia 6630 Smartphone with Symbian OS, MIDP 2.0 and JSR-82 APIs support. In all our experiments we called a test Web Service implementing just an echo service. Our tests were aimed to evaluate the efficiency of our framework in terms of used bandwidth and of serialization/deserialization performances. In our experiments we evaluated: 1. Discovery delay required by the smartphone to detect the master device. In our test we evaluated the performances of discovery service, using the standard JSR-82 approach. 2. The throughput of the application in terms of Kbytes per second assuming that the SOAP message contains only a string. 3. Serialization/deserialization delay assuming that the SOAP message contains an array of complex Java data types. 4. The performances of our framework with respect to the different Bluetooth communication modalities.
Figure 6: MASTER implementation overview To interact with the WSC, the MASTER side of the proxy needs to send a SOAP request to the WSC in order to get the correspondent SOAP response. To do that, a simple HTTP POST operation is performed, using the free Apache Commons HttpClient Java package [1]. This package allows building HTTP-aware client applications.
The first experiment was aimed to measure the discovery delay. In fact, our framework should allow to dynamically discover Bluetooth servers and not to be bounded to hard-coded settings. For this reason, the framework handles Bluetooth standard policies for devices and services discovery. We ran 50 discovery operations, getting only 1 timeout
5
Figure 7: Sequence Diagram
Figure 9: Discovery delay using caching mechanism on the Nokia 6630 smartphone Figure 8: Discovery delay on the Nokia 6630 smartphone
times. To guarantee that for each iteration the device were in the same initial conditions, we used dedicated threads. In fact, for each invocation a new thread was created and destroyed after the operation. Figure 10 shows the throughput of the application in terms of KBytes per second, with respect to the string size contained in the SOAP message. We observe that for short messages the cost of communication set-up affects the performances. When the size of messages gets over 5 Kbytes, throughput settles around 11 KBytes per second. The third test was aimed to evaluate the performances of the framework while handling complex objects to show its correct behavior and its robustness. Applications handled a custom object, i.e. Address, composed by six strings and two integers. Performances analysis was made by stressing the number of exchanged objects. Figure 11 shows the processing times for serialization and deserialization. Differences between these two operations are due to the different
error (see Figure 8). In all the other cases, we measured a discovery delay that is very close to 14,5 seconds. However, introducing a cache mechanism to store addresses of recently used Bluetooth devices we were able to reduce delays to a few hundreds milliseconds (see Figure 9). The second test was aimed to evaluate the throughput of our framework for an echo string service invocation. We ran tests for strings of size from 0,5 Kbytes to 15 Kbytes (the string size is increased by 0,5 Kbytes in each test). We measured the time needed to serialize input data, to send a SOAP message to the MASTER, to accomplish Web Service invocation on the WSC, and to receive and deserialize the SOAP response. For each test on strings of different size, we repeated the invocation 50 times and computed the average
6
Figure 10: Throughput for the String Echo Service on the Nokia 6630 smartphone
Figure 13: Throughput for an Address objects array on the Nokia 6630 smartphone
ent assignments of time slots. Masters have to periodically poll slaves to know if they have data to transmit. Bluetooth standard defines three different modalities of slave transmission: slaves can hold the channel for only one, three or five consecutive slots. Independently from the modality used by slaves, masters transmits only in odd time slots. Moreover, Bluetooth standard defines for ACL links two different types of packets: Data Medium Rate, DM, which provide a 2/3 FEC Hamming code (i.e. error correcting capabilities), and Data High Rate, DH, which provide no FEC coding (i.e. no error correction at all). Therefore, we have six different data packets according to slots assignment and data encoding: DH1, DH3, DH5, DM1, DM3, and DM5. We tried to evaluate the performances of the framework on our test-bed for each of such combinations. But, we have noticed that the Nokia 6630 smartphone forced the connection to its built-in settings. To overcome this limitation, we have introduced in our test-bed another client, a PC acting as client device:
Figure 11: Serialization and deserialization times for an array of Address objects of length n on the Nokia 6630 smartphone behavior of the kSOAP XML parser. Figure 12 shows that the time for sending requests is greater than the time for receiving responses. The approximatively constant difference between the time of the two operations is due to the asymmetry of the Bluetooth channel. Finally, Figure 13 shows
• HP Pavilion DV4266EA Notebook PC, Intel Pentium M 740 processor (1,73 GHz), 512 MB DDR RAM, built-in Bluetooth chipset. The experiments were run with the same modalities of the previous ones, with strings and arrays of Address objects. In the new scenario, we ran the tests with the six different packet types, witnessing a quite remarkable speed gap (see Figures 14 and 15).
Figure 12: Send and receive times for an array of Address objects of length n on the Nokia 6630 smartphone how the throughput obtained with this test settles around 20 Kbytes per second for an array containing more then 15 Address objects. In our last experiment, we wanted to test framework’s performances with the different Bluetooth communication modalities. Bluetooth standard establishes that devices make a frequency hop every 625 microseconds. For this reason, Bluetooth communications can be viewed as divided in time slots. Bluetooth defines different models of master-slave interaction (communication modalities), according to differ-
Figure 14: Send and receive time for an Address objects array using DM time slotting Our experiments show that the framework correctly uses the different communication modalities provided by the Bluetooth specification. Thus, application programmers using
7
[7] Broadcom bluetooth solutions. http://www.broadcom.com/products/Bluetooth/BluetoothRF-Silicon-and-Software-Solutions. [8] Impronto rococo software. http://www.rococosoft.com/. [9] Java 2 platform, micro edition (j2me). http://java.sun.com/j2me/. [10] Java api for xml-based rpc. http://java.sun.com/webservices/jaxrpc/. [11] Jsr 30, jsr 139: Connected limited device configuration(cldc). http://java.sun.com/products/cldc/. [12] Jsr 82: Java apis for bluetooth. http://www.jcp.org/en/jsr/detail?id=82. [13] ksoap 2. http://kobjects.org/. [14] M. kransyansky, bluez: Official linux bluetooth protocol stack. http://bluez.sourceforge.net/. [15] Mobile information device profile (midp); jsr 37, jsr 118. http://java.sun.com/products/midp/. [16] Soap version 1.2. http://www.w3.org/TR/soap/. [17] Web service axis. http://ws.apache.org/axis/. [18] Windows support for bluetooth. http://msdn.microsoft.com/library/default.asp? url=/library/enus/bluetooth/bluetooth/about bluetooth.asp. [19] Xml-rpc. http://www.xmlrpc.com/. [20] V. Auletta, C. Blundo, E. DeCristofaro, and G. Raimato. A lightweight framework for web services invocation over bluetooth. Proceedings of IEEE International Conference on Web Services, 2006. [21] J. Beutel and O. Kasten. A minimal bluetooth-based computing and communication platform, technical report. Engineering and Networks Lab, Swiss Federal Institute of Technology, 2001. [22] J. Cano, D. Ferrandez-Bell, and P. Manzoni. Evaluating bluetooth performace as the support for context-aware applications. 12th IEEE International Conference on Computer Communications and Networks, pages 333–347, 2003. [23] B. Chatschik. An overview of the bluetooth wireless tecnology. IEEE Communication Magazine, 39:86–94, 2001. [24] F. Kargl, S. Ribhegge, S. Schlott, and M. Weber. Bluetooth-based ad-hoc networks for voice transmission. Proceedings of 36th Annual Hawaii International Conference on System Sciences, 2003. [25] Y. Lim, J. Kim, S. L. Min, and J. S. Ma. Performance evaluation of the bluetooth-based public internet access point. Proceedings of the The 15th International Conference on Information Networking. [26] Misic, K. L. Chan, and V. Misic. Tcp traffic in bluetooth 1.2: performance and dimensioning of flow control. IEEE Wireless Communications and Networking Conference, (3):1798–1804, 2005. [27] S. Zeadally and A. Kumar. Protocol support for audio streaming between bluetooth devices. IEEE Radio and Wireless Conference, pages 303–306, 2004.
Figure 15: Send and receive time for an Address objects array using DH time slotting our framework can still adopt the communication modality that better suits their application scenario.
7. CONCLUSION AND FUTURE WORK In this paper we evaluated the performances of a framework for Web Services invocation over a Bluetooth channel. Experiments showed that the performance of the framework are quite good (i.e. high throughput). Hence, our framework is usable in a real world application. Moreover, its computational workload is small enough to be deployed on mobile devices with limited resources. Table 1 summarizes the differences between the framework developed in [20] and the one presented in this paper. Properties Transparency Lightweight Different error correction modes Different data packet slots Free Environment
[20] Yes Yes No No No
This paper Yes Yes Yes Yes Yes
Table 1: Differences between framework in [20] and the one in this paper In order to evaluate the real impact of different Bluetooth data packets, we plan to run performance’s tests on smartphones not forcing connection to their built-in settings. As future work, we plan to design, develop and test applications using the framework, such as MIDlets [12] targeted to information retrieving (eg. train timetables in a station) or micropayment applications (eg. buying ticket in a cinema or on a bus).
8. REFERENCES [1] Apache commons httpclient. http://jakarta.apache.org/commons/httpclient/. [2] Avetanabluetooth jsr-82 api implementation by avetana gmbh. http://www.avetana-gmbh.de/avetanagmbh/index.xml. [3] Blue cove open-source implementation of the jsr-82 api. http://sourceforge.net/projects/bluecove/. [4] The bluetooth sig standard. http://www.bluetooth.com. [5] Bluetooth solutions by atinav avelink. http://www.avelink.com/bluetooth/index.htm. [6] Bluetooth wireless technology. http://www.ericsson.com/technology/techarticles /Bluetooth.shtml.
8
