INTERNET OF THINGS (IOT)

The Internet of Things (IoT) is the interconnection of uniquely identifiable embedded computing
devices within the existing Internet infrastructure. Typically, IoT is expected to offer advanced
connectivity of devices, systems, and services that goes beyond machine-to-machine
communications (M2M) and covers a variety of protocols, domains, and applications.[ The
interconnection of these embedded devices (including smart objects), is expected to usher in
automation in nearly all fields, while also enabling advanced applications like a Smart Grid.

Things, in the IoT, can refer to a wide variety of devices such as heart monitoring
implants, biochip transponders on farm animals, electric clams in coastal waters, automobiles with
built-in sensors, or field operation devices that assist fire-fighters in search and rescue. Current
market examples include thermostat systems and washer/dryers that utilize wifi for remote
monitoring.

According to Gartner, Inc. (a technology research and advisory corporation), there will be nearly 26
billion devices on the Internet of Things by 2020. ABI Researchestimates that more than 30 billion
devices will be wirelessly connected to the Internet of Things (Internet of Everything) by 2020. As
per a recent survey and study done by Pew Research Internet Project, a large majority of the
technology experts and engaged Internet users who responded—83 percent—agreed with the notion
that the Internet/Cloud of Things, embedded and wearable computing (and the corresponding
dynamic systems ) will have widespread and beneficial effects by 2025. It is, as such, clear that the
IoT will consist of a very large number of devices being connected to the Internet.

Integration with the Internet implies that devices will utilize an IP address as a unique identifier.
However, due to the limited address space of IPv4 (which allows for 4.3 billion unique addresses),
objects in the IoT will have to use IPv6 to accommodate the extremely large address space
required. Objects in the IoT will not only be devices with sensory capabilities, but also provide
actuation capabilities (e.g., bulbs or locks controlled over the Internet). To a large extent, the future
of the Internet of Things will not be possible without the support of IPv6; and consequently the
global adoption of IPv6 in the coming years will be critical for the successful development of the
IoT in the future.

The embedded computing nature of many IoT devices means that low-cost computing platforms are
likely to be used. In fact, to minimize the impact of such devices on the environment and energy
consumption, low-power radios are likely to be used for connection to the Internet. Such low-power
radios do not use WiFi, or well established Cellular Network technologies, and remain an actively
developing research area. However, the IoT will not be composed only of embedded devices, since
higher order computing devices will be needed to perform heavier duty tasks (routing, switching,
data processing, etc.). Companies such as FreeWave Technologies have developed and
manufactured low power wireless data radios (both embedded and standalone) for over 20 years to
enable Machine-to-Machine applications for the industrial internet of things.

Besides the plethora of new application areas for Internet connected automation to expand into, IoT
is also expected to generate large amounts of data from diverse locations that is aggregated and very
high-velocity, thereby increasing the need to better index, store and process such data.

Diverse applications call for different deployment scenarios and requirement, which have usually
been handled in a proprietary implementation. However, since the IoT is connected to the Internet,
most of the devices comprising IoT services will need to operate utilizing standardized
technologies. Prominent standardization bodies, such as the IETF, IPSO Alliance and ETSI, are
working on developing protocols, systems, architectures and frameworks to enable the IoT.

INTRODUCTION
FUNCTIONING OF INTERNET OF THINGS (IOT)
1. INTRODUCTION
The Internet of Things is the expansion of the current Internet services so as to
accommodate each and every object which exists in this world or likely to exist in the coming
future. This article discusses the perspectives, challenges and opportunities behind a future Internet
that fully supports the “things”, as well as how the things can help in the design of a more
synergistic future Internet. Things having identities and virtual personalities operating in smart
spaces using intelligent interfaces to connect and communicate within social, environmental, and
user contexts. There are several fuzziness about the concept of Internet of Things such as IoT can be
broken in two parts Internet and Things.

The worldwide network of interconnected computer networks based on a standard communication

protocol, the Internet suite (TCP/IP) while a things is an object not precisely identifiable.

The world around us is full of objects, smart objects and the existing service provider known as
Internet. The convergence of the sensors like smart objects, RFID based sensor networks and
Internet gives rise to the Internet of Things. With increased usage of sensors the raw data as well as
distributed data is increasing. Smart devices are now connected to Internet using their
communication protocol and continuously collecting and processing the data. Ubiquitous
computing which was thought as a difficult task has now become a reality due to advances in the
field of Automatic Identification, wireless communications, distributed computation process and
fast speed of Internet . From just a data perspective the amount of data generated, stored and
processed will be enormous. We focused on making this architecture as a sensor based architecture
where each sensor node will be as important as the sensor network itself. Visualizing each sensor as
having intelligence is the ultimate aim of any architecture in the IoT domain
 There is a lot of pervasive presence in the human environment of things or objects,
described general overview of internet evolution with several IoT services with the use of radio-
frequency identification (RFID) tags, sensors, actuators, mobile phones, smart embedded devices,
etc. – which, through unique addressing schemes, are able to effectively communicate and interact
with each other and work together to reach a common goal of making the system easier to operate
and utilize. The objects that will be connected will be adaptive, intelligent, and responsive
2. FUTURE VISION OF INTERNET OF THINGS
The Internet of Things is a vision which is under development and there can be many stake
holders in this development depending upon their interests and usage. It is still in nascent stages
where everybody is trying to interpret IoT in with respect to their needs. Sensor based data
collection, data management, data mining and World Wide Web is involved in the present vision.
Of course sensor based hardware is also involved. A simple and broad definition of the internet of
things and the basic idea of this concept is the pervasive presence around us of a variety of things or
objects – such as Radio-Frequency Identification (RFID) tags, sensors, actuators, mobile phones,
etc. – which, through unique addressing schemes, are able to interact with each other and cooperate
with their neighbors to reach common goals. Fig. 2 has been discussion on three particular visions
given by.

They are:
• Things Oriented Vision
• Internet Oriented Vision
• Semantic Oriented Vision

A. Things Oriented Vision

This vision is supported by the fact that we can track anything using sensors and pervasive
technologies using RFID. The basic philosophy is uniquely identifying any object using
specifications of Electronic Product Code (EPC) .This technique is extended using sensors. It is
important to appreciate the fact that future vision will depend upon sensors and its capabilities to
fulfill the “things” oriented vision. We will be able to generate the data collectively with the help of
sensors, and sensor type embedded system. The summarized vision will be dependent upon sensor
based networks as well as RFID-based Sensor Networks which will take care of the
integration of technology based on RFID and sophisticated sensing and computing devices and the
global connectivity.
 Fig.2 Three main visions of Internet of Things.
B. Internet Oriented Vision
The internet-oriented vision has pressed upon the need to make smart objects which are
connected. The objects need to have characteristics of IP protocols as this is one of the major
protocols being followed in the world of Internet. The sensor based object can be converted in to an
understandable format, which can be identified uniquely and its attributes can be continuously
monitored. This makes the base for smart embedded objects which can be assumed to be a
microcomputers having computing resources.

C. Semantic Oriented Vision

This vision is powered by the fact that the amount of sensors which will be available at our
disposal will be huge and the data that they will collect will be massive in nature. Thus we will have
vast amount of information, possibly redundant, which needs to be processed meaningfully. The
raw data needs to be managed, processed and churned out in an understandable manner for better
representations and understanding. If we are able to make the sets of data into homogeneous and
heterogeneous formats then the interoperability issues of understanding the data will be dependent
upon the semantic technologies to process the data. It is here that needs a generic vision of
processing the raw data in to meaningful data and a marked separation of data and their
interpretation.

meaningful inferences to develop a unified picture of the situation for smart applications. This is
possible through large scale sensor networks, data processing and inferences using smart sensing
and cloud computing. The inferences will make the sensors sensible enough to rectify the whole
process which in turn will move towards making the whole process intelligent. The components that
make up the WSN monitoring network include:
• Wireless Sensor Networks hardware - Typically a WSN node contains interfaces to sensors,
computing and processing units, transceiver units and power supply. More sophisticated sensor
nodes can communicate over multiple frequencies
• Wireless Sensor Networks Communication Stack (WSNCS) – The nodes will be deployed in an
adhoc manner. Communication topology will be an important factor for communication through the
system of WSN nodes. There is this communication stack at one central node which will be able to
interact with the connected world through the Internet and which will act as a
gateway to the WSN subnet and the Internet .
• Middleware–This is associated with the internet infrastructure and the concept of service oriented
architecture (SOA) for access to heterogeneous sensor resources as described in. WSNs
technological advances in hardware domain catering to circuits and wireless communications have
made robust and cost effective devices in sensing applications. This has led to the use of sensors in
wireless communication devices in diversified environments. Sensor data is collected and sent for
centralized, distributed or any hybrid processing module for data processing. Hence, there are
several challenges WSN has to face to develop a successful IoT communication networks.

A. Communication Mechanism- 6lowpan Challenges

All the objects that are present in the environment can be called object fit to be the “things”
of the internet. All these objects need an address which must be unique. This uniqueness property
will be a unique constraint and it will pave the way to gather information and even control sensor
based devices. Internet Protocol is the standard based protocol which is used for internetworking
methods of Internet. The first version was IPv4 and was thought of having huge address spaces. But
IPv4 got exhausted. smart embedded devices or simply a sensor. Their communication mechanisms
will be Wi-Fi, DSL, Satellite, Cable, Ethernet and so forth. The typical packet size of the
communicating protocol will be around 1500 data bytes to 9000 data bytes and even more. Today
large amount of spatial data is also being generated and thus we can use to use metadata for
connecting database and Internet. As happens in World Wide Web, the operations with sensor
nodes may not be possible by giving unique names to the sensors. Instead a unique address scheme
must be formulated and will be known as Unique Resource Name (URN).A look up table of these
URN must be present at the centralized node commonly known as gateway to the sensor sub
system. Thus entire network now forms a web of connectivity from users (high-level) to sensors
(low-level) that is addressable (through URN) accessible (through URL) and controllable (through
Uniform Resource Characteristics - URC) [11]
• Data Storage - As IoT is getting developed the amount of data getting created is huge. The data
centers which will be storing this data will also needs space requirement as well as the energy and
power resources. It is this data which needs to be organized and processed. Semantic
data fusion models will also be required to create meaning out of this data. Artificial Intelligence
algorithms must be applied to extract meaning from this redundant data. Data storage and analysis
will be a challenge when the whole world will be connected through IoT.

• Visualization - Any interaction of user with the environment will need proper visualization
software which will highlight the sensing mechanism as well the interpretation of data scenario too.
Touch screens and smart embedded tablets have created a conductive environment for the system.
The information which is being processed in to meaningful data using sensor fusion
algorithms will present lot many inferences about the current situation.

4. IOT: SERVICES AND APPLICATIONS

Let us look into the possible set of future possibilities which we can have a rewarding
applications. Some of the attributes which can be considered while developing application is
highlighted in which says the network availability, bandwidth, area of coverage, redundancy, user
involvement and impact analysis. Fig.7 mainly focuses on the properties of the RFID, sensors and
6lowpan communication networks based IoT services.
Bluetooth
The Android platform includes support for the Bluetooth network stack, which
allows a device to wirelessly exchange data with other Bluetooth devices. The
application framework provides access to the Bluetooth functionality through
the Android Bluetooth APIs. These APIs let applications wirelessly connect to
other Bluetooth devices, enabling point-to-point and multipoint wireless
features.

Using the Bluetooth APIs, an Android application can perform the following:

Scan for other Bluetooth devices

Query the local Bluetooth adapter for paired Bluetooth devices

Establish RFCOMM channels

Connect to other devices through service discovery

Transfer data to and from other devices

Manage multiple connections

This page focuses on Classic Bluetooth. Classic Bluetooth is the right choice for more
battery-intensive operations, which include streaming and communicating between
Android devices. For Bluetooth devices with low power requirements, Android 4.3 (API
level 18) introduces API support for Bluetooth Low Energy. To learn more, see Bluetooth
Low Energy.

This document describes different Bluetooth profiles, including the Health Device Profile. It
then explains how to use the Android Bluetooth APIs to accomplish the four major tasks
necessary to communicate using Bluetooth: setting up Bluetooth, finding devices that are
either paired or available in the local area, connecting devices, and transferring data
between devices.

The Basics
In order for Bluetooth-enabled devices to transmit data between each other, they must
first form a channel of communication using a pairing process. One device, a discoverable
device, makes itself available for incoming connection requests. Another device finds the
discoverable device using a service discovery process. After the discoverable device
accepts the pairing request, the two devices complete a bonding process where they
exchange security keys. The devices cache these keys for later use. After the pairing and
bonding processes are complete, the two devices exchange information. When the session
is complete, the device that initiated the pairing request releases the channel that had
linked it to the discoverable device. The two devices remain bonded, however, so they can
reconnect automatically during a future session as long as they're in range of each other
and neither device has removed the bond.

Bluetooth Permissions
In order to use Bluetooth features in your application, you must declare the Bluetooth
permission BLUETOOTH. You need this permission to perform any Bluetooth communication,
such as requesting a connection, accepting a connection, and transferring data.

If you want your app to initiate device discovery or manipulate Bluetooth settings, you
must declare the BLUETOOTH_ADMIN permission in addition to theBLUETOOTH permission.
Most applications need this permission solely for the ability to discover local Bluetooth
devices. The other abilities granted by this permission should not be used, unless the
application is a "power manager" that will modify Bluetooth settings upon user request.

Declare the Bluetooth permission(s) in your application manifest file. For example:

<manifest ... >

<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
...
</manifest>
See the <uses-permission> reference for more information about declaring application
permissions.

Setting Up Bluetooth

Before your application can communicate over Bluetooth, you need to verify that
Bluetooth is supported on the device, and if so, ensure that it is enabled.

If Bluetooth is not supported, then you should gracefully disable any Bluetooth features. If
Bluetooth is supported, but disabled, then you can request that the user enable Bluetooth
without leaving your application. This setup is accomplished in two steps, using
the BluetoothAdapter:

1.Get the BluetoothAdapter.

The BluetoothAdapter is required for any and all Bluetooth activity. To get
the BluetoothAdapter, call the static getDefaultAdapter() method. This returns
a BluetoothAdapter that represents the device's own Bluetooth adapter (the Bluetooth
 radio). There's one Bluetooth adapter for the entire system, and your application can
