N. Sriskanthan et al.

: Protocol for Plug and Play in Bluetooth based Home Networks 457

Protocol for Plug and Play in Bluetooth based Home Networks

N. Sriskanthan, Member IEEE, D. Tandon, Member IEEE and K. K. Lee, Member, IEEE

Abstract — Home Networks, interlinking devices like in the market, Bluetooth is a suitable standard for Home
fridges, air conditioners, home theatres, security devices, Networks[3]. Hence our network is primarily based on the
lighting systems are about to realize the concept of a smart Bluetooth technology.
home. Among the competing technologies, Bluetooth, with its In this paper, we discuss the features of our network model,
low cost, low power consumption and its easily configurable the HomeBT protocol and the implementation of the
devices has emerged as one of the most suitable wireless appliances.
standard for Home Networks. In order to find a large market
for any automated home system, it must be user friendly, since II. NETWORK MODEL
most consumers are non-technical users. Hence, Plug and
Play is an important feature that must be incorporated into In a Bluetooth piconet, a collection of seven slave devices
any home network environment. In this paper we suggest a can operate together with one common Master. All devices on
method for data transfer, through the proposed HomeBT the piconet follow the frequency hopping scheme and timing
protocol. This protocol provides Plug and Play feature to of the master[1]. In our network model, shown in figure 1, the
appliances, in Home Networks using the Bluetooth Access Point (AP) acts as the master of its piconet. The
technology. Further, an Appliance_Changed_Status appliances or the attached devices (AD) connect to the home
Command and Status Change Event have been suggested as network through the AP. This architecture ensures scalability
additions in the Bluetooth HCI specifications1. of the system, as with addition of a new AP, seven more
Index Terms — Bluetooth, Home Networks, Home
devices can be added. The AP in turn, connects to the Host
Automation, Plug n Play. Control Device (HCD) through Ethernet (wired or wireless).
This HCD serves as a gateway for the home network. This
network model provides flexibility of building an entirely
I. INTRODUCTION wireless network by using 802.11 cards at the AP to connect to
Home environments require a cost-effective network, with
minimum network infrastructure involved in them. They
should be simple to use, easily configurable and easily
manageable even by a novice user, who doesn’t have much
knowledge of the system. The design considerations require
that the network architecture makes the system scalable, so
that new devices can easily be integrated into it. The overall
system should be fast enough to undertake the processes in real
time. At the same time, the system, with all these features,
should be cost effective in order to justify its application in
home automation.
Bluetooth technology, which was meant to provide a
replacement for cables, is optimized for limited wireless
network capability. It operates over a range of 100m/10m
(Class I/Class II), at 2.4 GHz frequency, providing data rate of
1 Mbps[1]. In comparison to 802.11, Bluetooth is preferred
where size, cost and mobility are more important than range
and throughput[2]. With single chip solutions being available

1
This work was supported in part by the Infoccom Development Authority,
Singapore.
Nadarajah Sriskanthan is an Associate Professor at the School of
Computer Engineering, Nanyang Technological University, Singapore
639811 (e-mail: esris@ntu.edu.sg). Fig. 1. Network Model of the Home Network. AD stands for Attached
Devashi Tandon was with the School of Computer Engineering, Nanyang Devices and refers to the controllable Appliances on the network.. AP
Technological University, Singapore 639811 for six months. He is now with stands for Access Point and provides interface between the Ethernet
Infosys Technologies, India. (e-mail: devashi@indiatimes.com). network and the Bluetooth (BT) connection. The Wireless Remote,
Keok Kee Lee is an Associate Professor at the School of Computer Internet, PC form the user-side devices which connect to the Host
Engineering, Nanyang Technological University, Singapore 639811 (e-mail: Controller (HCD).
ekklee@ntu.edu.sg).
Contributed Paper
Manuscript received January 23, 2004 0098 3063/04/$20.00 © 2004 IEEE
458 IEEE Transactions on Consumer Electronics, Vol. 50, No. 2, MAY 2004

