236
1, FEBRUARY 2004
An Implementation of Wireless Sensor Network
for Security System using Bluetooth
Soo-Hwan Choi, Byung-Kug Kim, Jinwoo Park, Chul-Hee Kang, Doo-Seop Eom
Abstract — In recent years, the advances in wireless
communication and electronics have accelerated to develop
many wireless network solutions to replace existing wired
networks. A wireless network solution can support mobility
and flexibility of nodes in a network. Especially in sensor
networks, it has many advantages to replace cables with
wireless logical links. On the other hand, Bluetooth is
generally considered as a promising short-range wireless
technology because of its inexpensive cost, low power and
small size, and thus Bluetooth has been gaining increasing
interest from various industries. For the above reasons, we
adopt Bluetooth technology for a wireless sensor network
which is designed for security systems. Since Bluetooth will
continue to be a feature found in many devices, it is
worthwhile to investigate its use in wireless sensor networks.
In this paper, we describe a Bluetooth wireless sensor network
for security systems, which includes the implementation issues
about system architecture, power management, self-
configuration of network, and routing. We think that the
methods or algorithms described in this paper can be easily
applied to other embedded Bluetooth applications for wireless
networks.
Index Terms — wireless, sensor network, Bluetooth,
security system
I. INTRODUCTION
Bluetooth uses short-range radio links, intended to
replace the cables connecting portable and/or fixed electronic
devices [1]. It is envisaged that it will allow for the
replacement of many propriety cables that connect one device
to another with one universal radio link. Its key features are
robustness, low complexity, low power and low cost.
Designed to operate in noisy frequency environments, the
Bluetooth radio uses a fast acknowledgement and frequency
hopping scheme to make the link robust. Bluetooth radio
modules operate in the unlicensed ISM (Industrial, Scientific
and Medical) frequency band at 2.4GHz, and avoid
interference from other signals by hopping to a new frequency
after transmitting or receiving a packet. Compared with other
systems in the same frequency band, the Bluetooth radio hops
faster and uses shorter packets. In this paper, we introduce a
system implementation of a wireless sensor network for
security systems using Bluetooth.
On the other hand, a sensor network is composed of a
large number of sensor nodes that are densely deployed either
inside the phenomenon or very close to it [2]. The position of
sensor nodes need not be engineered or predetermined. This
allows random deployment in inaccessible terrains or disaster
relief operation. But in the existing wired security system,
Contributed Paper
Manuscript received January 11, 2004 0098 3063/04/$20.00 © 2004 IEEE
IEEE Transactions on Consumer Electronics, Vol. 50, No.
because all sensor nodes have to be connected by wires,
whenever they are set up, cables must link the sensor nodes to
a local security system. If cables link to sensor nodes, it will
not only cost a great deal but also be hard to maintain and
mend. Moreover it is hard to change a position of a sensor
node, and if there is an accident such as a disaster that destroys
the wired network, sensor nodes corresponding to that portion
are divested of their function. Consequently if sensor nodes
are linked to a local security system using short range wireless
communication technology, a restriction of a position to set up
sensor nodes disappears and it has more advantages to
maintain, mend and recover than the existing wired network
[3], [4]. Representative short range wireless communication
technologies are Bluetooth, IEEE802.11 WLAN (Wireless
Local Area Networking), HomeRF and IrDA. The reason that
Bluetooth, especially, comes to fore is as follows.
Bluetooth modules can be adapted at low price according
to the law of mass production and used all over the world
because of working at 2.4GHz ISM frequency band [5].
Moreover Bluetooth has the ability to form personal area
networks or Piconets without manual configuration, which
means sensor nodes with Bluetooth modules can be
established only by being placed. And it also has an inherent
power management state to insure a low-power operation. The
power of a sensor node operated with a battery can be
efficiently saved [6].
To overcome the restrictions of wired sensor networks,
we propose to use Bluetooth technology for a wireless sensor
network for security systems. The proposed network consists
of sensor nodes, relay nodes and a control node. All nodes
communicate with each other with the Bluetooth module.
Sensor and relay nodes detect certain events (e.g. someone
enters the security area without permission) and report the
events to the control node. Then, the control node reports the
information received from the sensor or relay nodes to the
local security control system and replies to the corresponding
node with an ACK message. If sensor nodes are not able to
directly reach the control node, the relay nodes placed
between them can relay the message from the sensor node to
the control node. All nodes transmit and receive packets via a
Bluetooth module that is embedded in them. In this paper, we
introduce the implementation issues related to the proposed
network, which includes system architecture, power
management, self-configuration of network and routing. Since
the network configuration of Bluetooth is based on the
Piconets where each Piconet has one master and up to 7 slaves.
So, the tree topology can be considered as a natural and
appropriate choice for the networks using Bluetooth. Thus the
proposed system adopts the tree topology for self-
configuration and routing. The tree topology has many
advantages in that it is easy to find a multi-hop route to the
S.-H. Choi et al.: An Implementation of Wireless Sensor Network for Security System using Bluetooth
control unit or a specific node, to maintain network, and to
control medium access.
This paper is organized as follows. In Section 2, a general
description of Bluetooth is given. In Section 3, the overall
system architecture is described. The developed system’s
description and its performance evaluation are in Section 4.
Finally, we conclude this paper in Section 5.
II. THE OVERVIEW OF THE BLUETOOTH SYSTEM
A hardware architecture overview of Bluetooth is outlined
in Figure 1. It consists of an analog part – the Bluetooth radio,
and a digital part – the Bluetooth Host Controller. [1]
Fig. 1. Bluetooth hardware architecture overview
The Bluetooth radio consists of a transceiver and an
antenna, and operates in the ISM band of 2.4GHz. Information
is modulated using GFSK (Gaussian Frequency Shift Keying) at
a rate of 1M symbols/second and transmitted in one of 79
1MHz channels. Signals are frequency hopped over the 79
channels at a rate of 1600 hops per second.
The Host Controller consists of three parts; the Link
Controller (LC), a CPU core, and an external interface part. The
link controller consists of hardware and software parts that
perform the Bluetooth Baseband processing and physical layer
protocols such as ARQ (Automatic Repeat request) and FEC
(Forward Error Correction). The CPU core executes the Link
Manager (LM) software. It allows the Bluetooth module to
handle inquiries and filters Page requests without involving the
host device. The external interfaces provide the communication
channel between the host and the Host Controller, including
RS232 and USB (Universal Serial Bus) interfaces.
Fig. 2. (a) Piconets with a single slave operation, (b) a multi-slave operation
(c) and a scatternet operation.
The Bluetooth system provides a point-to-point connection
(only two Bluetooth units involved), or a point-to-multipoint
connection, see Figure 2. In the point-to-multipoint connection,
the channel is shared among several Bluetooth units. Two or
more units sharing the same channel form a piconet. One
Bluetooth unit acts as the master of the piconet, whereas the
other unit(s) acts as slave(s). Up to 7 slaves can be active in the
237
piconet. Multiple piconets with overlapping coverage areas
form a scatternet. Each piconet can only have a single master.
However, slaves can participate in different piconets on a time-
division multiplex basis. Each piconet has its own hopping
channel.
Two link types have been defined between a master and
slave(s):
z Synchronous Connection-Oriented (SCO) link
z Asynchronous Connection-Less (ACL) link
The SCO link is a point-to-point link between a master and
a single slave in the Piconet. The ACL link is a point-to-
multipoint link between the master and all the slaves
participating on the Piconet. The communication between two
Bluetooth devices is via packets. Bluetooth packets are
comprised of three major portions, the access code, the header,
and the payload, as shown in Fig. 3. The access code is used in
synchronization and to identify packet channels. If the header
field follows, the access code is 72 bits long, otherwise it is 68
bits long. The header identifies the sender of the packet and the
type of packet being sent. The encoded header field occupies 54
bits. The payload of the packet contains user information and
occupies one, three, or five time slots. Each time slot is 625 µs
long.
Fig. 3. Bluetooth packet format
The Host Controller Interface (HCI) driver on the host side
provides a uniform interface method of accessing the Bluetooth
hardware capabilities. The HCI firmware on the Host controller
side implements the HCI commands for the Bluetooth hardware
by accessing link manager commands, hardware status registers,
control registers, and event registers. Figure 4 provides an
overview of the Host Controller interface concept.
Fig 4. The Host Controller interface software layers
238
III. THE PROPOSED SYSTEM ARCHITECTURE
In this section, we give a full explanation about the
proposed system. To help understand the system operation, we
first introduce an overall working flow of the system and then
explain the initialization procedure for network configuration
and routing. Finally, we introduce the operation of each node
in the system in more detail.
A. System Overview
The purpose of the proposed system is for detecting an
invasion in a building that needs security service, and it
consists of lots of sensor and relay nodes and a control node.
Figure 5 illustrates the communication environment of the
system. Sensor nodes are placed in each room in the building
and logically connected to the control node, which is located
at a certain place in the building and can be reached via relay
nodes.
UA
Sensor node Relay node Control node
Bluetooth Bluetooth Bluetooth
module module module
Logical Communication Link
Fig. 5. Communication environment
The control node is connected to the local security
control system that is implemented using a PC. An operator in
the building can monitor the whole system in real time
through the local security control system. Namely, it is
possible for him to check the state of a certain room and the
operating status of a specific sensor or relay node in the
system at any time whenever he wants. Meanwhile, the local
security control system is connected to a central security
control system via the Internet. In this paper, we do not deal
with this issue.
Sensor and relay nodes detect certain events and report it
to the control node. Then the control node reports the event
received from the sensor or relay node to the local security
control system and replies to the corresponding node with an
ACK packet. The node which had sent an event packet must
receive an ACK packet from the control node to verify that the
event packet was delivered to the control node. If sensor nodes
are not able to directly reach the control node, the relay nodes
placed between them relay the message from the sensor node
to the control node. That is, if a sensor node is not able to
inquire the control node (i.e., the control node is located
outside the range of a sensor node), relay nodes placed
between them form a route from the sensor node to the control
node. All nodes transmit and receive packets via Bluetooth
modules embedded in them.
When a phenomenon is detected by a sensor or relay
node, such an event is translated to a predefined value
corresponding to that event, and then it is transmitted in the
form of an event packet to the control node via the radio link.
In this paper, we assume that sensor and relay nodes have on-
off switches to emulate certain events, e.g., the motion
detectors in those nodes detect a movement, for convenience.
IEEE Transactions on Consumer Electronics, Vol. 50, No. 1, FEBRUARY 2004
Since sensor and relay nodes must be operated without
any external power supply for a long time, it is important to
reduce power consumption. They have a power management
mode to insure their power supplied by battery can be
efficiently saved. The control node does not have a power
management mode because its power can be supplied through
the outer power line.
The application programs for the nodes directly drive their
Bluetooth module through the HCI interface without the help of
the upper layer protocols such as L2CAP and RFCOMM.
Instead, the basic functions of the eliminated upper layer
protocols are implemented in the application program. By doing
this, we can significantly reduce the total program code size and
the program can be operated in a single process. We can thus
extremely use the limited processing power and memory of the
ARM CPU core in the Bluetooth Host Controller. It is because
if there are multiple processes operated in CPU then the
resources such as CPU processing power and memory are more
required for the context switching.
RT B. Network Configuration
Local security control system
It is common that sensor and relay nodes are not able to
directly communicate with the control node. Thus network
configuration is required for routing packets over the multi-
hop route and maintenance of nodes, but which is performed
Central security control system
not by a manual setting but by a self-configuration. As
previously explained in Section 1, the tree topology as shown
in Fig. 7 is used for network configuration in the proposed
system. The tree topology has many advantages in that it is
easy to find a multi-hop route to the control node or a specific
node, to maintain network structure, and to control medium
access and transmission timing.
On the other hand, each Bluetooth device is allocated a
unique 48-bit Bluetooth device address (BD_ADDR). This
address is derived from the IEEE802 standard. With this
address, Bluetooth transceivers can communicate with each
other in only one hop range. In addition to the BD_ADDR, we
define a logical address such as IP address for finding multi-
hop routes easily in networks with tree topology.
For network configuration, each node first acquires the
local information such as its addresses, which is required for
set up, and then finds its neighbors through the inquiry
procedure defined in the Bluetooth specification. Finally it
communicates with its neighbors to exchange the information
which is necessary for network configuration. The flow for the
network configuration as shown in Fig. 6 is performed by each
node in a distributed manner. The procedure for the network
configuration is summarized as follows
1) Read memory in order to acquire address and other
information which are required for set up when the power
is turned on.
2) Perform an inquiry procedure to find adjacent nodes and
save respondent node’s information which is necessary
for connection in an address table (e.g., BD_ADDR, clock
information, etc...). The inquiry procedure can be
continued until finding N adjacent nodes or for a fixed
period.
3) Page the inquired nodes one by one for connection and
exchange a packet including logical address and other
information necessary for network configuration.
S.-H. Choi et al.: An Implementation of Wireless Sensor Network for Security System using Bluetooth
4) Compare its own logical address with the received
logical address to determine the logical relationship
between them, which includes parent, child node or none,
and then save the result at the address table.
5) Sensor and relay nodes enter a power management mode
and the control node enters a standby mode to wait for an
event or paging.
Fig. 6. Network configuration flow
After the network configuration, an inquiry procedure is
periodically performed, considering that some nodes disappear
or newly appear in operating time. If there is no inquiry
response from a node which had already been inquired before,
it is considered that the node moved out from the range of the
inquiring node or malfunctions. Thus the inquiring node
performs a series of three inquiries and if there is no response,
finally removes the information of the node from its memory.
If a node which had not been inquired before is newly
inquired, the inquiring node makes a new record and pages the
new node to exchange a packet which has logical address and
other necessary information. The period for inquiring is
normally set to 5 minutes. However, since each relay or sensor
node must be connected to its parent node to operate normally,
if its parent node is not inquired, such nodes periodically
inquire every 40 seconds until their parent nodes are inquired.
In the case of a sensor node, once it finds a parent node, it
doesn’t inquire until it loses its parent node. But, it does not
matter because sensor nodes do not relay the packets from the
other nodes. It also means that sensor nodes do not perform
the inquiry procedure periodically. The sensor node needs to
perform power management, so it doesn’t inquire its parent
node until its parent node disappears. If the sensor node
inquires periodically, it consumes more power.
After all nodes go through the above network
configuration procedure, they can achieve a network
configuration based on the tree topology as shown in Fig. 7.
As the depth of tree becomes deeper, the length of logical
address becomes longer because an additional value is added
to the rear of the logical address for identification. For
239
example, as shown in Fig.7, if the logical address of the
control node is 3, the addresses of the nodes just under the
control node are something like 3.1, 3.2, and 3.x, and the value
of the nodes just under the node with the logical address of 3.1
is something like 3.1.1, 3.1.2, 3.1.x. Due to such a hierarchical
addressing scheme, we can easily find multi-hop routes in
networks with tree topology as will be explained in Section
3.C.
Fig. 7. Network Configuration
At the network configuration stage, each node exchanges
a packet with its adjacent nodes, which includes the
information necessary for network configuration such as
logical address, and compares its logical address with the
logical addresses of its adjacent nodes to find the logical
relationship between the two nodes. The relationship may
become parent or child or none and the result is saved at the
address table.
Fig. 8. Address table
For example, the address table for the relay node with the
logical address of 3.2.2.1 is shown in Fig. 8. This address table
is used for routing. It is defined using the array of structures.
The data structure for the address table is described in Section
3.E in more detail.
C. Routing
The routing of packets is a very simple matter in the
proposed system because the data packets sent by sensor or
relay nodes are always destined for the control node and a tree
topology is adopted for the network configuration. In this case,
when a senor or relay node sends a data packet, it just sends
the packet to its parent node. Similarly, the parent node relays
the packet to its parent node. In this way, the packet finally
arrives at the control node. For example, if the sensor node
with address 3.2.2.1.1 wants to send a packet to the control
node, then it first finds its parent node from the address table
and then sends the packet to the relay node with address
3.2.2.1. Then the relay node sends the packet to its parent node,
i.e., the relay node with address with 3.2.2. In this way, the
packet finally arrives at the control node. After the control
240 IEEE Transactions on Consumer Electronics, Vol. 50, No. 1, FEBRUARY 2004