interact with it using this object. If getDefaultAdapter() returns null, then the device
does not support Bluetooth and your story ends here. For example:
BluetoothAdapter mBluetoothAdapter = BluetoothAdapter.getDefaultAdapter();
if (mBluetoothAdapter == null) {
// Device does not support Bluetooth
}
2.Enable Bluetooth.

Next, you need to ensure that Bluetooth is enabled. Call isEnabled() to check whether
Bluetooth is currently enabled. If this method returns false, then Bluetooth is disabled.
To request that Bluetooth be enabled, call startActivityForResult(), passing in
an ACTION_REQUEST_ENABLE intent action. This call issues a request to enable Bluetooth
through the system settings (without stopping your application). For example:
if (!mBluetoothAdapter.isEnabled()) {
Intent enableBtIntent = new
Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
startActivityForResult(enableBtIntent, REQUEST_ENABLE_BT);
}
A dialog will appear requesting user permission to enable Bluetooth, as shown in Figure
1. If the user responds "Yes," the system will begin to enable Bluetooth, and focus will
return to your application once the process completes (or fails).
The REQUEST_ENABLE_BT constant passed
to startActivityForResult() is a locally defined integer
that must be greater than 0. The system passes this Figure 1: The
constant back to you in enabling Bluetooth dialog.
your onActivityResult()implementation as
the requestCode parameter.
If enabling Bluetooth succeeds, your activity receives the RESULT_OK result code in
the onActivityResult()callback. If Bluetooth was not enabled due to an error (or the
user responded "No") then the result code is RESULT_CANCELED.
Optionally, your application can also listen for the ACTION_STATE_CHANGED broadcast intent,
which the system broadcasts whenever the Bluetooth state changes. This broadcast
contains the extra fields EXTRA_STATE and EXTRA_PREVIOUS_STATE, containing the new and
old Bluetooth states, respectively. Possible values for these extra fields
are STATE_TURNING_ON, STATE_ON, STATE_TURNING_OFF, and STATE_OFF. Listening for this
broadcast can be useful if your app needs to detect runtime changes made to the
Bluetooth state.

