ISSN ONLINE(2320-9801) PRINT (2320-9798)

All submissions of the EM system will be redirected to Online Manuscript Submission System. Authors are requested to submit articles directly to Online Manuscript Submission System of respective journal.

DISCOVERING A BLUETOOTH DEVICE USING SDP

Vaishali Yadav1, Ashwani Yadav2
  1. Lecturer, ASET, Amity University, Rajasthan, Jaipur, India
  2. Lecturer, ASET, Amity University, Rajasthan, Jaipur, India
Related article at Pubmed, Scholar Google

Visit for more related articles at International Journal of Innovative Research in Computer and Communication Engineering

Abstract

In the ubiquitous computing services are heterogeneous in nature. To be pervasive, these services should be defined in terms of their functionality and capabilities.The vision of ubiquitous computing refers to the creation of environments saturated with a spectrum of heterogeneous computing and communication capabilities, which seamlessly integrate with the physical world. Such capabilities cover the spectrum ranging from traditional devices (e.g., speakers), wireless mobile devices (e.g., cell phones) to smart devices (e.g., badges, sensors, intelligent appliances). In ubiquitous environments, users are surrounded by different kind of computing devices offering services of different types. As users need to discover and interoperate with such services, service discovery represents a crucial functionality. Service discovery protocols (SDP) are needed to discover and use the services in ubiquitous environments.

Keywords

Ubiquitous computing, Service discovery, Service discovery protocols (SDP)

INTRODUCTION

The term ?Ubiquitous computing‘ was originally introduced by late Mark Weiser. In ubiquitous computing, many computers—possibly small objects based on computer technologies—and their services are available throughout the world. People can use these services to perform tasks in various places without being aware of the underlying computer systems.Unlike in mainframe and desktop computing, computation power in the Ubiquitous Computing (UbiComp) paradigm is almost invisible and everywhere. This computing paradigm protects users from the complexity of technology and provides them with computing devices that can be used intuitively and subconsciously.
UbiComp is the 3rd wave of computing [1] which has two visions: (1) reduce users‘ need to concentrate when interacting with computing devices and (2) provide computing power in an anywhere anytime manner. The underlying goal of UbiComp is to send computers into the background thus enabling users to use them subconsciously in support of their daily activities [2]. This is what Russell et al. refers to as Disappearing Computers [3].
The usage of wireless-enabled handheld devices has seen an exponential growth in the past few years. It has facilitated the development of ubiquitous computing infrastructures for service provisioning. Mobile devices liked to access various services from ubiquitous resources. Moreover, users expect to have context-aware services [4].
In the ubiquitous computing paradigm, information and services are accessible virtually anywhere and at any time via any device – phones, PDAs, laptops or even watches. Ubiquitous environment consists of intelligent services that are accessible to users via handheld devices connected over short range wireless links.
Service Discovery refers to the act of (1) discovering hardware components or software entities (resources, data or computation components) on peer devices; (2) determining how to invoke or utilize the services. And we need protocols to discover and use these services. Some protocols constrain itself to only discovering services though. In this paper we discover a Bluetooth device using a PDA in a ubiquitous environment. Section 2 gives overview of Bluetooth, section 3 discusses our example of discovering a Bluetooth service in ubicomp environment and section 4 concludes the whole paper and gives future work.

BLUETOOTH

A. Protocol Stack
Figure 1 shows the Bluetooth protocols [5] and supporting entities involved.
The service discovery user application (SrvDscApp) in a local device (LocDev) interfaces with the Bluetooth SDP client to send service inquiries and receive service inquiry responses from the SDP servers of remote devices (RemDevs) BT_SDP_spec [5]. SDP uses the connection-oriented (CO) transport service in L2CAP, which in turn uses the baseband asynchronous connectionless (ACL) links to ultimately carry the SDP PDUs (protocol data units) over the air.
B. Configuration
Local device (LocDev):
A LocDev is the device that initiates the service discovery procedure. A LocDev must contain at least the client portion of the Bluetooth SDP architecture BT_SDP_spec [5]. A LocDev contains the service discovery application (SrvDscApp) used by a user to initiate discoveries and display the results of these discoveries.
Remote Device(s) (RemDev(s)):
A RemDev is any device that participates in the service discovery process by responding to the service inquiries generated by a LocDev. A RemDev must contain at least the server portion of the Bluetooth SDP architecture BT_SDP_spec [5]. A RemDev contains a service records database, which the server portion of SDP consults to create responses to service discovery requests.
The Bluetooth protocol stack contains a Service Discovery Protocol (SDP) BT_SDP_spec [5] that is used to locate services that are available on or via devices in the vicinity of a Bluetooth enabled device. Having located what services are available in a device, a user may then select to use one or more of them. Selecting, accessing, and using a service is outside the scope of this document. Yet, even though SDP is not directly involved in accessing services, information retrieved via SDP facilitates service access by using it to properly condition the local Bluetooth stack to access the desired service.
The service discovery profile defines the protocols and procedures that shall be used by a service discovery application on a device to locate services in other Bluetooth-enabled devices using the Bluetooth Service Discovery Protocol (SDP). With regard to this profile, the service discovery application is a specific user-initiated application. In this aspect, this profile is in contrast to other profiles where service discovery interactions between two SDP entities in two Bluetooth-enabled devices result from the need to enable a particular transport service (e.g. RFCOMM, etc.), or a particular usage scenario (e.g. file transfer, cordless telephony, LAN AP, etc.) over these two devices. Service discovery interactions of the latter kind can be found within the appropriate Bluetooth usage scenario profile documents.
SDP provides direct support for the following set of service inquiries:
• Search for services by service class;
• Search for services by service attributes; and
• Service browsing.
The figure 2 shows a local device (the notebook) inquiring for services among remote devices. Other than Bluetooth we also have other approaches which are used for service discovery. These approaches are summarized in the following table [6] and it also does a comparison between bluetooth and other approaches. In the last decade, several discovery protocols have been investigated. They are such as Bluetooth Service Discovery Protocol (SDP) [7], Jini [8], Salutation [9], Service Location Protocol (SLP) [10], UPnP Simple Service Discovery Protocol (SSDP) [11], and Zeroconf [12].

