Java and Bluetooth Technologies

CHAPTER – I

INTRODUCTION

1.1 Project Background

Wireless technologies are becoming more and more popular around the world. Consumers appreciate the wireless lifestyle, relieving them of the well known “cable chaos” that tends to grow under their desk. Nowadays, the world would virtually stop if wireless communications suddenly became unavailable. Both our way of life and the global economy are highly dependent on the flow of information through wireless mediums like television and radio. Cell phones have become highly available during the last decade. Now virtually everyone owns a cell phone, making people available almost wherever they are. Many companies are highly dependent on their employees having cell phones, some companies have even decided not to employ stationary phone systems but instead use cell phones exclusively throughout the organization. New wireless technologies are introduced at an increasing rate. During the last few years the IEEE 802.11 technologies have started to spread rapidly, enabling consumers to set up their own wireless networks. This constitutes an important change in how wireless communications are made available to consumers. Wireless networks are no longer provided by big corporations alone, they can just as well be implemented by individuals. Our society is becoming more and more dependent on wireless communications as new areas of use are introduced.

The Bluetooth wireless technology is also spreading rapidly. The number of Bluetooth chipsets shipped per year has doubled from 2002 to a total of 69 million chipsets in 2003. The majority of these Bluetooth chipsets are used in mobile phones. An interesting aspect is that consumers are highly dependent on having a cell phone, and the Bluetooth technology is included in the majority of new cell phones. The Bluetooth technology will therefore spread because of the general need for cell phones. As an increasing number of useful Bluetooth applications become available, many consumers will already have Bluetooth devices and be ready to start using Bluetooth PANs (Personal Area Networks) where all their Bluetooth devices communicate with one another.

The number of Java enabled mobile phones worldwide is over 250 million and the number of Java enabled mobile phones will continue to increase. Java enabled mobile phones have already been on the market for some years. Due to the very resource constrained mobile phones available a few years ago, Java applications were not very sophisticated and did not hit the mass-market the way many had hoped. As seen in the rest of the software and hardware industry, games play an important role in driving the development of both hardware and software forward. It is therefore interesting to see that a large market has emerged lately for Java games targeting mobile devices. Processing power, available memory, screen size, and screen resolution are increasing as new Java enabled mobile devices enter the market. Newly released Java applications are accordingly sophisticated, and will help to spread the Java technology usage even further.

The Java APIs for Bluetooth Wireless Technology (JABWT) ties the Java technology and the Bluetooth technology together. JABWT is made available in some of the latest smart phones and will probably be available also in low-end cell phones in the future. One can easily imagine different scenarios where JABWT would be useful, e.g. the functionality of existing Java games is extended to support multi-player games using Bluetooth connectivity. Other interesting scenarios emerge as well, such as a consumer using a Java Bluetooth enabled mobile phone to pay for a soda by connecting to a Bluetooth enabled soda vending-machine. A good prediction is that JABWT will first find its use in multi-player Java games, making the Java and Bluetooth technologies well-known to consumers. Thereafter we will probably see other types of Java Bluetooth applications, such as small-amount payment applications.

This thesis gives a broad overview of Java and Bluetooth technologies, and a mobile peer-to-peer application that allows users to share their files such as text, images music within a small Bluetooth network in a synchronized way.

1.2 Aim of the Project

This project is designed to develop a personalized mobile file sharing system that allow users to share their resources without the aid of any central server.

1.3 Motivation of the Project

With the availability of peer-to-peer mobile services operating on content sets, the need for a personalized file sharing Application rises. This project overcomes the requirements specified above by designing a personalized file sharing system that not only allows people to share files to the strangers in a mobile peer-to-peer mobile network, but also identifies the secure mobile devices in an “ad-hoc mobile social network” which allows people to share and personalize the file sharing experience with the strangers in the network.

1.4 Expected outcome of the project

The Outcome of this project is to design a system that provides methods to share their files within the users in an adhoc network by identifying the secure mobile devices. The user not only shares there files with known entities but also has provisions to share the image, text and music files with unknown entities.