Tip: Enabling discoverability will automatically enable Bluetooth. If you plan to

consistently enable device discoverability before performing Bluetooth activity, you can
skip step 2 above. For more information, read the enabling discoverability, section on this
page.

Finding Devices
Using the BluetoothAdapter, you can find remote Bluetooth devices either through device
discovery or by querying the list of paired devices.
Device discovery is a scanning procedure that searches the local area for Bluetooth-
enabled devices and requests some information about each one. This process is
sometimes referred to as discovering, inquiring, or scanning. However, a nearby Bluetooth
device responds to a discovery request only if it is currently accepting information
requests by being discoverable. If a device is discoverable, it will respond to the discovery
request by sharing some information, such as the device's name, its class, and its unique
MAC address. Using this information, the device that is performing the discovery process
can then choose to initiate a connection to the discovered device.

Once a connection is made with a remote device for the first time, a pairing request is
automatically presented to the user. When a device is paired, the basic information about
that device—such as the device's name, class, and MAC address—is saved and can be
read using the Bluetooth APIs. Using the known MAC address for a remote device, a
connection can be initiated with it at any time without performing discovery, assuming the
device is still within range.

Note that there is a difference between being paired and being connected:

To be paired means that two devices are aware of each other's existence, have a
shared link-key that can be used for authentication, and are capable of establishing an
encrypted connection with each other.

