Mobile Communication Wireless Systems Bluetooth Chatting

Published Date: 02 Nov 2017

S96008776

Harish Chand

S11031065

Mandeep Singh

S01007546

Prasheel Singh

CS427: MOBILE COMMUNICATION – Semester II–2009

WIRELESS SYSTEMS: BLUETOOTH CHATTING

Students: Harish Chand – 9259835, Suva, Fiji Islands. <[email protected]>

Mandeep Singh – 9307422, Suva, Fiji Islands. <[email protected] >

Prasheel Singh – 9995736, Suva, Fiji Islands <[email protected]>

Lecturer: Imtiyaz Hussein CS/IS Division.

The University of the South Pacific, Laucala Bay Campus, Suva, Fiji Islands.

Abstract

This paper provides an overview of Bluetooth Chatting and how Bluetooth technology is being utilized in order to successfully establish Bluetooth connections using mobile phones and demonstrate the usage of instant messaging. Bluetooth Chatting is an instant messaging technique that uses a Bluetooth enabled Midlet and Bluetooth technology and its protocols to provide a universal chatting environment between connected devices without fixed network infrastructures in a Wireless Personal Area Network.

Introduction

One of the key characteristics of today’s society is that many people are mobile. Thus, the mobile communication started to play a vital role in our society. Wireless communication is one of the fastest growing technologies. The demand for connecting devices without the use of cables is increasing everywhere. Bluetooth is a very common example of wireless systems technology for small wireless PAN.

In this project, we have carried out research on how the Bluetooth wireless system came into existence; how the Bluetooth technology functions; advantages and drawbacks of Bluetooth technology and how Bluetooth technology has contributed towards Bluetooth Chatting.

Bluetooth uses a radio technology called frequency-hopping spread spectrum, which chops up the data being sent and transmits chunks of it on up to 79 frequencies. In its basic mode, the modulation is Gaussian frequency-shift keying (GFSK) which can achieve a gross data rate of 1 Mb/s. Bluetooth provides a way to connect and exchange information between devices such as mobile phones, telephones, laptops, personal computers, printers, Global Positioning System (GPS) receivers, digital cameras, and video game consoles through a secure, globally unlicensed Industrial, Scientific and Medical (ISM) 2.4 GHz short-range radio frequency bandwidth.

Advantages of Bluetooth is that anyone who doesn't have any knowledge about the new technology can still uses the Bluetooth feature due to its simplicity and the ease of use. It is also free of charge, wireless and can be kept in control by allowing and not allowing access to other users. However it also has some disadvantages which are, more power used when Bluetooth is in activated mode, internet connections with Bluetooth can sometimes be very slow.

Bluetooth chat is a direct text chat between two or more users, where every one of them utilizes a Bluetooth device. This way of communicating is generally used in a public and populated space like a pub, a street, a plaza and so on. It’s better than the simple but effective short message services (SMS) that has been used to mobile chat over the years and is free. One of the main disadvantage is that complete strangers can communicate with others using Bluetooth devices. Overall, Bluetooth is a great thing to be using on all your devices that supports it.

Background

The art of connecting things is becoming more and more complex every day. In this project we will look at Bluetooth chatting using a method of connecting devices, called Bluetooth that can streamline the process. A Bluetooth connection is wireless and automatic, and it has a number of interesting features that can simplify our daily lives. The group has placed a great interest and emphasis on the project because it leads to a free and effective instant messaging. To do this the group has employed a program that can be used for Bluetooth chatting to and from multiple Bluetooth phones and devices simultaneously. These devices avoid interfering with other systems by sending out very weak signals of about 1mW.

For this project we have used Bluetooth Core Specification Version 2.0 + EDR mobile phones. Since the software used is a Freeware (Chat2U), therefore there are no risks to this project as well as the software is compatible with many latest mobile phones, however, the only constraint is that all devices need to have Bluetooth functionality.