the HCD( which will serve as an Access Point for TABLE I

802.11connection). Or the network could rely on an existing DESCRIPTOR TABLES
wired LAN.
The network connects to external world through this HCD. MAC Address Priority
The HCD connects to user-side device, from which appliances
6 Bytes 1 Byte
will be controlled. This user-side device could be a PC, a
A: Appliance (AD) Side Descriptor Table
mobile phone, PDA, or a RF based remote control built for the
home network. The manufacturer should provide driver for
their appliance, to carry out communication with the appliance. MAC Address Piconet ID Connection Handle
This driver shall be installed at the user-side device while 6 Bytes 3 bits 12 bits
configuring the appliance before it can be used on the network. B: Access Point (AD) Side Descriptor Table
The justification for the manufacturer to provide their driver is
that the appliance manufacturer know their appliance best.
MAC Address Device Name Device ID Status
This feature also allows the functionality of their appliance to
have flexibility on the network. This means that an appliance 6 Bytes 32 Bytes 2 Bytes 1 Byte
already on the network can be easily replaced with its new C: Host Controller (HCD) Side Descriptor Table
version, just by replacing the driver for it. security. Two, when a higher priority device requests
connection to the appliance, its request will be serviced (refer
III. HOMEBT PROTOCOL figure 2). If there is a lower priority device currently managing
the system, it will relinquish its control in an orderly manner
A. Appliance (AD) and then the requesting device will take over the system.
The appliance consists of an Appliance Side Descriptor Hence in this way, if a user wants to control the appliance
Table, as illustrated in Table 1(A). This table lists the MAC directly through a PDA, he would be able to do so even if the
(medium access control sub-layer) address of all the devices device is connected to the Home Network.
that can communicate with the Appliance and hence control it. When the appliance is switched on, it carries out an Inquiry
It also mentions the priority of these devices. Since the priority process to find the nearby devices. It then tries to connect with
size is of 1 Byte, a maximum of 256 devices can be defined to the devices found and listed in the descriptor table, in order of
connect to the appliance. The descriptor table serves two priority, by sending a Create_Connection packet to the device.
purposes. One, any device not defined in this list will not be If the device eventually responds with a Connection Complete
allowed to connect to the appliance, thereby providing Event packet (with the status indicating succesful

Fig. 2. HomeBT Protocol. This Diagram illustrates the behaviour of the protocol. Then number in parentheses denotes the sequence of the packet. It
demonstrates the use of the descriptor tables and the operation of Plug and Play, using examples of some of the possible scenarios.
N. Sriskanthan et al.: Protocol for Plug and Play in Bluetooth based Home Networks
Fig. 3. Plug N Play Flow Diagram. This diagram explains the sequential
transfer of packets on the network. The number in the parentheses
denotes the order in which the packet will be transferred. Hence,
Connection Request (2) will follow Connection Request (1).
establishment of connection), then the connection is retained,
otherwise the appliance tries to connect to the next relevant
device (refer figure 2). The process continues till it connects to
one of the devices listed in the descriptor table. If no device
wants to control the appliance directly, then it would
eventually connect to the Home Network through the Access
Point. In case of multiple AP’s, the AP closest in range can be
given higher priority so that the appliance first tries to connect
through it. The process would be repeated once a
disconnection occurs.
B. Access Point (AP)
The Access Point (AP) has a descriptor table, shown in figure
3(B), listing all the relevant appliances within its range. Their
connection status is represented by the Piconet ID. When a
device connects to the AP, the AP will issue it a Piconet ID and
Fig. 4. Packet Formats.
Contributed Paper
Manuscript received January 23, 2004 0098 3063/04/$20.00 © 2004 IEEE
459
store this in the descriptor table. The first connecting device
would be alloted a piconet ID of 1, the second one would be
alloted a piconet ID of 2, and so on. Each device would also
have a corresponding Bluetooth Connection Handle. The
piconet ID is used for identifying the device on the home
network, whereas the Connection Handle is used for Bluetooth
communication between the AP and the AD.
Again one reason of implementing this table is security. Any
device other than the ones listed on the AP will not be allowed
access to the network (see figure 2). This descriptor table also
assists in the implementation of the Plug and Play feature.
When a device tries to connect to the AP, it accepts the
connection if it is not already connected to seven devices and
if the device is listed in its descriptor table. After establishing
the connection, the Piconet ID in the descriptor table is
modified, and the Plug n Play is implemented.
C. Plug and Play (PnP)
The HCD contains a descriptor table enlisting all the ADs
on the network, as shown in figure 3(C). The devices in the
table are defined at the time of configuring them on the
network. The device ID consists of the AP ID (13 bits) issued
to the AP by the HCD, plus the Piconet ID (3 bits) issued to
the device by the AP when it connects to it. When an AD
connects to the AP, the AP sends a Device Detection Packet
(DDP) to the HCD. This will inform the HCD, about the
Device ID of the device that has come up in the network. The
HCD would then send an ACKP1 to the AP from which it
received the DDP.
An appliance can have many status. The protocol currently
supports a maximum of 256 status for the appliance. Status
0x00 is reserved for Disconnected, and 0xFF is reserved for
Connected. When an AD gets disconnected from its AP due to
some reason, the Host Controller of the AP receives a
Disconnection_Complete event. On receiving this event, the
AP sends a Status Change Packet (SCP) with status byte as
0x00 to the HCD. Whenever the appliance changes its status it
must inform the Access Point with a Status Change Event. The
AP will then generate the appropriate Status Change Packet.
The HCD sends back an ACKP1 packet acknowledging the
information.
Also, the HCD periodically checks the change in status of
the device in its descriptor table. If new devices have been
added during this interval, it sends a Cumulative DDP or the
New Devices Packet (NDP) to inform the user of the added
devices (refer figure 3). If status of the devices has been
changed then the cumulative SCP or the Modified Devices
Packet (MDP) is sent. If all the devices have got removed then
the number of devices is sent as FFFFH, and in this case no
device ID’s are sent. The user side device responds with an
ACKP2, for every NDP/MDP received. The reason for using
this method is to keep the configuration at the user-side
simple[4]. Once the network is configured, the user can use
any device to control the appliances. The user just needs to
install the driver(s) for the appliances he wishes to control, on
460
the user-device and establish a connection with the HCD. Once
it connects to the HCD, the HCD will generate an NDP
including information for all the requested devices. This will
inform the user about the device ID’s of the various appliances
and the appliance names. The MAC address information is
kept within the internal network. Subsequently, a MDP will be
issued to the user, informing the user about the current status
of the appliances.
The packet formats are represented in figure 4. The shaded
portion in the data packet is issued by the driver of the
appliance (mentioned earlier) at the user side, and then
transferred to the appliance. The AP sends this data to the
relevant AD as a Bluetooth Data Packet which is then
interpreted by the AD. When the communication is other way,
this data is issued by the AD, and passed on to the AP as a
Bluetooth data packet, which then transfers it to the driver at
the user side. The driver of the appliance at the user side then
interprets this data and takes necessary action.
IV. IMPLEMENTATION
The stack implementations on the various devices are
illustrated in Figure 5. The network was tested by simulating
the various devices on a computer. For the Bluetooth
implementations, the modules [5] were kept in presence of a
total of five neighbourhood Bluetooth devices2 to test the
behaviour of the network in presence of other devices. When
the mobile phone tried to connect to the Access Point, it was
refused connection as it was not listed in the AP descriptor
table. Two systems were used as appliances. One was an I2C
(Inter Integrated Circuit Communication) based system of
circuits[6] connected to a 8051 microcontroller and a
Bluetooth module. The other was a robotic vehicle with a
infra-red feedback. Both these devices were developed by
different projects (appliance manufacturers). The robotic
vehicle had its driver implemented in Java. This driver was
made to communicate with the HCD through TCP/IP[7],[8].
The performance tests of the system showed that the HCD was
able to generate the NDP and SCP packets as suggested in this
paper. Also, the driver was able to communicate with the
robotic device appropriately. The driver instructed the robotic
vehicle on the basis of feedback received from it. In one of the
Fig. 5. Implementation Block Diagram. This Diagram illustrates the stack implementations on the various devices on the network.
IEEE Transactions on Consumer Electronics, Vol. 50, No. 2, MAY 2004
tests the driver communicated with its appliance (the robotic
vehicle), uninterrupted for 12 minutes 32 seconds before a
Bluetooth Hardware error occurred. On hardware error, the
appliance was able to re-establish connection automatically
within 20 seconds and the communication resumed, before
being terminated by the user.
It must be noted that since the AP acts as master of its
piconet, the Bluetooth device on the appliance must support
master-slave switch[9], to be compatible with the system.
Also, when an appliance changes its status it must inform the
Bluetooth through a Bluetooth command to generate a
Bluetooth event, which informs the AP of the status change.
Only after this, the AP can generate a HomeBT Status Change
Packet. This Bluetooth command Appliance_Changed_Status
and the Event Status Change can be defined in Bluetooth as
mentioned in the next section.
V. SUGGESTED ADDITIONS IN BLUETOOTH
The Appliance_Changed_Status command and the Status
Change event explained in this section are suggested as
additions in the HCI specifications of Bluetooth. The number
in the parentheses denotes the section number they would
possess, if included in the Bluetooth specification. Care has
been taken to define the commands in accordance with the
definition format used in the Bluetooth specifications. Hence,
in order to understand these packets, knowledge of the HCI
specifications of Bluetooth is required. These packets would
help the appliance in informing the user of a status change in
the appliance, almost immediately after the status change
occurs, thereby fully implementing Plug n Play.
A. (4.9.5) Appliance_Changed_Status Command
This command falls in Status Parameters Group (of
Bluetooth Commands). Hence the OGF (Op-Code Group
Field) for this command will be 0x05.
TABLE II
COMMAND DEFINITION
Command OCF
Command Return
Parameters Parameters
HCI_Appliance_ 0x0006 New_State
Changed_Status
N. Sriskanthan et al.: Protocol for Plug and Play in Bluetooth based Home Networks 461