node receives the packet, it can obtain the source address of
the packet from the packet header for sending an ACK packet
to the source of the packet, i.e., the sensor node with address
3.2.2.1.1. Since a hierarchical addressing scheme is used for
routing, the control node can send the ACK packet to the relay
with address 3.2 instead of the relay node with address 3.1.
After the relay node receives the ACK packet, it looks up its
address table for routing and compares the destination address
of the ACK packet with the logical address fields in its address
table. Then it finds out that the best match address is 3.2.2. It
means that the relay node with address 3.2.2 is the next hop
node for the ACK packet. In this way, the ACK packet finally
arrives at the sensor node with address 3.2.2.1.1, i.e., the node
other hand, if a retransmission attempt is abandoned in the
upper level ARQ, the sender of the lost packet just deletes the
information about the lost packet from its memory. That is, it
searches its transmitting queue which is maintained in
anticipation of retransmission and then it deletes the entry
corresponding to the ACK packet. Figure 10 shows an
example of a data transmission sequence for the network
configuration shown in Fig.7. In this case, the sender node
with address 3.2.2.1.2 sends a packet to the control node with
address 3.
Control
5
4

that sent the packet corresponding to the ACK packet. Relay Relay
3
6
Sensor Sensor Relay
7
2
Relay
: Wireless Link 1
: Data 8
Sensor Sensor
Fig. 10. Example of a data transmission sequence