1.5. Introduction to Bluetooth

Bluetooth is a wireless communication protocol. Bluetooth is an always-on, short-range radio hookup that resides on a microchip. We can use Bluetooth to communicate to other Bluetooth-enabled devices. It was initially developed by Swedish mobile phone maker Ericsson in 1994 as a way to let laptop computers make calls over a mobile phone. Since then, several thousand companies have signed on to make Bluetooth the low-power short-range wireless standard for a wide range of devices. Industry observers expect Bluetooth to be installed in billions of devices by 2005.

The concept behind Bluetooth is to provide a universal short-range wireless capability. Using the 2.4 GHz band, available globally for unlicensed low-power uses, two Bluetooth devices within 10 m of each other can share up to 720 Kbps of capacity. Bluetooth is intended to support an open-ended list of applications, including data (such as schedules and telephone numbers), audio, graphics, and even video. For example, audio devices can include headsets, cordless and standard phones, home stereos, and digital MP3 players. Following are some examples of the capabilities that Bluetooth can provide consumers:

• Make calls from a wireless headset connected remotely to a cell phone;

• Eliminate cables linking computers to printers, keyboards, and the mouse;

• Hook up MP3 players wirelessly to other machines to download music;

• Set up home networks so that a couch potato can remotely monitor air conditioning, the oven, and children’s Internet surfing;

• Call home from a remote location to turn appliances on and off, set the alarm, and monitor activity.

1.5.1 Applications of Bluetooth

Bluetooth is designed to operate in an environment of many users. Up to eight devices can communicate in a small network called a piconet. Ten of these piconets can coexist in the same coverage range of the Bluetooth radio. To provide security, each link is encoded and protected against eavesdropping and interference.

Bluetooth provides support for three general application areas using short-range wireless connectivity:

• Data and voice access points – Bluetooth facilitates real-time voice and data transmissions by providing effortless wireless connection of portable and stationary communications devices;

• Cable replacement – Bluetooth eliminates the need for numerous, often proprietary cable attachments for connection of practically any kind of communications device. Connections are instant and are maintained even when devices are not within line of sight. The range of each radio is approximately 10 m, but can be extended to 100 m with an optional amplifier;

• Ad hoc networking – A device equipped with a Bluetooth radio can establish instant connection to another Bluetooth radio as soon as it comes into range.

1.5.2 Protocol Architecture

Bluetooth is defined as a layered protocol architecture consisting of core protocols, cable replacement and telephony control protocols, and adopted protocols.

The core protocols form a five-layer stack consisting of the following elements:

• Radio – Specifies details of the air interface, including frequency, the use of frequency hopping, modulation scheme, and transmit power.

• Baseband – Concerned with connection establishment within a piconet, addressing, packet format, timing, and power control.

• Link manager protocol (LMP) – Responsible for link setup between Bluetooth devices and ongoing link management. This includes security aspects such as authentication and encryption, plus the control and negotiation of baseband packet sizes.

• Logical link control and adaptation protocol (L2CAP) – Adapts upper-layer protocols to the baseband layer. L2CAP provides both connectionless and connection-oriented services.

• Service discovery protocol (SDP) – Device information, services, and the characteristics of the services can be queried to enable the establishment of a connection between two or more Bluetooth devices.

RFCOMM is the cable replacement protocol included in the Bluetooth specification. RFCOMM presents a virtual serial port that is designed to make replacement of cable technologies as transparent as possible. Serial ports are one of the most common types of communications interfaces used with computing and communications devices. Hence, RFCOMM enables the replacement of serial port cables with the minimum of modification of existing devices. RFCOMM provides for binary data transport and emulates EIA-232 control signals over the Bluetooth base band layer. EIA-232 (formerly known as RS-232) is a widely used serial port interface standard.

The adopted protocols are defined in specifications issued by other standards-making organizations and incorporated into the overall Bluetooth architecture. The Bluetooth strategy is to invent only necessary protocols and use existing standards whenever possible. These are the adopted protocols:

• PPP – The point-to-point protocol is an Internet standard protocol for transporting IP datagrams over a point-to-point link;

• TCP/UDP/IP – These are the foundation protocols of the TCP/IP protocol suite;

• OBEX – The object exchange protocol is a session-level protocol developed by the Infrared Data Association (IrDA) for the exchange of objects. OBEX provides functionality similar to that of HTTP, but in a simpler fashion. It also provides a model for representing objects and operations. Examples of content formats transferred by OBEX are vCard and vCalendar, which provide the format of an electronic business card and personal calendar entries and scheduling information, respectively;

• WAE/WAP – Bluetooth incorporates the wireless application environment and the wireless application protocol into its architecture.

1.5.3 Bluetooth Usage Models

A number of usage models are defined in Bluetooth profile documents. In essence, a usage model is a set of protocols that implement a particular Bluetooth-based application. Each profile defines the protocols and protocol features supporting a particular usage model. Following are the highest-priority usage models:

• File transfer – The file transfer usage model supports the transfer of directories, files, documents, images, and streaming media formats. This usage model also includes the capability to browse folders on a remote device;

• Internet bridge – With this usage model, a PC is wirelessly connected to a mobile phone or cordless modem to provide dial-up networking and fax capabilities. For dial-up networking, AT commands are used to control the mobile phone or modem, and another protocol stack (such as PPP over RFCOMM) is used for data transfer. For fax transfer, the fax software operates directly over RFCOMM;

• LAN access – This usage model enables devices on a piconet to access a LAN. Once connected, a device functions as if it were directly connected (wired) to the LAN;

• Synchronization – This model provides a device-to-device synchronization of PIM (personal information management) information, such as phone book, calendar, message, and note information. IrMC (Ir mobile communications) is an IrDA protocol that provides client/server capability for transferring updated PIM information from one device to another;

• Three-in-one phone – Telephone handsets that implement this usage model may act as a cordless phone connecting to a voice base station, as an intercom device for connecting to other telephones, and as a cellular phone;

• Headset – The headset can act as a remote device’s audio input and output interface.

1.5.4 Advantages

Bluetooth has a lot to offer with an increasingly difficult market place. Bluetooth helps to bring with it the promise of freedom from the cables and simplicity in networking that has yet to be matched by LAN (Local Area Network).

In the key marketplace, of wireless and handheld devices, the closest competitor to Bluetooth is infrared. Infrared holds many key features, although the line of sight it provides doesn’t go through walls or through obstacles like that of the Bluetooth technology.

Unlike infrared, Bluetooth isn’t a line of sight and it provides ranges of up to 100 meters. Bluetooth is also low power and low processing with an overhead protocol. What this means, is that it’s ideal for integration into small battery powered devices. To put it short, the applications with Bluetooth are virtually endless.

Disadvantages

Bluetooth has several positive features and one would be extremely hard pressed to find downsides when given the current competition. The only real downsides are the data rate and security. Infrared can have data rates of up to 4 MBps, which provides very fast rates for data transfer, while Bluetooth only offers 1 MBps.

For this very reason, infrared has yet to be dispensed with completely and is considered by many to be the complimentary technology to that of Bluetooth. Infrared has inherent security due to its line of sight.

The greater range and radio frequency (RF) of Bluetooth makAe it much more open to interception and attack. For this reason, security is a very key aspect to the Bluetooth specification. Although there are very few disadvantages, Bluetooth still remains the best for short range wireless technology. Those who have tried it love it, and they know for a fact that Bluetooth will be around for years to come.

1.5.5 Chat

In a Bluetooth Chat application, we’ll develop a JABWT-based chat room application, called Chat, for mobile devices that must support the J2ME MIDP 1.0 profile. Users who have a JABWT-capable device can use this application to chat with their nearby friends in an IRC fashion. It searches and joins any existing chat room within the Bluetooth effective range, or creates a new chat room in the nearby Bluetooth range. We use the words chat room to represent a virtual chat room that’s formed by a network of Chat applications. Users can start messaging with each other within the same virtual chat room when there’s more than one party connected to each other. If one user sends a message over the air, all parties of the chat room will receive the message. Users can join and leave the chat room at anytime. For our convenience we assumes like