1) Description: TABLE IV
The Appliance_Changed_Status command is used to inform EVENT DEFINITION
the remote devices connected to the local device about the Event Event Code Event Parameters
change in status of the appliance. The New_State command
parameter indicates the new status of the device. The remote Status Change Event 0x21 Status, Connection Handle,
New_State
Bluetooth device will receive the New_State command
parameter in the Status Change event. In Byte format an 2) Event Parameters:
example of the command packet would be 0x01, 0x06, 0x14,
TABLE V
0x01, 0x02 where 0x01 is the Packet Type Identifier for EVENT PARAMETERS
Command Packet, 0x1406 is the Op-Code Status: Size: 1 Byte
(OGF=0x05;OCF=0x06), 0x01 is the parameter total length
and 0x02 is the new status of the appliance. Value Parameter Description
2) Command Parameters 0x00 Status Change successfully completed
0x01-0xFF Status Change failed to complete. Error Code according
TABLE III to Table 6.1 in Bluetooth Specifications.
COMMAND PARAMETERS
New_State: Size: 1 Byte Connection Handle: Size: 2 Bytes (12 Bits Meaningful)

Value Parameter Description Value Parameter Description

0x00 Disconnection. Since this gives same result as
Disconnection Command/Disconnection Complete
event, the Disconnection command may be called
instead.
0x01-0xFE New Status of the appliance. The codes are appliance
specific and will be interpreted by the appliance driver.
0xFF Connection. Since this gives same result as Connection
Request Command/ Connection Complete Event,
Connection Request command may be called instead.
3) Return Parameters
None.
4) Event(s) generated (unless masked away):
When the Host Controller receives the Appliance-
_Changed_Status command, it sends the Command Status
event to the Host. Subsequently, it will inform all the
Bluetooth devices connected to the local device about the
Status Change. The Status Change event will occur at each
Host (including the local host), on successful completion. This
event will indicate (to the local host) that the command has
been completed successfully and hence no Command
Complete event will be sent by the Host Controller to the local
host.
B. (5.2.33) Status Change event
1) Description:
The Status Change Event occurs whenever the status of the
appliance is modified. This event will be generated (at the
Access Point) whenever the remote device (Appliance)
modifies its status. The remote device (Appliance) Bluetooth
will inform the local device (Access Point) Bluetooth of the
new status, leading to the generation of this event. The
Connection_Handle must be a Connection_Handle for an
ACL Connection. In Byte format an example of the event
packet would be 0x04, 0x21, 0x04, 0x00, 0x01, 0x00, 0x02
where 0x04 is the Packet Type Identifier for Event Packet,
0x21 is the Event Code, 0x04 is the parameter total length,
0x00 is the status of the command, 0x0001 is the Connection
Handle and 0x02 is the new status of the appliance.
Contributed Paper
Manuscript received January 23, 2004 0098 3063/04/$20.00 © 2004 IEEE
0xXXXX Connection Handle for which Status has changed. Valid
Range (0x0000-0x0EFF)
New_State: Size: 1 Byte
Value Parameter Description
0x01-0xFE New Status of the appliance. The codes are appliance
specific and will be interpreted by the appliance driver.
0x00, 0xFF These values represent Disconnection and Connection
respectively which will be handled by the
Disconnection Event and Connection Complete events
respectively. Hence they are redundant here.
VI. SECURITY
For any successful home system, security is an important
necessity. It can be said that our system relies on the security
features provided by Bluetooth. It has been assumed that two
Bluetooth devices would always have an unique MAC address,
assigned by the IEEE[10]. The descriptor tables defined on the
AP and the AD would ensure that connection is provided only to
the devices having one of the pre-listed MAC addresses.
Particularly, a secure method is necessary for the appliance(AD)
to connect to the Access Point (AP), since this is an automated
process, undertaken without user intervention. The PIN Code
method provided in Bluetooth would not be sufficient here, since
the PIN code of an AD would have to be stored in an AP (or
vice versa) and hence can be retrieved by a third device.
VII. SUMMARY
The HomeBT Protocol proposed in this paper has been
verified for it’s plug and play features. The implementation of
the AD-side Bluetooth and the AP-side Bluetooth was done on
a PC[11]. These programs can be loaded into micro-
controllers on the devices, and run from there itself.
Eventually, the HCD would be a stand-alone device. The user
would be communicating with the HCD through a separate
device. This device will have the device drivers for all the
appliances loaded on it.
462 IEEE Transactions on Consumer Electronics, Vol. 50, No. 2, MAY 2004