The benefits we have attained from this research is that we gain in-depth knowledge in regards to the Bluetooth technology, and understand the importance of Bluetooth technology in our society. Functionalities, advantages and drawbacks of Bluetooth technology are learnt. We also exhibit that Bluetooth Chatting can provide us with a means to communicate with our peers in limited area without any connection fees.

Bluetooth Chatting Overview

Bluetooth Technology – Foundation of Bluetooth Chatting

Introduction

Bluetooth is an always-on, wireless PAN technology that resides on a microchip, designed to connect devices of different functions such as mobile phones, PDAs, notebooks, computers (desktop and laptops), cameras, and printers and so on. One major reason Bluetooth is dominating is wireless PAN is because the cost of a Bluetooth chip is under $3.

History

Bluetooth was first initially developed in 1994 by Jaap Haartsen and Sven Mattisson in Sweden. In 1998, Bluetooth Special Interest Group officially formalized the Bluetooth specification. In 2002, IEEE approved the 802.15.1 specification to conform to Bluetooth wireless technology. Today, it has membership of over 11,000 companies worldwide. Initially it was established by Ericsson, IBM, Intel, Toshiba, and Nokia, and later joined by other companies.

How Bluetooth Operates

Bluetooth technology operates in the unlicensed 2.4 GHz spectrum having coverage of 10 meters or 100 meters depending on the Bluetooth device class. The peak rate with EDR (Enhanced Data Rate) is 3Mbps. Bluetooth technology is Omni-directional and does not require line-of-sight positioning to connection devices and is also able to go through solid objects.

Bluetooth Security

Security has always been and continues to be a priority in the development of the Bluetooth specification. Developers who use Bluetooth technologies in there products have several options for implementing security. The Bluetooth specification allows for three modes of security for access between two Bluetooth devices: non-secure, service level enforced security and link level enforced security. Furthermore, devices and services security is also taken into consideration when developing Bluetooth. Devices security has two levels, that is, trusted devices and untrusted devices and services security have three levels: services that require authorization and authentication, services that require authentication only and services that are open to all devices.

Bluetooth Versions

Bluetooth technology has released a number of Bluetooth Specification Versions: Bluetooth 1.0 Specification (1999), Bluetooth Core Specification Version 1.2 (2003), Bluetooth Core Specification Version 2.0 + EDR (Enhanced Data Rate) (2004), and Bluetooth Core Specification Version 3.0 + HS (High Speed) (2009).

Bluetooth Protocol Stack

Basically, the Bluetooth Chatting utilizes the Bluetooth Protocol.

The figure given above shows the Bluetooth protocol architecture. Bluetooth technology is designed for and optimised for use in mobile devices, Mobile Computer, Cellular handsets, network access points, Printers, PDA’s, desktops, keyboards, joysticks, and virtually any other device can have short range Bluetooth radios operating in the free 2.4 GHz Industrial Scientific Medical (ISM) band using 79 channels between 2402 GHz to 2480 GHz which is integrated into a single a single Bluetooth chip. It uses Frequency Hopping Spread Spectrum (FHSS), which divides the frequency band into a number of hop channels. Bluetooth radios use tiny RF transmitters, no larger than 1.0 × 0.5 inches, that can run off a watch battery for months.

The range for Bluetooth communication is from 0 to 10 metres with a power consumption of 0dBm (1mW). The distance can be increased to 100m by amplifying the power to 20 dBm. Note that the Bluetooth supports 2 kinds of links which are asynchronous connection links for data transmission and synchronous connection links for audio and voice transmission. The gross Bluetooth data rate is 1Mbps while the maximum effective rate on an asymmetric ACL link is 721 Kbps in either direction or 57.5Kbps in the return direction. Symmetric ACL link allows data rates of 4326Kbps. Bluetooth also supports up to three 64Kbps SCO channels per device and are guaranteed bandwidth for transmission. Since Bluetooth operates in unlicensed band that is also used by other devices such as 802.11 networks, baby monitors, garage door openers, microwave ovens, etc with some interference which is avoided using Frequency Hop Spread Spectrum (FHSS). A Bluetooth channel is divided into time slots each 625 μs in length. The devices hop through these timeslots making 1600 hops per second. Bluetooth communication occurs between a master radio and a slave radio which is symmetric and may operate as a master or a slave. Two or more radio devices together from ad-hoc networks called piconets where the same channel is used by all the units. Each piconet has one master device and one or more slaves and can be up to seven active slaves at a time within a piconet. Each active device within a piconet is identified by a 3 bit active device address. The inactive slaves are in disconnected modes which continue to reside within the piconet. A master is the one that initiates the Bluetooth communication link and once it is established, a slave may request a master/ slave switch to become the master. Note that the slaves are not allowed to talk to each other directly and the slaves within a piconet must also synchronise with their internal clocks and frequency hops with that of the master. Each piconet uses a different frequency hopping spectrum using time division multiplexing. A master device in a piconet transmits an even numbered time slots and the slaves may transmit on odd numbered time slots. Multiple piconets overlapping the coverage areas form a scatternet. Each piconet may have only one master but slaves may participate in different piconets on a time division multiplexing basis.