• There’s only one chat room that exists within effective Bluetooth range.

• There is no security imposed when joining a chat room.

• Users run one instance of Chat on a device at any given time.

Before we dig into the source code, let’s look at some of the Bluetooth application design issues. JABWT does a good job of providing a familiar API to J2ME developers for accessing Bluetooth facilities. JABWT is integrated with the J2ME Generic Connection Framework. As a result, Bluetooth network programming is very similar to a stream-based connection model.

Like many other network protocols, the Bluetooth connection model employs a client/server architecture. Our Chat application, on the other hand, operates in a peer-to-peer manner. Each running instance of Chat (or a node) can serve as a client and a server at the same time. It behaves as a client when Chat starts up; it searches and connects to existing running Chat devices. Once connected, it makes itself available for future clients to connect to. In such cases, it serves as a server for future client connections. To logically represent an active Chat node, we use the concept of endpoint to encapsulate all the connectivity attributes of a node. An endpoint represents a unique message delivery destination and source regardless of whether it is a server or a client.

A Bluetooth connection differs from a regular socket connection by its unique device and service discovery processes. Bluetooth applications typically start the device discovery process to identify connectable devices, which is followed by a service discovery process to obtain a reference (URL) to suitable services. To hide these complexities from the Graphical User Interface (GUI) elements, a network layer is introduced to serve as a façade to the Bluetooth API. This design is comparable to the Model-Viewer-Controller model where the Viewer component is decoupled from the Model component. The GUI can access Bluetooth connectivity via a simplified interface, which does all the discovery and connection establishment behind the scenes. This network layer also provides the functionality to send messages to and receive messages from other endpoints. A call back interface is in place to report any network activity back to the GUI. The Bluetooth Network is explain below.

The communication channel between each connected Chat endpoint is a structured data stream connection. We put together a simple protocol to coordinate the activity between each endpoint. This protocol includes the following features:

• Initial handshake: Each point must handshake with each other when the connection is first established. This ensures that the connecting device is a Chat node rather than a mistakenly connected application. During the handshake, we also exchange the screen names of the users

• Delivery of text message: Each sent text message is delivered to all endpoints connected to the Chat network.

• Termination handshake: If the user quits the chat room gracefully, a termination token is sent to all the other endpoints to indicate its intention. We can clean up the necessary network and runtime resources associated with the leaving endpoint upon receiving this token. However, if the user walks away from effective range and becomes inaccessible, a termination token is not sent. Other active endpoints will discover the leaving party is inaccessible when the connections are lost, and they will clean up the resources.

1.5.5.1 Implementation Consideration

The NetLayer class, which implements the Chat networking layer, does most of the Bluetooth-related work and provides the following functionality:

• Initializes the Bluetooth stack

• Registers Chat services to the Bluetooth device

• Searches for nearby devices

• Searches for Chat services on nearby devices

• Establishes endpoint connectivity for found Chat services

• Manages the life cycle of all endpoints

The Bluetooth stack can be initialized by calling LocalDevice. getLocalDevice(). LocalDevice is a singleton that uniquely represents the underlying Bluetooth device implementation. You can use the LocalDevice instance to gain access to other Bluetooth features including:

• Discovery agent (via getDiscoveryAgent())

• Bluetooth physical network address (via getBluetoothAddress())

• SDDB (via getRecord() and updateRecord())

The Chat NetLayer’s initial work is to create and register a Chat service to a local device. A Bluetooth service is an entry point for other Bluetooth clients to access available functionalities. Since each Chat endpoint can serve as a server, it must register its service in order to make this server available to other Chat clients. JABWT utilizes the MIDP Generic Connection Framework to instantiate a server connection. A Chat application needs to instantiate a Serial Port Profile connection, basically a stream-based connection that allows two Chat applications to exchange data using Java input and output streams. A Chat server connection is created.