Although, in our implementation only one user was defined, Devashi Tandon (M’02) became a Member(M) of IEEE
since 2002. He completed his Bachelors in Technology
user profiles can be implemented to have multiple users and to
majoring in Electrical Engineering, from the Indian
distinguish different users. Their priorities can be set in order Institute of Technology, Roorkee (Former Univ. of
to identify which user has higher priority while trying to Roorkee) , India. He was awarded the Institute medal for
control an appliance. A default value of appliance settings can his undergraduate thesis on Robotics and Control. After
that he was attached with the School of Computer
be provided for each user in these user profiles, so that the Engineering, NTU, Singapore during the course of
network adapts to each user. which he worked on the Home Automation Project. Currently he is with
Infosys Technologies. His research interests include Home Networking,
Intelligent Control, Autonomous Systems and Robotics.
REFERENCES
[1] Bluetooth Committee “Specifications of the Bluetooth v1.1 System
(Core)” vol. 1, pp 41-42. Feb. 2001.
[2] Silicon Wave “White Paper: Bluetooth and 802.11 compared”. Nov. Lee Keo Kee (M’95) . This author became a Member
2001. (M) of IEEE in 1995. He is an associate professor in the
[3] http://www.thewirelessdirectory.com/BluetoothDevelopment, School of Computer Engineering, Nanyang
“Semiconductors-Single-Chip-Bluetooth.htm”. Oct. 2003 Technological University, Singapore. He obtained his
[4] James Kelsey, “Programming Plug and Play” , Sams Publication, 1995. B.Eng.(Elect.) from the National University of
[5] Bluetooth Committee “Profiles of the Bluetooth v1.0b System Singapore and M.E.E. from Rice University. His
(Profiles).” Dec. 1999 interests are in computer architecture, parallel I/O and
[6] N. Sriskanthan, F. Tan, A. Karande, “Bluetooth based Home scheduling, and electronics and digital systems.
Automation System”, Elsevier Microprocessors and Microsystems, pp.
281-283, May, 2002.
[7] http://java.sun.com/developer/onlineTraining/Programming/BasicJava2/
socket.html. Jan. 2004.
[8] http://java.sun.com/developer/onlineTraining/Programming/BasicJava2/
Code/SocketServer.java. Jan. 2004.
[9] Bluetooth Committee “Specifications of the Bluetooth v1.1 System
(Core)” vol. 1, pp 121-123. Feb. 2001.
[10] Bluetooth Committee, “Bluetooth Assigned Numbers v2.25”, Jan. 2003.
[11] Ericsson Mobile Communications AB, “User Manual (Bluetooth PC
Reference Stack)”, 2001.

Sriskanthan Nadarajah (M’86) became a Member

(M) of IEEE in 1986, He is an Associate Professor with
the School of Computer Engineering at the Nanyang
Technological University, Singapore. He received the
B.Sc. degree in Electrical Engineering from the
University of London and the M.Sc. degree in
Electronic Equipment Design from Cranfield Institute
of Technology, UK during the period 1972 - 1978. He
worked as a Senior Test Engineer with Plessey Radar from 1972 - 1976. From
1978 - 1982, he was Design Engineer at Philips, London. From 1982-1984,
he worked as Research Officer at Cranfield Institute of Technology. Since
1985, he has been teaching Computer Interfacing Techniques,
Microprocessor Systems, Application Specific Microprocessors, Digital TV
and Multimedia Systems Design at the Nanyang Technological University,
Singapore. His research interests are in developing computer interfacing
hardware and software, particularly for the application of Computer Graphics,
Digital Video Systems, Multimedia Technology, Internet Based Training
Systems and Multiprocessors.