The Bluetooth protocol stack is divided into 4 layers according to their purpose in the following manner:

Bluetooth Core protocol

Cable replacement protocol

Telephony control protocol

Adapted protocol

Bluetooth Core Protocols

Baseband and link control layer enables the physical RF link between units forming a piconet where FHSS system is used in which packets are transmitted into defined time and frequency slots. Inquiry and paging procedures are used in this layer to synchronise the transmission hopping frequency and clock of different Bluetooth devices. Further it provides two different types of physical links with there corresponding baseband:

Synchronous connection oriented (SCO) link for audio and data.

A synchronous connection oriented link for data only.

These are transmitted in multiplexing manner on the same RF link. The SCO is a symmetric point to point link between a master and a single slave in a piconet. The master maintains the SCO link by using reserved slots at regular intervals. The SCO link mainly carries voice information. The master can support up to 3 simultaneous SCO links while the slaves can support two or three SCO links. SCO packets are never transmitted and are used for 64kBps speech transmission. The ACL link is a point to multipoint link between the master and all the slaves participating on the piconet.

Bluetooth has five logical channels which can transfer different types of information. These channels are Link Control (LC) channel, Link Manager (LM) channels are used in link levels while User Asynchronous (UA) data channel, User Isosynchronous (UI) data channel and User Synchronous (US) data channel are used to carry asynchronous, isosynchronous and synchronous user information. Four possible types of addresses are assigned to Bluetooth units. These addresses are Bluetooth Device Address (BD_ADDR) where each Bluetooth transceiver is allocated a 48 bit device address. It is divided into a 24 bit Local Area Network Access Point (LAP) field, a 16 bit Non-significant Address Portion (NAP) field, and an 8 bit User Address Portion (UAP) field. Secondly the Active Member Address (AM_ADDR) is a 3 bit number is only valid as long as the slave is active on the channel. Thirdly the Parked Member Address (PM_ADDR) is an 8 bit member address that separates the parked slaves and is only valid as long as the slave is parked. Finally the Access Request Address (AR_ADDR) is used by the parked slave- to- master half slot in the access window it is only allowed to send the access request messages in and is valid as long as the slave is parked and is not necessarily unique.

All the data on a piconet channel is conveyed in packets that are of 13 different types defined for the baseband layer of the blue tooth system. The packets are ID packet used in 68 bit packet used in paging, inquiry and response routines, and NULL packet is a 126 bit packet consisting of Channel Access Code and packet header only and is used to return link information to the source, POLL is similar to NULL packet except it requires confirmation from the destination and upon reception of a POLL packet the slave must respond with the packet, Frequency Hopping Synchronisation (FHS) is a special control packet revealing among BD_ADDR and the clock of the source device, Data - Medium Rate (DM1) packets containing a 16 bit CRC code up to 18 information bytes. These packets are defined for SCO and ACL links. Further packets are Data – High Rate (DH1) which can carry up to 28 information bytes and covers a single time slot, AUX1 can carry up to 30 information bytes, DM3, DH3, DM5, DH5 are defined for ACL links only. HV1,HV2,HV3 carries information bytes, DV – data voice divided into voice field of 80 bits and a data field of 150 bits which are defined for SCO links only. The packet format is of 3 types, Access Code, Header and Payload. Access Code is used for timing synchronisation, offset compensation and paging inquiry. There are 3 different types of Access codes which are Channel Access Code – identifies a unique piconet, Device Access Code is used for paging and its responses and Inquiry Access Code is used for inquiry purpose. The second type is the Header which contains information for packet acknowledgement, packet numbering for out of order packet reordering, flow control, slave address and error check for header. Thirdly, the Payload which contains either voice field, data field or both.