After a server connection is created, the service is not yet available to external clients (it is not discoverable). What has happened is that JABWT created a corresponding ServiceRecord for this service. A ServiceRecord is a collection of attributes that describes our service, and these attributes are searchable by clients. We can use localDevice.getRecord( server ) to retrieve the newly created ServiceRecord. You may notice that the ServiceRecord is not empty at this point; it is already populated with some default values that are assigned by the JABWT implementation based on the connection string and the implementation configuration when we perform Connector.open().

The server.acceptAndOpen() method notifies the Bluetooth implementation that the application is ready to accept incoming connections and make the service available. This also instructs the underlying implementation to store the ServiceRecord object in the SDDB, which occurs when server.acceptAndOpen() is first invoked. Notice that only the attributes stored in the SDDB can be seen and queried by other Bluetooth clients. Any subsequent change to the ServiceRecord must be reflected in the SDDB by using localDevice.updateRecord().

Now our Chat application is ready to accept a connection. But what if your friends are already chatting prior to the start of your Chat? If there is an existing chat room available, Chat should join the existing network by searching for other Chat services on each individual device and connecting to their services. Three steps must be taken to perform this action.

• Search for an available device.

• For each available device, search for available and matching services.

• For each available and matching service, connect to the service and perform the initial handshake.

DiscoveryAgent, another singleton in JABWT, can help us find other devices and services. There are two other options for retrieving connectable devices, a cached devices list and a pre known devices list. Cached devices are remote devices that have been discovered in a previous inquiry. Pre known are remote devices that are preconfigured in BCC. In our example, we choose to ignore both cached and pre known devices. We want to retrieve the most up-to-date list of active Chat devices at the moment Chat is launched. Therefore, our Chat application always initiates a new search for all surrounding devices.

Devices can be searchable in two modes, General Inquiry Access Code (GIAC) and Limited Inquiry Access Code (LIAC). When a device is set to GIAC, it basically means “I want to be discovered all the time.” Devices that provide public and permanent services fall into this category. Printers and fax machines are examples of GIAC devices. On the other hand, LIAC discovery mode means “I want to be discovered for a short period of time, as requested by my user.” Devices that provide on-demand connectivity will fall into this category. Examples are multiple player game consoles, mobile modems, and our Chat program.

The device discovery and service discovery processes are performed in an asynchronous manner. A Bluetooth application must provide a callback object for the JABWT implementation to notify when devices or services are found. This callback object implements the DiscoveryListener interface. When a device is found, the deviceDiscovered() method is invoked. We do some basic filtering to narrow down the candidate devices for our Chat application and ignore other unrelated devices.

When all candidate devices are discovered, the device search is completed and the searchCompleted() method is invoked. We initiate the service discovery process using DiscoveryAgent .searchServices(). This is where the ServiceRecord attributes become useful. ServiceRecord is not only a description of the services, but also a query of constraints during service discovery. The second parameter of searchServices() allows us to specify which attributes and values the services must have in order for us to discover them. We can provide the UUID for the service that we registered earlier and it narrows down the exact matching candidate services on a remote device. This mechanism not only improves the performance of the discovery process, but also reduces the possibility of conflict. Once the desired service (Chat service) is found, we can retrieve the corresponding connection URL and establish the physical connection.

To further validate that the connected service is indeed a Chat service, we immediately perform a handshake with the other party by sending a handshake signal (SIGNAL_HANDSHAKE) and exchanging the user screen name. Receiving parties must respond with an acknowledgment (SIGNAL_HANDSHAKE_ACK) to confirm the request..

To logically represent all the parties in the chat room, we introduce class EndPoint. From the application-level perspective, an endpoint encapsulates information for each actively connected Chat user and device. Chat uses EndPoint to identify which user to send a message to, and from which user a message is received. This abstraction allows us to hide the JABWT complexity from the GUI application. Endpoints are created when a connection is established between two Chat devices. Once created, we attach a reading thread and sending thread to the endpoint to manage the traffic between two endpoints. From this point on, two endpoints exchange user-entered messages (using SIGNAL_MESSAGE) until a termination signal is received. Implementation of this protocol can be found in the Reader and Sender classes.