To be connected means that the devices currently share an RFCOMM channel and are
able to transmit data with each other. The current Android Bluetooth API's require
devices to be paired before an RFCOMM connection can be established. Pairing is
automatically performed when you initiate an encrypted connection with the Bluetooth
APIs.

The following sections describe how to find devices that have been paired, or discover new
devices using device discovery.

Note: Android-powered devices are not discoverable by default. A user can make the
device discoverable for a limited time through the system settings, or an application can
request that the user enable discoverability without leaving the application. For more
information, see the enable discoverability section on this page.

Querying paired devices

Before performing device discovery, it's worth querying the set of paired devices to see if
the desired device is already known. To do so, call getBondedDevices(). This will return a
set of BluetoothDevice objects representing paired devices. For example, you can query
all paired devices and get the name and MAC address of each device, as the following
code snippet demonstrates:

Set<BluetoothDevice> pairedDevices = mBluetoothAdapter.getBondedDevices();

if (pairedDevices.size() > 0) {
// There are paired devices. Get the name and address of each paired device.
for (BluetoothDevice device : pairedDevices) {
String deviceName = device.getName();
String deviceHardwareAddress = device.getAddress(); // MAC address
}
}
To initiate a connection with a Bluetooth device, all that's needed from the
associated BluetoothDevice object is the MAC address, which you retrieve by
calling getAddress(). You can learn more about creating a connection in the section
about Connecting Devices.