Bluetooth Controller operates in 2 major states, Standby and Connection. The other seven substates which are used to add slaves or make connections to the piconet are Page, Page Scan, Inquiry, Inquiry Scan, Master Response, Slave Response and Inquiry Response. Connections between two devices are followed by inquiry and paging procedures. The inquiry procedure enables the device to discover which devices are in range and determine the addresses and clocks for the devices. With the paging procedure the actual connection is established that typically follows the inquiry procedure. Only the Bluetooth device address is required to set up a connection. A unit that establishes a connection will carry out a page procedure and will automatically be the master of the connection.

The paging procedure follows 6 steps as follows:

A device pages another device.

The destination receives the page.

Destination sends the reply to the source.

Source sends an FHS packet to the destination.

Destination sends its second reply to the source.

Destination and source then switch to source channel parameters.

The Connection state starts with POLL packet sent by the master to verify that slave has switched to the master’s timing and channel frequency hopping. A Bluetooth device in the connection mode can be in any of the following modes:

Active Mode: Bluetooth unit actively participates on the channel. The master schedules the channel based on the traffic demands to and from different slaves and supports regular transmissions to keep slaves synchronised to the channel. Active slaves listen in the master - to - slave slots for packets and if an active slave is not addressed, it mat sleep until next new master transmission.

Sniff Mode: Devices synchronised to a piconet can enter power saving modes in which device activity is lowered. In this mode a slave device listens to the piconet at a reduced rate, thus reducing it’s duty cycle. The sniff interval is programmable and depends on the application and ha the highest duty cycle of all the three power saving modes.

Hold Mode: Devices synchronised to a piconet can enter power saving modes in which device activity is lowered. The master units can put the slave units into hold mode, where only an internal timer is running. The data transfer starts at instant when units transitions are out of hold mode. Note that this mode has immediate duty cycle of the three power saving modes.

Park Mode: the device is still synchronised to the piconet in this mode but does not participate in the traffic. The Park device gives up the MAC address and occasionally listens to the traffic of the master to re – synchronise and check on broadcast messages. This mode has the lowest duty cycle of all the three power saving modes.

Link Manager Protocol (LMP) is responsible for link setup between Bluetooth devices which includes security aspects like authentication and encryption by generating, exchanging and checking of link and encryption keys and the control and negotiation of the baseband packet sizes. It also controls power modes, duty cycles of the Bluetooth radio device and the connection states of a Bluetooth unit in a piconet. This protocol consists of a number of protocol data units (PDU) which are sent from one device to another which are determined by the access mode address in the packet header. Link Manager Protocol Data Units (LM PDU) are always sent as single slot packets and the payload header is therefore one byte. The DM1 packets are used to transport LMPDU’s except if an SCO link is present using HV1 packets and the length of content is less than nine bytes.

Logical Link Control and Adaptation protocol (L2CAP) adapts upper layer protocols over the baseband and provides connection oriented and connectionless data services to the upper layer protocols with protocol multiplexing capability, segmentation and reassembly operation and group abstractions. L2CAP transmits and receives data packets up to 64KB in length and is only defined for ACL links. L2CAP is based on concept of channels and the endpoints of L2CAP channel is referred to by the channel identifier (CID). CID is the local name representing a logical channel endpoint on a device. The assignment of CID is relative to a particular device and a device can assign CIDs independently from other devices. L2CAP operates in one of the three different modes as selected for each L2CAP channel by an upper layer. These modes are:

Basic L2CAP mode.

Flow Control Mode.

Retransmission mode

L2CAP is based on packet mode and follows a communication model based on channels. A channel represents a data flow between L2CAP entities in remote devices and the channels may be connection - oriented or connectionless. All the signalling commands are sent to the signalling channel with CID 0×0001. This signalling channel is available as soon as an ACL logical transport is setup and L2CAP traffic is enabled on L2CAP logical link. Multiple commands may be sent in a single signalling command. Commands take the form of request and responses. All L2CAP implementations supports the reception of C-frames with a payload length that does not exceed the signalling MTU. The minimum supported payload length for the C-frame (MTU signal) is 48 Octets. L2CAP should not use C-frames that exceed the MTU signal of the peer device.

Services Discovery Protocol (SDP) provides the means for applications to discover which services are available and to determine the characteristics of those available services. SDP is a very simple protocol with minimum requirements on the underlying transport. It can function over a reliable packet transport and uses a request / response model where each transaction consists of one request protocol data units (PDU) and one response PDU. But the request may potentially be in line and responses may potentially be returned out of order. In the request / response model each transaction consists of one request PDU and one response PDU and for each case SDP is used with the Bluetooth L2CAP transport protocol. Only one SDP request PDU per connection to given SDP server may be outstanding at a given instant. Limiting SDP to sending at least one unacknowledged request PDU provides a simple form of flow control as shown in figure 1 below.

Server Application

Client application

SDP Server

SDP Client

Figure 1: SDP flow control diagram.

Every SDP PDU consists of a PDU header followed by PDU – specific parameters. Three fields are contained by this header. PDU ID –field identifies the specific parameter, Transaction ID- field uniquely identifies request PDUs and is used to match response PDUs to request PDUs, Parameter Length- field specifies the length of all parameters contained in the PDU. Further the SDP services define how the individual characteristics of different devices are stored. Further the SDP services given as follows describe how the individual characteristics of different devices are stored.

Service Record: Any entity that provides information, perform an action or control resource on be half of entity. Services may be implemented as a form of software or hardware or both. All the information about the service is maintained by an SDP server which is contained within a single service record.

Service Attribute: describes single characteristics of a service and consists of 2 components, an attribute ID and an attribute value. An Attribute ID is a 16 bit unsigned integer that distinguishes each service attribute within a service record and also identifies the schematics of the associated attribute value. In addition an Attribute Value is a variable length field whose classification is determined by the attribute ID associated with it and by the service class of the service record in which the attribute is contained.

Service Discovery: allows the Bluetooth devices to discover what other services Bluetooth devices can offer. The means allowed by SDP are Searching- looks for specific service, and Browsing – sees what services are actually being offered.

Cable Replacement Protocol

RFCOMM: is a simple transport that provides emulation of RS232 serial ports over L2CAP protocol and based on ETSI standard TS 07.10. This protocol supports up to 60 simultaneous connections between two Bluetooth devices. A complete communication path involves two applications running on different devices with a communication segment between them. The figure 2 below shows a complete communication path.

Application Device B

Application Device A

Communication segment

Figure 2

RFCOMM is only concerned with the connection with the connection between the devices in the direct connect case or between the device and a modem in a network case. It also accommodates two device types. Types 1 device are communication endpoints such as computers and printers and type 2 devices are those that are part of communication segment. RFCOMM has a 60s timer which is started when a command is sent. If an acknowledgement isn’t received when the timer elapses, the connection will be shut down. This is different from GSM 07.10, which resends the command when the timer elapses. In the case of RFCOMM, the Bluetooth Baseband provides a reliable link, so if the command wasn’t acknowledged first time, it is not likely to be acknowledged a second time. For the SABM command, the timeout can be extended because security procedures might mean that this command takes longer to process than others. If RFCOMM ever times out and disconnects, it must send a DISC (disconnect) command frame on the same DLCI as the original SABM frame just in case the other side has come back into range and thinks the connection is still active.

Telephony Control Protocol

