An implementation of wireless sensor network for ... - IEEE Xplore

236

IEEE Transactions on Consumer Electronics, Vol. 50, No. 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, selfconfiguration 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

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 selfconfiguration and routing. The tree topology has many advantages in that it is easy to find a multi-hop route to the

0098 3063/04/$20.00 © 2004 IEEE

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.

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 timedivision 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-tomultipoint 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. 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

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.

Sensor node

Relay node

Control node

Bluetooth module

Bluetooth module

Bluetooth module

RT UA Local security control system

Logical Communication Link

Central security control system

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 onoff switches to emulate certain events, e.g., the motion detectors in those nodes detect a movement, for convenience.

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. B. Network Configuration 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 multihop route and maintenance of nodes, but which is performed 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 multihop 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.


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.

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

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

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


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 that sent the packet corresponding to the ACK packet.

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

Relay

4

Relay 6

Sensor

Sensor

3

Relay 7

Relay : Wireless Link : Data

Sensor

8

2 1

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

Fig. 9. Data flow chart

An example data flow chart for the proposed system is depicted in Fig. 9. When a sensor node detects an event, it changes its mode from a power saving mode to an active mode. Then it first pages the relay node1 (i.e., its parent node) and transmits a Message packet to inform the control node of the event. Then, the packet arrives at the control node via the 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 control system and then transmits an ACK packet to the sensor node to inform that it has received the Message packet successfully. When the sensor node receives the ACK packet through the relay nodes, it finishes its work and then reenters the power saving mode until detecting another event. Note that we use a link level ARQ in addition to the upper layer ARQ (i.e., end-to-end ARQ) for successful data transmission. The Send OK packet is used for the link level ARQ while the ACK packet is used for the upper layer ARQ. In either ARQ, the sender of the packet maintains a timer for retransmission and waits for an acknowledgement from the receiver. If timeout happens, the sender retransmits the corresponding packet to the receiver. If retransmissions happen more than three times, this retransmission attempt is abandoned. If a retransmission attempt is abandoned in the link level ARQ, the sender deletes the information about the receiver of the lost packet from its memory and attempts to find the receiver again through the inquiry procedure. On the

Packet Request Reply Message

Code 0x01 0x02 0x03

Send OK ACK

0x04 0x05

Parameters Source address Source address Source address, Destination address, Sequence ID, Length, Data [length] Sequence ID Source address, Destination Address, Sequence ID

From now on, we focus on the data transmission between any two nodes. In this case, the sender first pages the receiver for acquiring the information required for connection. But, the inquiry procedure is not necessary for data transmission since it was already performed at the network configuration stage or the periodic inquiries. After the receiver replies to the paging request, the sender can transmit a packet to the receiver. In this paper, we do not consider the Scatternet of Bluetooth and thus each node must change its Bluetooth mode to the slave mode from the master mode whenever it transmits a packet. D. Operation of nodes All senor or relay nodes stay in power saving mode most of the time since these nodes must be operated without any external power supply for a long time. The sniff mode defined in the Bluetooth specification is used for power saving. In the case of a control node which is directly connected to the local security control system through the UART (Universal Asynchronous Receiver and Transmitter) interface, we do not


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


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 u8_t p_type; // DATA_MSG, DATA_SIG, DATA_ACK union { msg_t msg;

// for Message Packet

sig_t sig; // for Signaling Packets ack_t ack; // for Ack. Packets }d;

The flag field indicates whether there is any data in the element of the array. The tr_count field is used for the upper layer packet retransmission. If the tr_count is zero, the node 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, 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. IV. EXPERIMENTS AND DISCUSSION In this section, we introduce our experiment environment for the proposed system and present experiment results. A. Experiment Environment Figure 12 shows the development board used for the proposed system. It consists of a Bluetooth module, an RF daughter board, one UART port and a 4-bit on-off switch to emulate external inputs. The Bluetooth module has an ARM7TDMI CPU core. Our application program code and the code for the lower layer Bluetooth protocols are combined to make 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. 12. Development board

In the proposed system, since we implement the HCI commands in the application program, it is possible for the application to drive the Bluetooth module directly without the help of the upper layer protocols of Bluetooth such as L2CAP and RFCOMM. But, the basic functions of the eliminated upper layer protocols which are required for reliable data communication are implemented in the application program. By taking this approach, as previously explained, we can have many advantages in terms of program code size, processing power, memory resource and power consumption.

Fig. 13. Experiment environment

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 nodes and debug the source codes for each node. The PC on the right hand side of the figure also plays the role of the local security control system. An event from a sensor node is relayed to the control node through relay nodes, and then it is reported to the local security system through the UART interface. Also, an operator can send a message from the local security control system to a specific node through the UART interface. When an event is reported by the control node, the local security control system informs the operator of it by means of the message displayed on screen or alarm. Figure 14 shows an example for the monitoring result.

Fig. 14. Monitoring result


243

15 14

B. Experiment Results

11

5nodes 4nodes 3nodes 2nodes

10 9 8 7 6 5 4

1

2

3

4

5

Trials

(a) Transmission times 14 12 10

Minimum Average Maximum

8 6 4 2 0 2

3

4

5

Number of nodes

(b) Variations of transmission times Fig. 16. Transmission times according to the depth of tree

11

Inquiry and exchange time (Seconds)

12

3

Transmission time (Seconds)

To evaluate the performance of the implemented system, we have carried out two experiments. We first measure the time taken for inquiring adjacent nodes and exchanging data between the inquiring node and the inquired node. The time consists of the inquiry time, the paging time and the data exchange time. We measure the period from the time when the inquiry procedure is initiated to the time when the data exchange is over. Figure 15 shows the result. We assume that the inquiry procedure is performed at the network configuration stage. In this stage, each node continuously inquires for 4 seconds to find out its adjacent nodes, and then it pages the inquired nodes and exchanges data with the inquired nodes one by one for gathering the information which is necessary for network configuration. The result shows that the period is almost directly proportional to the number of adjacent nodes. It is because the inquiry procedure is continuously performed for 4 seconds regardless of the number of adjacent nodes and the time for paging and exchanging data takes about 0.8 seconds per each node.

Transmission time (Seconds)

13

10

V. CONCLUSION AND FURTHER WORK

9 8 7 6 5 1

2

3

4

5

6

7

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.

We have proposed a wireless sensor network for security systems using Bluetooth technology. We have introduced its system architecture, power management, self-configuration of network and routing. In this paper, the tree topology has been 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


REFERENCES [1] [2] [3] [4] [5] [6]

Specification of the Bluetooth System. Version 1.1, February 22 2001 Ian F. Akyildiz, Weilian Su, Yogesh Sankarabramaniam, and Erdal Cayirci, “A survey on sensor networks”, IEEE Communications Magazine, pp. 102-114, August 2002 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. 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. Bluetooth 2000: To Enable The Star Generation, Cahners In-Stat Group, MM00-09BW, June 2000 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.

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.

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.