Caution: Performing device discovery consumes a lot of the Bluetooth adapter's

resources. After you have found a device to connect to, be certain that you stop discovery
with cancelDiscovery() before attempting a connection. Also, you shouldn't perform
discovery while connected to a device because the discovery process significantly reduces
the bandwidth available for any existing connections.

Discovering devices
To start discovering devices, simply call startDiscovery(). The process is asynchronous
and returns a boolean value indicating whether discovery has successfully started. The
discovery process usually involves an inquiry scan of about 12 seconds, followed by a page
scan of each device found to retrieve its Bluetooth name.

In order to receive information about each device discovered, your application must
register a BroadcastReceiver for the ACTION_FOUND intent. The system broadcasts this
intent for each device. The intent contains the extra fields EXTRA_DEVICE and EXTRA_CLASS,
which in turn contain aBluetoothDevice and a BluetoothClass, respectively. The following
code snippet shows how you can register to handle the broadcast when devices are
discovered:

@Override
protected void onCreate(Bundle savedInstanceState) {
...
// Register for broadcasts when a device is discovered.
IntentFilter filter = new IntentFilter(BluetoothDevice.ACTION_FOUND);
registerReceiver(mReceiver, filter);
}
// Create a BroadcastReceiver for ACTION_FOUND.
private final BroadcastReceiver mReceiver = new BroadcastReceiver() {
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (BluetoothDevice.ACTION_FOUND.equals(action)) {
// Discovery has found a device. Get the BluetoothDevice
// object and its info from the Intent.
BluetoothDevice device =
intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE);
String deviceName = device.getName();
String deviceHardwareAddress = device.getAddress(); // MAC address
}
}
};
@Override
protected void onDestroy() {
super.onDestroy();
...
// Don't forget to unregister the ACTION_FOUND receiver.
unregisterReceiver(mReceiver);
}
To initiate a connection with a Bluetooth device, all that's needed from the
associated BluetoothDevice object is the MAC address, which you retrieve by
calling getAddress(). You can learn more about creating a connection in the section
about Connecting Devices.

