BWIG: Bluetooth Web Internet Gateway Nicolas Rouhana University Saint-Joseph, Lebanon
[email protected] Abstract Bluetooth is a new wireless standard for low cost, low power, local radio communications. This technology is designed to be small enough to fit inside any electronic device, hence revolutionizing wireless connectivity by enabling many new and innovative services for its users. Several usage models and applications are already being identified for various Bluetooth wireless mobile devices such as headsets, phones, computers, modems, and so forth. In this paper, we propose a new architecture called BWIG (Bluetooth Web Internet Gateway) which defines a Bluetooth usage model that provides seamless ad-hoc Web access for Internet-enabled Bluetooth portable devices such as PDAs, notebook computers and WAP mobile phones. We validate our proposal by developing a prototype implementation of the various functional blocks of BWIG and show how it can be deployed and used in actual devices for Internet access.
Eric Horlait University Pierre et Marie Curie, France
[email protected] between portable devices, such as the use of a wireless headset with a mobile phone, automatic synchronization between a personal data assistant (PDA) a laptop and a mobile phone, wireless modems, and so forth. In this paper, we focus on a particular usage model for Bluetooth that provides Web access (which is typically the most used Internet application today for information retrieval) to Bluetooth devices equipped accordingly with the necessary client software, i.e. browsers in PDAs and notebook computers, or “micro-browsers” in WAPenabled mobile phones. Legacy methods of Internet access for such devices while on the move has been mainly relying on dial-up phone lines, which is a lowbandwidth solution, and can be costly when using longdistance calls, not to mention the hassle to find out the appropriate numbers to call, modem settings, cable interfaces, etc. each time. Bluetooth network Internet
1. Introduction Wireless connectivity has become the buzzword in today’s networks. As a result, intense research activities around wireless networks and mobile networking led to the introduction of several technologies, ranging from wide area cellular systems (e.g. satellite or GSM networks) to wireless local loops and wireless LANs. However, such efforts on wireless technologies still lack a universal framework that offers wireless connectivity to a diverse set of portable devices (e.g., PDAs, mobile phones, laptop computers, etc.) in a seamless, userfriendly and low-cost manner. In 1998, 5 leaders in mobile telephony and computing (Ericsson, IBM, Intel, Nokia and Toshiba) formed the Bluetooth special interest group (SIG) [1] to design a global standard for short-range low-power wireless communications. Bluetooth was originally intended as a “cable replacement” technology permitting both voice and data wireless connectivity to a wide range of mobile devices within a typical vicinity of 10 meters radius. This introduced new and exciting usage models for cooperation
BWIG gateway
Figure 1. BWIG network architecture We propose an architecture called Bluetooth Web Internet Gateway (BWIG) that allows Internet mobile clients to use Bluetooth wireless networks to seamlessly gain access to the Internet (figure 1). With BWIG, users can access the Internet in an environment where no dialup connection is needed anymore, and benefiting from a higher throughput than classical phone lines with a configuration-free setup. Deployment of such a solution can typically be in environments where Internet access is needed on a low-range coverage with a limited number of users, such as conference or meeting rooms, hotel lobbies, home Internet, airport waiting lounges, etc. The remainder of the paper is organized as follows. In the next section, we introduce the Bluetooth protocol stack as well as the Bluetooth SIG LAN access profile and its limitations. In section 3, we explain our new usage model of Internet access by introducing our BWIG
architecture. Section 4 details the implementation and the platform used, and discusses a preliminary performance overview. In section 5, we show how we can extend our BWIG architecture to a WAP environment, and then we conclude in section 6.
2. Bluetooth architecture Figure 2 shows the SDP Bluetooth protocol stack. L2CAP It comprises of four core protocols (Baseband, Audio LMP LMP, L2CAP and SDP) Baseband that are required in Bluetooth Radio Bluetooth devices [2]. The Radio takes care of Figure 2. Bluetooth sending and receiving protocol stack modulated bit streams. The Baseband protocol defines the timing, framing, packets, and flow control on the link. The Link Manager (LMP) assumes the responsibility of managing connection states, enforcing fairness among slaves, power management, and other management tasks. The Logical Link Control (L2CAP) handles multiplexing of higher level protocols, segmentation and reassembly of large packets, and device discovery using the Service Discovery Protocol (SDP). Audio data is mapped directly on to the Base-band while audio control is layered above the logical link control. Bluetooth devices can establish connections in ad-hoc fashion to form a piconet (figure 3). In a piconet, one Bluetooth device acts as a master (nodes 1 in figure 3) and controls all the traffic in the piconet while all the other devices act as slaves. Slaves can only communicate with the master and not with other slaves. In a piconet, Bluetooth allows one master and seven slaves. A scatternet is the linking of multiple co-located piconets through the sharing of common master or slave devices.
Figure 3. Piconet/Scatternet example
Every Bluetooth device has a built-in 48-bit unique IEEE hardware address (BD_ADDR), as well as a 3-bit Active Member Address (AM_ADDR) used to distinguish the active participants on the piconet A number of usage models are identified by the Bluetooth SIG, and indicate what kind of applications Bluetooth is intended for. Each usage model is accompanied by a Profile [3] that defines the protocols and protocol features supporting a particular usage model.
Some of the defined usage models are: file transfer, Internet bridge, LAN access, synchronization, three-inone phone, and ultimate head-set. Our work was motivated by the LAN access profile which is used for TCP/IP networking. The initial focus of the Bluetooth SIG while developing the LAN access profile was on the reuse of existing protocols wherever possible (figure 4). Hence, it defined a simple and natural extension of legacy circuitswitched dial-up networking, and mandated the use of the popular PPP (Point-to-Point Protocol) [4] over emulated serial channel over Bluetooth. For that purpose, the Bluetooth SIG also re-used RFCOMM [5], a transport protocol with additional provisions for emulating RS-232 serial ports, intended as a serial “cable-replacement” protocol between a terminal and a modem for dial-up networking. Application (HTTP, FTP)
Application (HTTP, FTP) TCP
UDP
TCP IP
IP
IP PPP
PPP
RFCOMM
RFCOMM
SDP
SDP L2CAP
L2CAP
LMP
LMP Baseband
Baseband
Bluetooth Radio
Bluetooth Radio
Internet
Server
Bluetooth piconet Access Point Access sever
Figure 4. LAN Access Profile
The original motivations for PPP as IP bearer over Bluetooth was principally because PPP is implemented in most mobile devices already (it’s needed for Dial-up networking anyway), it also enables user-based authentication (LAN access control), carries IPv4, IPv6 and other protocols, and solves (to a reasonable degree) the IP address assignment problem in ad-hoc contexts. PPP on emulated serial channel serves well legacy applications, but is not the most efficient and flexible solution, and the Bluetooth SIG states that it will disappear on the long run; it was chosen as an interim solution because of the lack of available timeframe and the push for a fast solution. In the above proposed model, IP is always used over the Bluetooth radio to help solve ad-hoc connectivity in wireless networks, which leads to several address resolution schemes that have to be defined (such as logical address to physical address translation, broadcast, etc), which consequently add more overhead and processing at the mobile node. Furthermore, configuration issues have also to be considered, since all
IP stacks need to be configured with an address, a netmask, a default gateway, DNS servers, etc. In the next section, we show that for a web browsing application, we can do without the entire IP stack overhead in the Bluetooth network, and define a simple and transparent way to access the Internet.
BWIG gateway
Application (HTTP, FTP)
BWIG client
TCP IP
Application (HTTP, FTP)
BWIG server
SDP
SDP
L2CAP
L2CAP
TCP
TCP
IP
IP
Baseband
Baseband Bluetooth Radio
Bluetooth Radio
3. Bluetooth Web Internet Gateway
Internet Bluetooth piconet Server
In this section, we define a new type of profile targeted at Internet access applications namely Web browsing which, in our opinion, will be the far most commonly needed usage of Bluetooth Internet-enabled mobile devices, such as PDAs and portable computers. The basic idea behind our model is to eliminate the use of the TCP/IP protocols over the Bluetooth radio: the application-level requests (e.g. GET URL in HTTP [6]) are sent directly over the Bluetooth stack (specifically over L2CAP) and over the radio interface to the BT gateway, which in turn will use the TCP/IP stack to contact the origin server (figure 5). The return path follows the reverse scheme. Internet
BT Gateway
Client Get URL (over L2CAP)
Response/Content (over L2CAP)
Origin server Get URL (over TCP)
Response/Content (over TCP)
Figure 5. BWIG operation model
One could closely relate this client/BT-gateway communication to the classical client/proxy/server model which breaks an HTTP connection into two parts: a clientto-proxy connection and a proxy-to-server connection, where the proxy server acts as an intermediate between the two end-systems communicating entities, sending ASCII-based commands in the upwards direction to the servers and bulk file-transfer in the downwards direction to the clients. In order to achieve this, our model uses two BWIG “proxies”: a “BWIG client” and a “BWIG server”. The “BWIG client” (figure 6) is an application-level proxy that acts at the client side, and intercepts the original requests sent by the user over the local TCP/IP stack, and redirects them directly over the local Bluetooth stack to the BT gateway. At the BT gateway, the “BWIG server” receives the client request from the Bluetooth stack, and uses the TCP/IP stack to establish a connection with the content server requested in the incoming URL from the client (such as GET http://www.usj.edu.lb).
slave #2 master
slave #1
Figure 6. BWIG architecture model
The results of our BWIG communication scheme have the following characteristics over the Bluetooth network: • Less protocol overhead and layer processing than the Bluetooth SIG LAN access profile, eliminating PPP and RFCOMM usage. This means there is much less overhead to clog up the limited bandwidth than the defined Bluetooth SIG LAN Access profile. Furthermore, our model cuts down on overhead at the TCP level by doing away with the three-way handshake and the two-half close that TCP uses to establish and terminate connections respectively [8]. • No need for IP addresses for the Bluetooth devices, and all associated schemes for peer-to-peer IP communications (e.g. address resolution, broadcast, etc). The BWIG model uses the link-layer IEEE Bluetooth device addresses for the point-to-point communications between the clients and the gateway. In addition, since the hosts do not have IP addresses during the communication, they should be safe against direct attacks coming from the Internet while connected. • No need for layer-4 port numbering found in TCP or UDP; the CID (Channel ID) at the L2CAP layer is used to distinguish different client connections at the gateway. L2CAP is based around the concept of ’channels’. Channel identifiers (CIDs) are local names representing a logical channel end-point on the device • Minimum LAN infrastructure is needed, e.g., no DHCP servers or authentication servers required. Nevertheless, the gateway can also provide authentication control for the mobile Bluetooth hosts. • No configuration changes are required at the mobile hosts, i.e. no change in their original office or home IP stack configuration settings. The client new proxy settings can be set automatically by the “BWIG proxy client”. • No more TCP over wireless link: while the TCP protocol has performed admirably for the wired Internet, there are some constraints of today’s wireless networks that proved too problematic for TCP [9], such
as the congestion management back-off scheme of TCP [10] that is a limitation on wireless networks. • Caching can be implemented at the gateway much like any caching or proxy server, and will allow the BT gateway to deliver frequently requested content from its own cache rather than returning to the origin server. DNS can also be implemented in the gateway to save processing requirements on the device end as well as radio bandwidth. The next section explains the implementation of our BWIG model used for Web browsing.
In addition to the set-up steps made for the Server application above, the client application also performs the following further steps before it can be started: • Call the HCI_ReqInquiry function to discover other nearby Bluetooth radios. • Call the HCI_ReqRemoteName function that reads the name of any other nearby Bluetooth radio. • Call the SCM_ReqConnect function in order to set up a data connection with another Bluetooth device, and establish the communication between the two devices. Application
4. BWIG application suite
BT Stack COM_ReqStart SD_ReqStart
We used as a development platform Bluetooth Modules from Ericsson (Radio Board ROK 101 008 provided by Telca Comtec [7]) compliant with Bluetooth specification version 1.1, with a USB and/or UART interface connection to a host computer. A generic Bluetooth host stack is available in a Win32 environment, and it gives the application programmer an access to the APIs provided by the RFCOMM, SDP, L2CAP, SCM (Stack Connection Manager that handles and administrates the Bluetooth baseband connection and the radio links) and the HCI interface (that handles the communication by the transport layer through the UART/USB interface with the host). In the Bluetooth concept, applications are written in a client/server approach; the clients in our case are the Bluetooth slaves in the piconet wanting to access the Internet, and the server is the gateway (master). The BWIG application suite consists of two parts: • “BWIG server”, which runs at the BT Gateway side (i.e. the master). • “BWIG client” with a ‘Bluetooth neighborhood’ module, which runs at the client side (i.e. the slave). We list below the sequence of API function that has to be called in a Bluetooth environment for a client to connect to a server. For simplicity, we used in our implementation the RFCOMM API interface that supports up to 60 simultaneous connections and hides a lot of treatment than the direct L2CAP encapsulation. The first thing to do in the server application is to start the RFCOMM and Service Discovery layers by calling COM_ReqStart and SD_ReqStart, respectively (figure 7). The RFCOMM layer is needed for the communication and the SD layer is needed in order for other Bluetooth devices to find this server. In order to be able to respond to events, the application needs to register with the SCM component using SCM_ReqRegister. This is to ensure that the application will be notified about created or destroyed links. At this point the stack is ready for the Server application, which will accept a connection from a Client application upon request.
SCM_ReqRegister
INIT (server & client)
HCI_ReqInquiry HCI_ReqRemoteName SCM_ReqConnect SD_ReqConnect SD_ReqServiceSearch SD_ReqServiceAttribute SD_ReqDisconnect
Discovery + Data Connect (client)
BTAPI_ConnectRfcomm COM_ReqConnect COM_DataAlloc COM_DataSend
Figure 7. Bluetooth API function calls
Now that the connection is made, the client needs to find out what services the other device offers. The application uses the Service Discovery layer for this purpose: • The SD_ReqConnect function starts an SDP instance for obtaining SDP Server Database values from a specific Bluetooth device. • The SD_ReqServiceSearch function is used to locate service records for a specific Bluetooth device. • The SD_ReqServiceAttributes function is called to retrieve the name of the other Bluetooth device. • The SD_ReqDisconnect function is called to disconnect from the Service Discovery protocol. Then, the BTAPI_ConnectRfcomm routine creates an RFCOMM connection to a Bluetooth device given its IEEE-address with the first available server identified. This routine starts this RFCOMM connection set-up session (a sequence of requests to the stack), where all following received messages will be handled in this BTAPI module until this session sends the last request to the stack (COM_ReqConnect). Data are sent using COM_DataAlloc and COM_DataSend primitives.
The “BWIG server” application runs at the Bluetooth Gateway, and registers the Internet Proxy gateway to the Bluetooth stack in order to be discovered by Bluetooth devices. The “BWIG server” window (figure 8) shows the registered service and the status of the connection with the client(s): IDLE or Connected.
After this selection, a session is setup with the selected service by pressing the ‘Connect’ button. Now the “Web Client” application will pop up (figure 10), with, if everything goes well, the ‘Connected’ button shadowed. The “Web client” window shows the connected device and service name, and gives the user the status of the connection. At the server side, the “BWIG server” window changes from IDLE to Connected when a client sets up an RFCOMM connection to it (figure 11).
Figure 8. BWIG Server interface at the Gateway
When the “BWIG client” application is started, the “Bluetooth Neighborhood” module (figure 9) allows the user to choose which interface will be used to connect to the Bluetooth unit (USB or UART).
Figure 11. BWIG Server interface
The user then launches his browser and types the URLs to access. While data transfer is occurring, the “BWIG Web Client” window interface shows simple statistics of the HTTP connection (figure 12).
Figure 9. Bluetooth neighborhood
Figure 12. BWIG client statistics
When either ‘Serial port’ or ‘USB port’ has been chosen the ‘Inquiry’ (or Get Services) button gets visible and the application is usable. Before the interface is selected the Bluetooth Neighborhood window title bar shows “NOT CONNECTED”. After an interface is selected and the stack has successfully connected to the Bluetooth Device the title bar should read “CONNECTED TO DEVICE:” and the Bluetooth address for the device. The window is divided into 2 main parts, where functionality for device discovery and service discovery are found. The upper part is able to discover all Bluetooth devices in the neighborhood via the ‘Inquiry’ button, where address and name are displayed. From this list a device can be selected. In the lower part, a client can request for a list of services in the selected device which results in an SDP session, retrieving all services from the remote device in a list and then choosing a service by selecting one from the list.
As for performance issues, the data transfer rate calculated is highly dependant of the host machine and the Bluetooth modules. For example, we used DM5 packets to transfer data between the Bluetooth modules, and the data transfer rate calculated reached approximately 45 kbps when both computers use the USB interface to the modules. If UART is used by one or both computers the file data transfer rate is approximately 30 kbps. Another performance factor resides in the event-driven environment. The application is designed as a Windows program, which means that for each message popping up from the Bluetooth Stack, an event-handler is programmed. Furthermore, in Visual Studio, the program can be compiled and linked in two ways: either in release mode or in debug mode. When we calculated the throughput we had compiled the program in release mode; in debug mode, performance is poorer. For reference, we used as hosts HP Vectra VL PCs, with Pentium II 400MHz processors, 64MB RAM and Win98 OS.
5. BWIG extensions for WAP
Figure 10. BWIG client interface
Our BWIG architecture can be extended to also embed Wireless Application Protocol (WAP) [11] functionality to provide Internet access to WAP-enabled Bluetooth
devices. The Bluetooth SIG defined a reference model for protocol support of WAP shown in figure 13. It is largely inspired from the dialW AP up LAN access profile described Environm ent earlier. For the same reasons explained earlier, Bluetooth’s ad hoc UD P IP nature provides capabilities that can be exploited by the WAP protocols, P PP without the need for dial-up RFC O M M networking. Bluetooth can be used like other wireless networks with L2CAP regard to WAP. It provides a bearer Figure 13. WAP access profile
for transporting data between the WAP Client and its adjacent WAP Gateway. The BWIG Gateway defined in the previous sections can also be embedded with a WAP Gateway functionality. The resulting architecture is shown in figure 14. The bearer used in that case is directly Bluetooth and not the UDP service interface. WAP Application Environment
WAP / HTTP gateway
SDP
SDP
L2CAP
HTTP
TCP
TCP
IP
IP
L2CAP
higher cost and high-power consuming radios than the Bluetooth solution; this is why we are yet to see 802.11 radios in low-cost devices such as mobile phones. Furthermore, one of the key features in favor of Bluetooth is its embedded service discovery very useful in ad-hoc networks. Also, Bluetooth physical channels allow the co-existence of two different kinds of links within a piconet, circuit-switched for voice and packet-switched for data for a total bit rate of 1Mbps. However, as per the Bluetooth specifications, it is possible to achieve an aggregate throughput of 10Mbps with a fully expanded scatternet. We validated our proposal by implementing a working prototype of our architecture, and the positive results encourage us to consider it as a serious contender for proposing a new Bluetooth profile for ad-hoc Web access to Internet mobile devices. Unfortunately, by the time of this writing, the ROK modules we used did not support point-to-multipoint communications to be able to test our application using multiple slaves. Currently, we are working on the platform to implement the defined Bluetooth SIG LAN access profile in order to compare its performance in terms of overhead and throughput to our proposed architecture.
7. References
Baseband
Baseband Bluetooth Radio
Bluetooth Radio
Internet Content server
Bluetooth piconet
WAP / BT -enabled phone
BWIG/WAP gateway
Figure 14. WAP/BT Gateway architecture
6. Conclusions and future works In this paper, we used the Bluetooth technology to show our vision of an architecture that seamlessly allows ad-hoc Internet access to mobile devices. We considered the Bluetooth technology instead of other wireless alternatives in our proposal because we believe that Bluetooth is becoming a universal framework for wireless connectivity in every mobile device. The two other contending technologies are IrDA and IEEE 802.11. The Infrared Data Association (IrDA) [12] protocol stack supports usage models similar to those of Bluetooth, yet there has not been significant developed applications using infrared, due perhaps to the most disadvantage of IR over RF which is the line-of-sight restriction that would constrain and jeopardize networking applications which typically rely on “unconscious” low-range computing such as our own. The IEEE 802.11 [13] standard enables LAN based applications with large radio coverage, leading to
[1] Bluetooth Special Interest Group, http://www.bluetooth.org/ [2] Bluetooth Special Interest Group, “Bluetooth Core”, Specification of the Bluetooth System, Version 1.1, February 22, 2001 [3] Bluetooth Special Interest Group, “Bluetooth Profile”, Specification of the Bluetooth System, Version 1.1, February 22, 2001 [4] W. Simpson, “The Point-to-Point Protocol (PPP)”, IETF Request for Comments 1661, July 1994 [5] ETSI, “Terminal Equipment to Mobile Station (TEMS) multiplexer protocol” (GSM 07.10 version 6.1.0), July 1998. TS 101 369. [6] R. Fielding, et al., “Hypertext Transfer Protocol -HTTP/1.1.”, IETF Request for Comments 2616, June 1999. [7] Comtec Telca, http://www.comtec.sigma.se/ [8] J. Postel. “Transmission Control Protocol”, IETF Request for Comments 793, Sep 1981. [9] A.C. Augé, J.P. Aspas, “TCP/IP over Wireless Links: Performance Evaluation”, 48th Vehicular Technology Conference, May 1998. [10] M. Allman, et al., “TCP Congestion Control”, IETF Request for Comments 2581, April 1999 [11] The WAP Forum, http://www.wapforum.org/ [12] Infrared Data Association, http://www.irda.org/ [13] IEEE Working Group for Wireless LAN, http://www.ieee802.org/11/