Telephony Control Binary (TCS BIN) it defines the call control signalling for the establishment of speech and data calls between Bluetooth devices and also defines mobility management procedures for handling groups of Bluetooth TCS devices. This protocol is based on ITU – T recommendation. Telephony Control protocol Specifications contains the functions as follows:

Call control - signalling for the establishment and release of speech and data calls between Bluetooth devices.

Group management – signalling to ease the handling of groups of Bluetooth devices.

Connectionless TCS (CL) – provisions to exchange signalling information not related to an ongoing call. [BT Specification ; 449]

TCS uses point – to - point signalling and may also use point – to - multipoint signalling. Point – to - point signalling is used when it is known to which side a call to be established but the point – to – multipoint needs may be used when there are more sides available for call establishment. Point-to-point signalling is mapped towards a connection-oriented L2CAP channel, whereas point-to-multipoint signalling is mapped towards the connectionless L2CAP channel, which in turn is sent as broadcast information on the beacon channel.

Telephony Control – AT Commands by which a mobile phone and modem can be controlled in multiple usage modems is defined by the Bluetooth SIG.

Adopted Protocols

PPP runs over RFCOMM and accomplishes point-to-point connections. PPP is used to carry packets from the higher IP layer across the RFCOMM serial port emulation layer. It provides a Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. It is simplified by assuming that we will only use the Internet Protocol Control Protocol (IPCP) to encapsulate network layer protocol information over point-to-point links.

TCP/UDP/IP standards in Bluetooth devices allow for communication with any other device connected to the internet. TCP is responsible for providing reliable transmission control mechanism over IP protocol. In order to do so, TCP incorporates such mechanisms as sequencing, windowing and reassembly of packets. UDP offers unreliable, unsequenced, connectionless protocol that sacrifices reliability for speed. It relies on higher layer protocols to provide sequencing and reliability and as such, provides a much and lower level transport protocol than TCP can. For this reason, UDP is used for the actual payload for VoIP calls. If a voice packet for some reason is dropped or lost, UDP disregards the lost packet, simply because delivering a lost voice packet out of synchronous will hinder rather than aid a call.

OBEX Protocol has been chosen to specifically to allow Ad-hoc connections to enable data transfer from one device to another. Tasks such as synchronisation and file transfer can take place between one or more device where such objects may include vCalender, vCard, and vMessage and so on. The OBEX component has been designed with portability in mind and any existing infra-red application may reside above OBEX and use Bluetooth as its underlying transport. There are no fixed master slave roles which allow either free to initiate and terminate a connection.

Wireless Application Protocol (WAP) reuses the software application developed for web application environment and the servers allow for both content push and pull between Bluetooth devices, bring to life concepts like kiosks. Protocols operate over a different bearer services, including short message, circuit switched data and packet data. The bearers offer different quality of service with respect to throughput, error rate and delays. The WAP protocols are designed to compensate for or tolerate these varying levels of service. WAP server can be preconfigured with the Bluetooth device address of a WAP Server in range, or a WAP client can find it by conducting an inquiry and then use service discovery to find a WAP server [Hac; 87, 152]. The WAP client needs to use SDP to find the RFCOMM server number allocated to the WAP services. The WAP servers service discovery record identifies whether the service is proxy used to access files on other devices, an origin server, which provides its own files, or both. The WAP layers use UDP, IP and PPP which allows datagram to be sent across the RFCOMM serial port emulation layer.

Bluetooth Chatting

Introduction

One of the fastest growing applications of Bluetooth technology is Bluetooth Chatting. Chatting via Bluetooth provides a universal chatting environment between connected devices without fixed network infrastructures. Sitting in café or restaurant, having fun at disco or sitting in a boring class/lecture, users can pick up friends for chatting using any Bluetooth device such as Bluetooth compatible mobile phones, pocket PCs, etc. It does not have any cost per message or connection fees. In this section, we will getting a overview of the Bluetooth Chatting application and highlighting the important design and implementation elements of Bluetooth Chatting applications.