Caution: Performing device discovery consumes a lot of the Bluetooth adapter's

resources. After you have found a device to connect to, be certain that you stop discovery
with cancelDiscovery() before attempting a connection. Also, you shouldn't perform
discovery while connected to a device because the discovery process significantly reduces
the bandwidth available for any existing connections.

Enabling discoverability
If you would like to make the local device discoverable to other devices,
call startActivityForResult(Intent, int) with theACTION_REQUEST_DISCOVERABLE intent.
This will issue a request to enable the system's discoverable mode without having to
navigate to the Settings app, which would stop your own app. By default, the device
becomes discoverable for 120 seconds, or 2 minutes. You can define a different duration,
up to 3600 seconds (1 hour), by adding the EXTRA_DISCOVERABLE_DURATION extra.

Caution: If you set the EXTRA_DISCOVERABLE_DURATION extra's value to 0, the device is

always discoverable. This configuration is insecure and therefore highly discouraged.

The following code snippet sets the device to be discoverable for 5 minutes (300 seconds):

Intent discoverableIntent =
new Intent(BluetoothAdapter.ACTION_REQUEST_DISCOVERABLE);
discoverableIntent.putExtra(BluetoothAdapter.EXTRA_DISCOVERABLE_DURATION, 300);
startActivity(discoverableIntent);

Figure 2: The enabling discoverability dialog.

A dialog is displayed, requesting the user's permission to make the device discoverable, as
shown in Figure 2. If the user responds "Yes," then the device becomes discoverable for
the specified amount of time. Your activity then receives a call to
the onActivityResult() callback, with the result code equal to the duration that the
device is discoverable. If the user responded "No," or if an error occurred, the result code
will be RESULT_CANCELED.

Note: If Bluetooth has not been enabled on the device, then enabling device
discoverability will automatically enable Bluetooth.

The device silently remains in discoverable mode for the allotted time. If you would like to
be notified when the discoverable mode has changed, you can register a
BroadcastReceiver for the ACTION_SCAN_MODE_CHANGED intent. This intent contains the extra
fields EXTRA_SCAN_MODE andEXTRA_PREVIOUS_SCAN_MODE, which provide the new and old
scan mode, respectively. Possible values for each extra are as follows:

SCAN_MODE_CONNECTABLE_DISCOVERABLE

The device is in discoverable mode.

SCAN_MODE_CONNECTABLE

The device is not in discoverable mode but can still receive connections.
SCAN_MODE_NONE

The device is not in discoverable mode and cannot receive connections.

If you are initiating the connection to a remote device, you do not need to enable device
discoverability. Enabling discoverability is only necessary when you want your application
to host a server socket that accepts incoming connections, as remote devices must be
able to discover other devices before initiating connections to those other devices.

Connecting Devices
In order to create a connection between two devices, you must implement both the server-
side and client-side mechanisms because one device must open a server socket, and the
other one must initiate the connection using the server device's MAC address. The server
device and the client device each obtain the required BluetoothSocket in different ways.
The server receives socket information when an incoming connection is accepted. The
client provides socket information when it opens an RFCOMM channel to the server.

The server and client are considered connected to each other when they each have a
connected BluetoothSocket on the same RFCOMM channel. At this point, each device can
obtain input and output streams, and and data transfer can begin, which is discussed in
the section about Managing a Connection. This section describes how to initiate the
connection between two devices.