Also, the packet formats used in the proposed system are

summarized in Table I. The Request and Reply packets are
used for exchanging data between two nodes after inquiry.

Table I. Packet formats

Packet Code Parameters
Request 0x01 Source address
Reply 0x02 Source address
Fig. 9. Data flow chart Message 0x03 Source address,
Destination address,
An example data flow chart for the proposed system is Sequence ID,
depicted in Fig. 9. When a sensor node detects an event, it Length,
Data [length]
changes its mode from a power saving mode to an active
mode. Then it first pages the relay node1 (i.e., its parent node) Send OK 0x04 Sequence ID
and transmits a Message packet to inform the control node of ACK 0x05 Source address,
Destination Address,
the event. Then, the packet arrives at the control node via the
Sequence ID
intermediate nodes, i.e., the relay nodes 1 and 2. When the
control node finally receives the packet through the relay
nodes, it makes a report on the event to the local security From now on, we focus on the data transmission between
control system and then transmits an ACK packet to the sensor any two nodes. In this case, the sender first pages the receiver
node to inform that it has received the Message packet for acquiring the information required for connection. But, the
successfully. When the sensor node receives the ACK packet inquiry procedure is not necessary for data transmission since
through the relay nodes, it finishes its work and then reenters it was already performed at the network configuration stage or
the power saving mode until detecting another event. the periodic inquiries. After the receiver replies to the paging
Note that we use a link level ARQ in addition to the request, the sender can transmit a packet to the receiver. In this
upper layer ARQ (i.e., end-to-end ARQ) for successful data paper, we do not consider the Scatternet of Bluetooth and thus
transmission. The Send OK packet is used for the link level each node must change its Bluetooth mode to the slave mode
ARQ while the ACK packet is used for the upper layer ARQ. from the master mode whenever it transmits a packet.
In either ARQ, the sender of the packet maintains a timer
for retransmission and waits for an acknowledgement from the D. Operation of nodes
receiver. If timeout happens, the sender retransmits the
All senor or relay nodes stay in power saving mode most
corresponding packet to the receiver. If retransmissions
of the time since these nodes must be operated without any
happen more than three times, this retransmission attempt is
external power supply for a long time. The sniff mode defined
abandoned. If a retransmission attempt is abandoned in the
in the Bluetooth specification is used for power saving. In the
link level ARQ, the sender deletes the information about the
case of a control node which is directly connected to the local
receiver of the lost packet from its memory and attempts to
security control system through the UART (Universal
find the receiver again through the inquiry procedure. On the
Asynchronous Receiver and Transmitter) interface, we do not
S.-H. Choi et al.: An Implementation of Wireless Sensor Network for Security System using Bluetooth
adopt power saving mode since it can be operated with an
external power supply. All nodes in the proposed system
operate in an event driven manner. The hardware of the sensor
is identical to the relay node and it consists of the Bluetooth
module and the on-off switch for emulating external events
such as motion detection. The software of both nodes is
operated in the CPU core in the Bluetooth module.
Most functions of the sensor and relay nodes are identical
except that the relay node has the additional function of packet
relay. If a sensor or a relay node detects an event, it changes its
mode to the active mode from the sniff mode and performs the
specific operation corresponding to the event. It then reenters
the sniff mode and waits for another event as shown in Fig. 11.
Fig. 11. Operating flow chart for the sensor or relay nodes
The operations related to the events are summarized as
follows.
z External input event (e.g., a sensor detects an invader):
We emulate this event by means of the on-off switch. The
node detecting this event makes a Message packet
corresponding to the event for reporting it to the local
security control system. To send the packet, it searches the
logical address of its parent node from the address table
and then pages the parent node to send the packet.
z Retransmission timeout events: These events are further
classified into the retransmission timeout for the link level
ARQ and the retransmission timeout for the upper layer
ARQ. We already explained the ARQ schemes in detail in
Section 3.C.
z Inquiry timeout event: This event occurs when the timer
for periodic inquiry timeouts. We also explained the
periodic inquiry procedure in detail in Section 3.B.
z Paging event: This event happens when a node is paged.
The node performs different operations as follows
according to the purpose of paging.
- If it is paged to receive a Send OK packet, then it
searches its transmitting queue which is maintained in
anticipation of retransmission. And then it deletes the
entry corresponding to the Send OK packet from the
queue since the Send OK packet means that the
transmission is successful.
- If it is the final destination of the ACK packet when it is
paged to receive an ACK packet, then it performs an
operation similar to the case in which it is paged for
receiving a Send OK packet. If it is not the final
destination, however, then it just relays the ACK packet.
241
- If it is paged when a new node wants to participate in
the network and thus requests its information, then a
packet which includes its logical address and other
information necessary for connection is transmitted to
the new node.
- If it is paged when the local security control system
wants to monitor its status, then it transmits a packet
which contains its status information.
- If it is paged due to a request for packet relay, then it
transmits this packet to the next node on the multi-hop
route. But the address of the source node is never
modified. This case happens only when it is a relay
node.
On the other hand, the control node also performs most
functions of the sensor and relay nodes. Additionally it reports
all the events received from the sensor or relay nodes to the
local security control system via the UART interface and it
checks, on demand of a system operator, the status of a specific
node.
E. Data Structure
Each node has an address table which records the logical
addresses of its adjacent nodes and other information related to
routing and link connection. Each node uses its address table to
route packets or page other nodes. It is defined as an array of
structure of addr_table_t as shown in Table II. Each field
except for f_count is updated when an inquiry is performed.
Table II. Data structure for the address table
#define MAX_TABLE_DEV 32
#define MAX_ADDR_SIZ 8
…
Typedef struct …{
U8_t log_addr[MAX_ADDR_SIZ]; // Logical Address
U8_t relation; // NONE, PARENT, CHILD
U8_t mac_addr[6]; // Bluetooth Device Address
U32_t class_dev; // Class of Bluetooth Device
U16_t clock_oset; // Clock Offset
U8_t f_count;// Count of Connection Failures
…
The log_addr field determines the maximum tree depth.
The MAX_ADDR_SIZ is set to eight as a default value; hence
the maximum tree depth is eight. The relation field defines the
relationship between its own node and its adjacent nodes as
PARENT, CHILD, and NONE. The fields such as mac_addr,
class_dev and clock_oset are used for paging. The f_count
field counts the total number of the link level retransmissions.
If its value is over the defined value, the corresponding entry
is deleted from the address table.
The data structure defined in Table III is used for the
transmitting packet. It is defined as an array of structure of
data_q_t. Each element of the array data_q corresponds to a
packet to be transmitted, and the array itself forms a queue for
the packets to be transmitted.
242 IEEE Transactions on Consumer Electronics, Vol. 50, No. 1, FEBRUARY 2004

Table III. Inputted data working queue

typedef struct … {
bool flag; // Is Data in Queue (TRUE, FALSE)
u8_t tr_count; // Retransmission Count
s32_t s_time; // Start Time
u8_t src_addr[MAX_ADDR_SIZ]; // Source Address
u8_t dst_addr[MAX_ADDR_SIZ];
// Destination Address
u8_t seq_id; // Sequence ID Fig. 12. Development board
u8_t p_type; // DATA_MSG, DATA_SIG, DATA_ACK
union { In the proposed system, since we implement the HCI
commands in the application program, it is possible for the
msg_t msg; // for Message Packet
application to drive the Bluetooth module directly without the
sig_t sig; // for Signaling Packets help of the upper layer protocols of Bluetooth such as L2CAP
ack_t ack; // for Ack. Packets and RFCOMM. But, the basic functions of the eliminated
}d; upper layer protocols which are required for reliable data
communication are implemented in the application program.
The flag field indicates whether there is any data in the By taking this approach, as previously explained, we can have
element of the array. The tr_count field is used for the upper many advantages in terms of program code size, processing
layer packet retransmission. If the tr_count is zero, the node power, memory resource and power consumption.
checks the p_type, makes a packet according to their type
(defined as union of p_type), and transmits or relays it.
The union p_type contains the data which will be the
payload of the packet to be transmitted. The msg_tmsg field in
the union is used for the Message packet. The sig_tsig field is
used for signaling packets such as the Request and Reply
packets. And the ack_tack field is used for acknowledgement
packets such as the Send OK and Ack packets.
If tr_count is larger than zero, the node considers that the
packet corresponding to the entry had been retransmitted before,
Fig. 13. Experiment environment
and so checks the s_time field which indicates how long to wait
for an ACK packet. Thus, by using s_time, the node makes a
decision whether it performs a retransmission or not. Figure 13 shows an example of our experiment
environment. PCs are connected to the nodes through the
UART interface and Multi-ICE. They are used to monitor
IV. EXPERIMENTS AND DISCUSSION
nodes and debug the source codes for each node. The PC on
In this section, we introduce our experiment environment the right hand side of the figure also plays the role of the local
for the proposed system and present experiment results. security control system. An event from a sensor node is
A. Experiment Environment relayed to the control node through relay nodes, and then it is
reported to the local security system through the UART
Figure 12 shows the development board used for the
interface. Also, an operator can send a message from the local
proposed system. It consists of a Bluetooth module, an RF
security control system to a specific node through the UART
daughter board, one UART port and a 4-bit on-off switch to
interface. When an event is reported by the control node, the
emulate external inputs. The Bluetooth module has an ARM-
local security control system informs the operator of it by
7TDMI CPU core. Our application program code and the code
means of the message displayed on screen or alarm. Figure 14
for the lower layer Bluetooth protocols are combined to make
shows an example for the monitoring result.
a single process running on the ARM-7TDMI CPU core. We
code the application program by using C language on the PC.
Since ATM-7TDMI needs a binary file, ARM cross-compiler
is used to convert the source file to the binary file. ARM Multi
ICE (Multi In Circuit Emulator) is used to download the
executable binary file from a PC to the development board. It
can read the values of registers and memories inside of the
Bluetooth module while the development board is running.
Also, we can set the values manually by using it. Thus it is
very convenient for developers.
Fig. 14. Monitoring result
S.-H. Choi et al.: An Implementation of Wireless Sensor Network for Security System using Bluetooth 243

15
14
B. Experiment Results 13

Transmission time (Seconds)

12
11
5nodes
To evaluate the performance of the implemented system, 10

9
4nodes
3nodes
we have carried out two experiments. We first measure the 8
2nodes

time taken for inquiring adjacent nodes and exchanging data 7

6
between the inquiring node and the inquired node. The time 5

consists of the inquiry time, the paging time and the data 4
3

exchange time. We measure the period from the time when the 1 2 3 4 5

inquiry procedure is initiated to the time when the data Trials

exchange is over. Figure 15 shows the result. We assume that (a) Transmission times
the inquiry procedure is performed at the network
configuration stage. In this stage, each node continuously 14

inquires for 4 seconds to find out its adjacent nodes, and then 12

Transmission time (Seconds)

it pages the inquired nodes and exchanges data with the
10
inquired nodes one by one for gathering the information which
8 Minimum
is necessary for network configuration. The result shows that Average
Maximum
the period is almost directly proportional to the number of 6

adjacent nodes. It is because the inquiry procedure is 4

continuously performed for 4 seconds regardless of the 2

number of adjacent nodes and the time for paging and 0

2 3 4 5

exchanging data takes about 0.8 seconds per each node. Number of nodes

(b) Variations of transmission times

Fig. 16. Transmission times according to the depth of tree
11
Inquiry and exchange time (Seconds)

10

9
8
7
6 system architecture, power management, self-configuration of
5 network and routing. In this paper, the tree topology has been
1 2 3 4 5 6
Number of nodes
Fig. 15. Inquiry and exchanging data times according to the number of
nodes
Second, we measure the time taken to complete the data
transmission between a sensor node and the control node. We
measure the period from the time when the sensor node sends
a packet to the time when it receives an ACK corresponding to
the packet. Figure 16 gives the result that shows how the
period is changed according to the number of relay nodes
placed between two nodes. If the number of relay nodes is two,
the number of total nodes involved is four and it means that
the depth of the tree is also four. For each case, we perform
experiments five times. As the depth of the tree increases,
more time is needed to complete the data transmission. In
addition, when adding one node, it takes about an additional 3
seconds. We think that if Scatternet can be adopted for this
implementation, these times will be dramatically shortened.
V. CONCLUSION AND FURTHER WORK
We have proposed a wireless sensor network for security
systems using Bluetooth technology. We have introduced its
7
used for network configuration and routing since it can be
considered as a natural and appropriate choice for Bluetooth
networks. Thus routing is an easy matter in the proposed
network. Also, it can give many advantages from the
viewpoint of network maintenance, controlling medium access.
Also, we have developed application programs for the nodes
which can directly drive their Bluetooth module through the
HCI interface without the help of the upper layer protocols.
Instead, the basic functions of the eliminated upper layer
protocols are implemented in the application program. By
doing so, we can fully use the limited processing power and
memory of the ARM CPU core in the Bluetooth Host
Controller.
We think that the schemes proposed can be referenced for
many other embedded Bluetooth networks. In the proposed
network, the end-to-end data transmission time is relatively
long because Bluetooth Scatternet is not considered. We leave
this issue for future work.
244 IEEE Transactions on Consumer Electronics, Vol. 50, No. 1, FEBRUARY 2004

REFERENCES
[1] Specification of the Bluetooth System. Version 1.1, February 22 2001
[2] Ian F. Akyildiz, Weilian Su, Yogesh Sankarabramaniam, and Erdal
Cayirci, “A survey on sensor networks”, IEEE Communications
Magazine, pp. 102-114, August 2002
[3] D. Kaleshi and M. H. Barton, “Ensuring interoperability in a home
networking system: A case study”, IEEE Trans. Consumer Electronics,
Vol. 45, No 4, pp. 1134-1143, November 1999.
[4] E.S. Eilley, “In-home digital networks and cordless options”, IEE Colloq.
on ATM in professional and consumer electronics, pp. 8/1-8/6, 1997.
[5] Bluetooth 2000: To Enable The Star Generation, Cahners In-Stat Group,
MM00-09BW, June 2000
[6] S. Krco, “Bluetooth based wireless sensor networks-implementation
issues and solutions,” 10th TELECOMUNICATIONS FORUM
(TELEFOR2002) NOV. 2002.
Soo-Hwan Choi received the B.S. and M.S. degrees in
Electronics Engineering from Korea University, Seoul,
Korea in 2000 and 2002, respectively. Since 2002, he has
been in the Ph.D. program in Electronics and Computer
Engineering at the same university. His research interests
include Bluetooth, wireless PAN and ubiquitous
networking.
Byung-Kug Kim received the B.S. degrees in Electronics
Engineering from Won Kwang University, Iksan, Korea
in 2002. Since 2002, he has been in the M.S. program in
Electronics and Computer Engineering at the Korea
University, Seoul in Koea. His research interests include
Bluetooth, embed Linux and sensor networking.
Chul-Hee Kang received his B.S., M.S, and Ph.D. degrees
from Wasedda University, Tokyo, Japan in 1975, 1977, and
1980, respectively. From 1980 to 1994 he was with
Electronics and Telecommunication Research Institute
(ETRI) of Korea. In 1994, he was a visiting professor at
Washington University, ST. Louis, Missouri. In 1995, he
joined the department of electronics engineering at Korea
University, where he is currently a professor. His current
research area is Internet traffic engineering, quality of service, mobile
Internet, and optical Internet.
Doo-Seop Eom received the B.S. and M.S. degrees in
Electronics Engineering from Korea University, Seoul,
Korea, in 1987 and 1989, respectively. He joined the
Communication Systems Division, Electronics and
Telecommunications Research Institute (ETRI), Korea, in
1989. He received the D.E. degree in Information and
Computer Sciences from Osaka University, Osaka, Japan,
in 1999. He was awarded a Japanese Government
Scholarship during 1996-1999 his academic years at Osaka University. From
September 1999 to August 2000, he was an Associate Professor of Wonkwang
University, Korea. From September 2000 to August 2002, he was an Assistant
Professor in the School of Electronics Engineering, Korea University, Seoul,
Korea. Since September 2002, he has been an Associate Professor in the
School of Electronics Engineering, Korea University, Seoul, Korea. His
research interests include communication network design, wireless ATM and
Internet QoS.

Jinwoo Park received the B.S. degree in electronics

engineering from Korea University, Seoul, Korea, in 1979,
the M.S. degree in electrical and computer engineering
from Clemson University, SC, in 1983, and the Ph.D.
degree in electrical engineering from Virginia Polytechnic
Institute and State University, VA, in 1987. In 1989, he
joined the Department of Electronics Engineering at Korea
University where he is now a professor. He has been in
sabbatical leave at NHK research laboratory in Japan as a visiting scholar in
1995 and Virginia Polytechnic Institute and State University as a visiting
professor in 1999. He is now serving as a director of Division of Optical
Technologies in Korean Optical Internet Forum. His research interests include
optical networks, optical Internet, and optical packet switching.