Bluetooth chatting makes your communication within Bluetooth range both natural and unbound. Chat2U is a Bluetooth Chatting Midlet used in this project to Chat for free without wired connection within a 10 meter area using Bluetooth v2.0 featuring cell phones. This application has functionality to search users within Bluetooth range, connect to the users in Bluetooth contact list and simply just Chat.

The main disadvantage of Bluetooth chatting is that complete strangers can communicate with others using Bluetooth devices ones they are able to connect to your device.

Background

A Bluetooth Chatting Midlet is a Bluetooth Instant Messaging application designed for Bluetooth enabled devices such as cell phones that enables users to search for online users in Bluetooth range and Chat with them. It is basically aimed at youth market to make chatting more convenient, personalized and eliminate the cost factor of exchanging messages. Developing Bluetooth application is a hideous and challenging task for lots of developers.

In this project, developing a Bluetooth Chatting application was not possible due to the time constraints faced by the members of this group since we all have different working hours and the time allocated for this course is just 16 weeks. However, in order to complete this project, we decided to use a freeware Bluetooth Chatting Midlet (Chat2U) for demonstration purposes and broaden our knowledge with the important design and implementation elements of a Bluetooth Midlet. To compile and execute a Bluetooth application it is essential to acquire the J2ME Wireless Toolkit and some Simulator application and get them installed.

Features

Essentially, any Bluetooth Chatting application has the characteristics to search the remote user within Bluetooth range with that same application, add list of remote users in the contact list and connect to any user(s) for Chat. The user can set the Chat Nickname before starting the Chat. The Chat Nickname will be during the chatting session.

The main features of Bluetooth chatting are:

Sending and receiving instant messages;

Separate dialogues for every user;

Contact list management functions, including facilities to add new contact, to change nick names of contacts and to put contact into ignore list;

Contact list status update options – manually, after going online and many more.

Midlet Installation

Chat2U application is suitable for various make and model of cell phones. This application is delivered as a compressed software package file (called Chat2U.jar) of 52KB. The installation package may be transferred to your phone from a computer, downloaded during WAP browsing, or sent to you in a multimedia message, as an email attachment, via Bluetooth or via infrared.

Once the file is transferred to your phone, you can then install the application by using the device Installer automatically. The software will not be installed if there is not enough memory or if components required by the software are missing without which the installation cannot proceed (such as cell phones that does not support Java Midlets).

How to Chat

After successful installation, the users can Chat with remote users for free within the 10 meter area. The user needs to choose a Chat Nickname before starting the Chat and is used during the chat session.

Once the Chat Nickname is chosen, Chat2U application uses the following procedure in order to exchange instant messaging:

Search for the User to Chat with you via Bluetooth.

A list of Users available within the range is displayed.

User can then select any user from the list to start the Chat.

Instant messages are sent and received until a user leaves the Chat Room (exits application) or moves out of Bluetooth range.

Bluetooth Chat Application Design

The Bluetooth module manufacturers provide the necessary SDK to interface with their modules, however, fragmentation of these SDKs and APIs are one of the complexities of Bluetooth development. Vendor-specific SDKs force the developers to adopt proprietary APIs for their respective Bluetooth chip sets. The Bluetooth Chatting Midlet are built on top of these APIs, hence, are not portable across devices and platforms. The Bluetooth specification of the technology, that is, how proper Bluetooth devices behave and how they interoperate with each other, the Bluetooth specification does not describe how Bluetooth devices can be programmed or how the applications exercise a Bluetooth device’s functions and utilizes communication channels. Hence, the need for a standardized API arises in order to develop Bluetooth application in a platform independent manner.

The first standardized API specification (JSR-82), the Java API for Bluetooth Wireless Technology (JABWT), was introduced by the Java Community Process in 2000. This specification, establishes a common ground for rapid Bluetooth application development enabling the developers to write Bluetooth applications independent of hardware vendors. On the contrary, the Bluetooth specification is designed to cover a diverse range of devices and usage scenarios, therefore, to complement this diversity the scope of the JABWT to include the only the most commonly used profiles and functions, mainly, Generic Access Profile, Service Discovery Profile, Serial Port Profile, Generic Object Exchange Profile, and their respective protocols supported.