HOW TO DISCOVER SERVICES

Typically we have various frameworks which are used in service discovery process. Here as an example we are discussing personalized service discovery framework [13]. This framework has three main components: services, directories, and personal operating middleware (POM).
Services automatically discover an appropriate directory to which to send their advertisements. Directories index and cache these service advertisements. Directories can propagate queries to adjacent directories if they don‘t have appropriate services for the queries. Second, service advertisements carry services‘ contextual attributes:
• class is the service‘s name and category;
• location is a 2D coordinate representing a user‘s or service‘s physical position;
• popularity is the number of users that include the service in their VPS;
• quality is a discrete value between 0 and 1 that represents the service‘s general quality specified by the service owner;
• service load is the capacity in use divided by the service‘s maximum capacity; and
• required services are the services that the user might need to invoke while the service is operating.
The POM provides two functions to help users discover appropriate services: service recognition and personalization.

EXAMPLES: DISCOVERING BLUETOOTH DEVICES

Before enabling any two Bluetooth-equipped devices to communicate with each other the following may be needed:
• The devices need to be powered-on and initialized.
• A Bluetooth link has to be created, which may require the discovery of the other device's BD_ADDR via an inquiry process, and the paging of the other device.
Inquiry process and paging is beyond the topic of this paper. We will show how a Bluetooth device will discover another Bluetooth and how they will chat with each other.
When a LocDev performs a service discovery search, it does so against three different types of RemDevs:
1. Trusted devices: These are devices that are currently not connected with the LocDev but the LocDev device has already an established trusted relation with.
2. Unknown (new) devices: These are untrusted devices that are currently not connected with the LocDev.
3. Connected devices: These are devices that are already connected to the LocDev.
While it may be seem natural to consider a LocDev serving as a Bluetooth master and the RemDev(s) serving as Bluetooth slave(s), there is no such requirement imposed on the devices participating in this profile. Service discovery as presented in this document can be initiated by either a master or a slave device at any point for which these devices are members of the same Piconet.
A specific SDP is needed in the Bluetooth environment, as the set of services that are available changes dynamically based on the RF proximity of devices in motion, qualitatively different from service discovery in traditional network-based environments. We have implemented this type of discovery in Asp.Net 2008, environment using windows application. In our example a PDA will find a Bluetooth device if any comes in range or the PDA goes in range of that device.
A. Connecting with Internet
We connect our PDA with internet if our PDA is in range of Wi-Fi it will automatically connect with internet as it will find wi-fi protocol.
If no wi-fi is in range, and we are trying to connect with internet, it will show that wi-fi service is not discovered and unable to connect with internet.
Figure 3 shows a screen shot in which we are showing that we have installed service discovery modem for blue tooth so that we can find Bluetooth device which is in range.
B. Communication with other Bluetooth Device
If our PDA‘s Bluetooth discovers [5] any device in range then our device will send him message or will chat with him and if no devices are found in Bluetooth range, and our pda is unable to discover this service for a particular Bluetooth device, and if we try to send him message or try to chat with them, then our pda will show that Bluetooth service for particular pda is not discovered.
Figure 4 shows a screen shot in which we are showing that our pda does not find any device in range and hence service is not discovered. This is because the service discovery modem or Bluetooth hardware is not installed.
Figure 5 shows a screen shot in which we are showing that our pda finds a device in range and hence service is discovered.
Figure 6 shows a message sent to another Bluetooth device which is in range.
Figure 7 shows how our PDA will be connected to many devices at the same time.
Figure 8 shows a message sent to all other Bluetooth devices which are in range.

CONCLUSION

We have shown that how the services in a ubiquitous environment are discovered. And we have implemented service discovery in ubiquitous environment using a PDA which uses Bluetooth to discover another device which is also having a Bluetooth. In the work done we can only discover the services of another device, the further work which can be done in this context is to access the services of another Bluetooth devices.

ACKNOWLEDGMENT

Many thanks are due to My Parents who continuously encourage me to do this work, without their support it was not possible. I am grateful to my colleagues who have given the time to discuss technical terms with me for this paper.
 

Tables at a glance

Table icon
Table 1
 

Figures at a glance

Figure 1 Figure 2 Figure 3 Figure 4
Figure 1 Figure 2 Figure 3 Figure 4
Figure 1 Figure 2 Figure 3 Figure 4
Figure 5 Figure 6 Figure 7 Figure 8
 

References