Connection techniques
One implementation technique is to automatically prepare each device as a server so that
each device has a server socket open and listening for connections. In this case, either
device can initiate a connection with the other and become the client. Alternatively, one
device can explicitly host the connection and open a server socket on demand, and the
other device initiates the connection.

Figure 3: The Bluetooth pairing dialog.

Note: If the two devices have not been previously paired, then the Android framework
automatically shows a pairing request notification or dialog to the user during the
connection procedure, as shown in Figure 3. Therefore, when your application attempts to
connect devices, it doesn't need to be concerned about whether or not the devices are
paired. Your RFCOMM connection attempt will block until the user has successfully paired
the two devices, and the attempt fails if the user rejects pairing, or if the pairing process
fails or times out.

Connecting as a server
When you want to connect two devices, one must act as a server by holding an
open BluetoothServerSocket. The purpose of the server socket is to listen for incoming
connection requests and provide a connected BluetoothSocket after a request is
accepted. When the BluetoothSocket is acquired from the BluetoothServerSocket,
the BluetoothServerSocket can—and should—be discarded, unless you want the device to
accept more connections.
To set up a server socket and accept a connection, About UUID
complete the following sequence of steps: format for a string ID used to
uniquely identify information. The
1.Get a BluetoothServerSocket by point of a UUID is that it's big enough
calling listenUsingRfcommWithServiceRecord(). that you can select any random ID,
and it won't clash with any other ID.
The string is an identifiable name of your service,
In this case, it's used to uniquely
which the system automatically writes to a new
identify your application's Bluetooth
Service Discovery Protocol (SDP) database entry on service. To get a UUID to use with
the device. The name is arbitrary and can simply be your application, you can use one of
your application name. The UUID is also included in the many random UUID generators on
the SDP entry and forms the basis for the connection the web, then initialize
agreement with the client device. That is, when the a UUID withfromString(String
client attempts to connect with this device, it will ).
carry a UUID that uniquely identifies the service with
which it wants to connect. These UUIDs must match in order for the connection to be
accepted.
2.Start listening for connection requests by calling accept().

This is a blocking call. It returns when either a connection has been accepted or an
exception has occurred. A connection is accepted only when a remote device has sent a
connection request containing a UUID that matches the one registered with this
listening server socket. When successful, accept() returns a
connectedBluetoothSocket.
3.Unless you want to accept additional connections, call close().

This method call releases the server socket and all its resources, but doesn't close the
connected BluetoothSocket that's been returned byaccept(). Unlike TCP/IP, RFCOMM
allows only one connected client per channel at a time, so in most cases, it makes
sense to call close() on theBluetoothServerSocket immediately after accepting a
connected socket.
Because the accept() call is a blocking call, it should not be executed in the main activity
UI thread so that your application can still respond to other user interactions. It usually
makes sense to do all work that involves a BluetoothServerSocket or BluetoothSocket in
a new thread managed by your application. To abort a blocked call such as accept(),
call close() on the BluetoothServerSocket or BluetoothSocket from another thread. Note
that all methods on a BluetoothServerSocket or BluetoothSocket are thread-safe.

Managing a Connection

After you have successfully connected multiple devices, each one has a
connected BluetoothSocket. This is where the fun begins because you can share
information between devices. Using the BluetoothSocket, the general procedure to
transfer data is as follows:

1.Get the InputStream and OutputStream that handle transmissions through the socket
using getInputStream() and getOutputStream(), respectively.

2.Read and write data to the streams using read(byte[]) and write(byte[]).
There are, of course, implementation details to consider. In particular, you should use a
dedicated thread for reading from the stream and writing to it. This is important because
both the read(byte[]) and write(byte[]) methods are blocking calls.
The read(byte[]) method blocks until there is something to read from the stream.
The write(byte[]) method doesn't usually block, but it can block for flow control if the
remote device is not calling read(byte[]) quickly enough and the intermediate buffers
become full as a result. So, your main loop in the thread should be dedicated to reading
from the InputStream. A separate public method in the thread can be used to initiate
writes to the OutputStream.