These profiles allow JABWT applications to perform the following functionalities:

Generic Access Profile: provides the basic building blocks of a Bluetooth application, such as local device, remote device, Bluetooth address, and device discovery.

Service Discovery Profile: Provides the ability to find available services to access remote functionalities.

Serial Port Profile: Provides a stream-based connectivity between Bluetooth applications.

Generic Object Exchange Profile: Provides support for OBEX protocol, which allows applications to exchange simple objects.

The two entities Bluetooth Configuration Centre (BCC) and Service Discovery Database (SDDB) are abstracted from the Java API to simplify the programming model. BCC includes the capabilities that globally configure the Bluetooth stack and prevent one application from adversely affecting another. Although BCC is transparent to Java applications, it is important to realize that BCC has the ultimate authority over the Bluetooth host and may affect the behaviour of your Bluetooth applications. SDDB is an abstract database of service records, that is, a collection of attributes that describes an individual’s services. Java applications interact with SDDB indirectly via the update and retrieval of service records.

JABWT is integrated with the J2ME Generic Connection Framework hence providing a familiar API to J2ME developers for accessing Bluetooth facilities; as a result, Bluetooth network programming seems similar to a stream-based connection model. Bluetooth connection model employs client/server architecture. Bluetooth Chatting application behaves as a client when it starts up, searches and connects to existing running same chatting application devices. Once connected, it makes itself to other devices to connect to. In such cases it serves as a server for future clients connects.

The figure given above represents the network relationship between three Bluetooth Chatting mobile phones. To logically represent an active node, we use the concept of endpoint to encapsulate all connectivity attributes of a node. Each mobile represents a unique message delivery destination and source regardless of whether it is a server or a client.

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 disguise to the Bluetooth API. 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 mobile phones. A call back interface is in place to report any network activity back to the GUI.

The figure given below shows the relationship between different layers and components of a Bluetooth Chatting Midlet.

Moreover, the communication channel between each connected Chatting mobile phone is a structured data stream connection. A simple establishing protocol is designed to coordinate the activity between each mobile phone. This protocol includes the following features:

Initial handshake: Each phone must handshake with each other when the connection is first established. This ensures that the connecting device is running the same Midlet. During the handshake, we also exchange the screen Nicknames of the users.

The figure below illustrates the initial handshaking protocol.

Delivery of text message: Each sent text message is delivered to all clients connected to the Chatting network.

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

The following figure illustrates the termination handshake.

Implementation Consideration

The NetLayer class, which implements the Bluetooth Chatting application 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 device connectivity for found Chat services.

Manages the life cycle of all devices.

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 Midlet 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 Chatting device 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 using the code in Listing 1.

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 the Chat application is ready to accept a connection. If there is an existing chat room available, chatting device should join the existing network by searching for same 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 function 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.

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, devices want to be found. 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 that devices want to be discovered for a short period of time, as requested by any 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. 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 and 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 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. From the application-level perspective, an endpoint encapsulates information for each actively connected Chat user and device.

Chat Midlet 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 device to manage the traffic between two devices. From this point on, two devices 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 device is no longer active. All receiving parties must return an acknowledgment (SIGNAL_TERMINATE_ACK) and remove the leaving device from the active device list. A device 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. 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.

Future Works

After the completion of this research the following recommendations can be taken into consideration:

The coverage of Bluetooth technology could be increased using Bluetooth amplifiers.

Increase in data transfer rate by further making changes to Bluetooth Specification v3.0 + HS.

In terms of Midlets for Bluetooth Chatting, features such as file transfer while chatting and video chatting via 3G cell phones could be incorporated into a single Midlet will definitely eliminate the cost of sending MMS messages and video calls.

Conclusion

To conclude, Bluetooth enabled mobile phones which operate in the unrestricted 2.4 GHz ISM band frequency automatically synchronizes contact information of other Bluetooth mobile phones allowing Bluetooth Chatting to eventually send instant messages in a WPAN without any mobility restriction and communication fees.