When a user exits Chat, the application sends the last message – a termination token (SIGNAL_TERMINATE) – to all connected parties. This token signals that the endpoint is no longer active. All receiving parties must return an acknowledgment (SIGNAL_TERMINATE_ACK) and remove the leaving endpoint from the active endpoint list. An endpoint can also be removed when the connectivity is dropped, which suggests the user has left the chat room without an explicit exit command (possibly due to a user’s walking away from the Bluetooth effective range).

Our GUI, based on the MIDP LCDUI API, provides a simple interface to send and receive messages. All received messages from all connected users are displayed sequentially on the screen, which creates a virtual chat room environment. When there are more messages to display than can fit onto one screen, older messages will roll off the upper edge. In this example application, users are not able to scroll back to see the past messages. Pressing the “Write” command takes users to a message-editing mode. Pressing the “Send” command sends the currently entered message to the chat room; all other connected users are able to see the message. To quit the chat room, pressing the “Exit” command sends a termination token to all other parties.

1.5 Literature Survey

There are a number of related research projects related to the music sharing. Their similarities and differences from our project are described as follows.

tunA [TUNA, 2004], researched by Media Lab Europe is probably the closest relative of our system. It explored the possibilities of a system which enables people to share their music and to communicate with others nearby while they are on the go. tunA focuses on synchronized music sharing while our system focuses on personalized music sharing.

Soundpryer [SOUNDPRYER, 2002], made by the Mobility Studio of the Interactive Institute in Sweden which focuses on a shared music experience between nearby cars and focuses on personal mobile music uses in urban settings. Unlike our system, Soundpryer does not include tight synchronization of that shared audio as part of their concept and implementation, and users do not choose which cars they are connected to.

Sotto Voce [SottoVoice, 2002], a Xerox PARC project, is an electronic guidebook which attempts to promote a shared activity between museum visitors by allowing them to ‘eavesdrop’ on the descriptive audio passages that another is listening to. The system is a ‘hack’ in that no content is streamed – all devices have identical local content.

Bubbles [Bubbles, 2003], a Telenor R&D project, is a mobile audio player that allows users to exchange audio files with nearby peers. It functions much like a mobile file trading application: Users swap files over HTTP but there is no infrastructure to join the audio experience among those users.

Push!music [PUSH, 2005], a software developed on PDAs, which focuses on the concept of ‘media ecology’, using agents to make songs migrate from one device to another in accordance to users’ music consumption habits.

The methodology in “A peer to peer network file sharing system in mobile phones” is going to focus on mobile file sharing system. The mobile file sharing system allows users to share their resources like images, text, audio files without any aid of the central server. This system not only allows people to share their files to stranger but also identified the mobile devices in the mobile social network.

CHAPTER – II

OVERVIEW OF THE SYSTEM

2.1 System Preliminary Design

The Wireless Service subsystem will let mobile phones communicate with each other when they are in range. Since the devices use Bluetooth protocol which is a radio communications system, so they do not have to be in line of sight of each other, and can even be in other rooms, as long as the received transmission is powerful enough. There are three types of power class dependent with different ranges: 1 metre, 10 metres, 100 metres. The model that the Wireless Service subsystem uses for communication is a Client-Host architecture illustrated in figure. The role of a Host can communicate with up to 7 devices playing the role of a Client using Wireless Service Subsystem. The

Host refers to Tune-in Host subsystem and Client refers to Tune-in Client subsystem.

This network with a group of up to 8 devices (1 Host + 7 Clients) is called a piconet. A piconet is an ad-hoc computer network of devices using Bluetooth technology protocols to allow one host device to interconnect with up to seven active client devices (because a three-bit MAC address is used). Up to 255 further Client devices can be deactivated, or parked, which the Host device can bring into active status at any time. At any given time, data can be transferred between the Host and one Client, but the Host switches rapidly from Client to Client in a round-robin fashion.

To set up a connection, a Client can would perform an inquiry to find any available device