Sensor Node Middleware to Support Web-Based Applications over Wireless Sensor Networks

Young-Jun Jeon, Sang-Hyun Park, Jong-Seung Park Dept. of Computer Science and Engineering

University of Incheon, South Korea {0961144, tank1862, jong}@incheon.ac.kr

Abstract—Sensor Nodes in Ubiquitous Sensor Network (USN) environments are composed of many sensors and hardware components for various purposes and applications, such as service in the industrial field, the public administration sector, and in life services. A middleware is required for wireless sensors to treat a huge amount of information from sensor nodes. However, the use of a middleware and specialized application services could be a big obstacle for the portability of heterogeneous hardware, software platforms, and various methods of information consumption. These problems can be solved by providing an HTTP interface gateway based on a standardized web platform. The web is an open standard that can perform a connecting role for different types of equipment. This article proposes a sensor node middleware to support web-based applications over a Wireless Sensor Network (WSN). We expend a WSN middleware to the web platform by providing an HTTP interface gateway. The gateway makes full duplex possible between sensor nodes and client modules. The processing results of sensor data are then presented to clients by using RIA. Our proposed middleware makes full use of the web platform’s advantages and supports a wide range of various applications. The experimental results showed that the proposed middleware efficiently manages sensor nodes, and the response time for collecting sensor data is significantly reduced.

Keywords: WSN middleware; sensor gateway; Web platform; HTTP interface gateway

I. INTRODUCTION. A Wireless Sensor Network (WSN) is a ubiquitous

technology that can be applied to various industries and life environments, such as logistics, product distribution, surveillance, and home automation. For example, a typical application, such as a fire surveillance application, collects fire-related information from sensor nodes of fire occurrences. In another example, sewage management application monitors water leakage, sewage flow, and backflow using sensors for water pressure, water level and harmful gas amounts [1]. A WSN will be a standard technology in a future information society, where mass sensor data is frequently measured and transmitted over a WSN, and the sensor middleware plays a key role with the emergence of diversified sensor application services. In addition, an ideal sensor middleware needs to include a running environment that can support and adjust diversified applications. Standardized systematic services should be supported, including data integration, control, management, and the effective use of system resource [2] [3].

A middleware should connect application programs and subordinate modules in order to collect and provide real-world information. Through the middleware, any type of sensor data can be communicated, regardless of time and place. The middleware should also provide diversified application services and it can be integrated with an existing system.

To support diversified WSN application services, several types of middleware have been developed, such as Courgar [4], TinyDB [5], SINA [6], DSWare [7], Milan [8], and Impala [9]. However, it is still difficult to resolve the limitations and conduct integrated management; consequently, diversified sensor platforms and specialized middleware application services become a stumbling block to transferability to different equipment or consumption of information. For this reason, it is necessary to standardize various sensor platforms and massive sensor data and conduct integrated management based on open-system architecture.

The problem can be resolved based on a standard web platform, since the web can serve as a contact point among different types of equipment as an open standard [10]. Such web technology is called Rich Internet Application (RIA) [11]. RIA can configure a user interface similar to desktop applications and provide asynchronous message transmission. In this regard, as an alternative to the current middleware approach, we have designed a new sensor middleware scheme by investigating the advantages of RIA to WSN middleware. Our study suggests an RIA-based web platform that provides WSN data to clients through base nodes that are installed in a data server and that can conduct two-way communication with sensor nodes. We provided a new computing environment through the replacement of classical sensor network modules with a keyboard and a mouse input device, a Web Application Server (WAS) with system bus and storage, and client web browsers with output and computation devices. As a result, the web platform is combined with sensor middleware so that the operating system, terminals, and limitations in time and place are resolved, sensor data is confirmed through the web browser, and sensor nodes are controlled.

Our study consists of the following: Chapter 2 describes a hardware platform and an operating system in the WSN and RIA/web platforms. Chapter 3 describes the application of the web platform and RIA to the proposed WSN system. Chapter 4 demonstrates our integrated design and implementation scheme and analyzes the results. Chapter 5 describes the conclusion and suggested future directions for further study.

1 This work was supported by the Brain Korea 21 Project in 2009 and by the Ministry of Commerce, Industry and Energy through the Northeast Asia e-Logistics Research Center at University of Incheon.

963978-1-4244-4487-8/09/$25.00 ©2009 IEEE

The 2nd IEEE Workshop on Wireless and Internet Services (WISe 2009)Zürich, Switzerland; 20-23 October 2009

II. RELATED STUDIES

A. Sensor node platform Unlike existing wired network terminals, sensor nodes

work on a limited computing capacity. In most cases, a low-power Micro Controller Unit (MCU) and Radio Frequency (RF) modules are used for sensor nodes. Low clock 8 bits Reduced Instruction Set Computer (RISC) CPU ATmega [12] series and ARM [13] series are used most frequently for the MCU [14]. The most widely-known Crossbow Mica series includes an Atmel ATmega MCU and a Chipcon RF module. A sensor node platform called WeC was developed for the first time in 1999; since then, several node hardwares, including Rene, dot, Mica, Mica2, and MicaZ, have been developed [15].

Our prototype platform uses two MicaZ models that include a ZigbeX by Hanback Electronics [16] and a UStar-2400 by Huins [17]. A sensor node consists of a micro-controller unit, a wireless communication chip, a sensor, and an antenna. Main hardware components are shown in Fig. 1. We also use two motor controllers, called LB1638 [18] by Sanyo, per sensor node in order to move the remote-control sensor node. A motor controller inputs two signal lines and outputs two signal lines to control the mobility of the sensor node.

B. WSN middleware A sensor network middleware is located in the middle of

high-level applications and low-level sensor network modules, and it supports flexible integration between the two layers [3]. A good middleware should support several functional properties [2]. Firstly, the middleware should consume minimal resources for basic sensing, data processing, and communication mechanism functions. Sensor node resources such as energy, computing power, memory, and communication bandwidth are strictly limited, and they need to be used effectively to provide all of the necessary functions. Secondly, the dynamic network topology can be configured without affecting the sensor network when some sensor nodes move to different positions or when new sensors are added

Thirdly, the middleware should preserve the accuracy of collected sensor data and guarantee real-time processing and transmission by dynamically configuring a common measure for time and space. The middleware should provide an integrated environment for diversified sensor node hardware and network interfaces. Finally, the middleware should support various types of sensor data, applications, and network Quality of Service (QoS).

Figure 1. Hardware components of a sensor node

The diversity includes different types of measurement and placement of sensor nodes, different service ranges of network applications, and different life spans of sensor nodes.

Sensor middleware can be functionally classified according to purposes and applications into one of the following four categories: database-based middleware, mobile agent supporting middleware, event middleware, and limited resource protection middleware [1]. According to these classifications, TinyDB regards a sensor network as a virtual database that uses an SQL-like language. However, such a middleware should preserve spanning tree-based network expansion and, hence, each query needs to be transmitted to all sensor nodes. Worse, if a new function is added, inquiries on all nodes must be revised [5]. DSWare abstracts various services in the application layer. Services such as event request, event detection, data storage, and group management are considered to be applications. Regardless of complicated low-level technologies, standard SQL is used to acquire data [7]. Table 1 shows the characteristics and limitations of several popular WSN middleware [1].

C. RIA and FLEX Traditional web applications operate on Thin-Client servers,

and all processing is handled in the server.

Clients transmit all data to the server, and processed data is responded again to all the clients. Rich Internet Application (RIA) is a web application similar to traditional desktop applications in terms of its appearance and function [11]. RIA is sometimes called X-Internet technology, in that Internet function was expanded. X-Internet aims to provide a user interface that cannot be expressed through a HyperText Markup Language (HTML). In this regard, an X-Internet solution provides a user interface engine to deal with complicated user interactions. Fig. 2 shows differences between X-Internet and RIA [19]. The RIA and X-Internet shown in Fig. 2 are similar in their implementation, but RIA can deal with multimedia, including audio and high-quality video. RIA supports asynchronous communication as well as synchronous communication using client engines.

In our proposed prototype system, we use Adobe Flex to implement RIA applications. Flash Player is a Flex client engine which is installed on many of PC. It provides much better cross-platform compatibility than other RIA technologies.

TABLE I. LIMITATIONS AND FEATURES OF WSN MIDDLEWARE

Middleware Major Feature Limitation

TinyDB (Berkeley)

Query-processing to extract information from a network of sensor devices

Yield considerable bandwidth and energy savings by reducing the amount of data

Cougar (Cornell)

Database approach in which sensor data are considered a virtual relational database

Use valuable resources to transfer large amounts of raw data to the database server

DSWare(Virginia)

Database-like abstraction adapted to sensor networks on the basis of event detection

Does not provide solutions for heterogeneity and mobility

964

Figure 2. X-Internet and RIA

Figure 3. Run-time architecture of FLEX

Flex Flash Player executes compiled binary files. Binary files are downloaded by a web browser from a server and are executed by Flash Player. There is no additional resource burden other than the download and execution of applications. Flex provides additional advantages. Subsequent data can be requested through Simple Object Access Protocol (SOAP) or Hypertext Transport Protocol (HTTP). In addition, Flex can be operated in scripting environments, including Java Server Pages (JSP) and Active Server Pages (ASP). Fig. 3 shows the Flex run-time architecture [19].

III. PROPOSED MIDDLEWARE AND APPLICATION SERVICE

A. Components of the proposed system The proposed system consists of three main parts: a

gateway per sensor node, a data server that includes a Web Application Server (WAS), and application services using RIA. To understand the entire system shown in Fig. 4, we describe the proposed system through a basic computing model. A WSN plays the source of sensor data and corresponds to input devices. The gateway module that transmits WSN data to a web server corresponds to the interface. The gateway transmits WSN sensor data to a WAS through HTTP.

Figure 4. Comparison of role and architecture of system components: our proposed model (left) and conventional computing system (right)

The WAS acts as a storage and communication controller. It stores WSN data and controls communication between the gateway and the web browser. The RIA processes WSN sensor data and outputs appropriate results. Like a computing device, our model consists of input, interface, storage and communication, and calculation and output. Communication devices such as Ethernet, LAN, and Serial Port correspond to data buses in a conventional computing device.

B. Hardware design and control of sensor nodes A ZigbeX by Hanback Electronics [16] and a UStar-2400

by Huins [17] are used to control the sensor node. We constructed two different sensor node platforms using TinyOS [20] as their operating system. In addition, wheels or legs are added to each sensor node, as shown in Fig. 5, for the mobility of the sensor nodes. Due to the mobile capability, applications can guarantee feedbacks from sensor nodes. Mobility also enables a wide range of various applications in terms of the acquisition of varying sensor locations.

1) Sensor node control program: MobileMote A mobile sensor node control program for our prototype,

called MobileMote, was developed through the use of nesC language on TinyOS. As well as basic control functions for sensor nodes, MobileMote also contains auxiliary functions to control the Light Emitted Diode (LED) panel, the timer, a RadioCRCPacket for mobile communication logics, and humidity sensors. In order to measure Receive Signal Strength Indicator (RSSI), the strength of the radio signal received, a CC2420Radio component is used.

MobileMote measures humidity, illumination, and infrared rays on a sensor node and transmits measurements through Zigbee. A TOSBase program running on a PC receives messages from MobileMote via an RS-232 port. The TOSBase can also send any messages to the mobile sensor node. Fig. 6 shows the structure of the message transmission procedure.

965

Figure 5. Two different versions of our prototype of mobile sensor node

Figure 6. Message flow between a sensor node and a WSN gateway

TABLE II. MESSAGE FORMAT OF MOBILEMOTE

Message Structure

Sync Bytes Packet Type Payload Data Sync Bytes

0 1 2...N-1 N

Payload Data

Address Message Type

Group ID

Data Length

Sensor Data CRC

0 1 2 3 4 5...N-2 N-1 N

Sensor Data

Node ID

Sequence

Temperature

Humidity

Intensity Infrared Battery RSSI

0-1 2-3 4-5 6-7 8-9 10-11 12-13 14

Command Node ID Command Type Parameter1 Parameter2

0 1 2 3

Each sensor data message sent to a PC by MobileMote includes a node ID, a message ID, a temperature measurement, a humidity measurement, an illumination measurement, an infrared measurement, and a battery measurement. Each command message sent to MobileMote from a PC includes a node ID, a command ID, and two parameter values. In a sensor node, the ADC register is checked every two seconds by a timer, and a sensor data message is formed by attaching sensor values. Table 2 shows the transmission message formats of MobileMote. The message part of TinyOS includes payload data. The address field in the payload data indicates the transmission medium when a message is transmitted. The message type field indicates a TinyOS program message type. The group ID field is a user-defined ID with a default value of 0x7D. Application developers define the sensor data. The data length field is the size of the defined sensor data. Fields of sensor data are node ID, message order, temperature, humidity, illumination, infrared, remaining battery, and signal strength. Each field of sensor data except the last one is 2 bytes. A command message includes a node ID, a command type, and two parameters. A command type is one of radio power adjustment, sleep mode control, timer adjuster, sensor node

reset, and motor controller control (forward, backward, turn left, turn right, and stop).

C. Sensor gateway program for WSN To send WSN data to the WAS, all data received through

RS-232, Bluetooth, or Universal Serial Bus (USB) should be transformed and sent into the Local Area Network (LAN) and Ethernet. In our proposed system, a sensor gateway converts the sensor data. A similar example is found in the PXA250 sensor gateway by Intel [21]. Fig. 7 shows the structure of our sensor gateway program. In the lower part of Fig. 7, there is an interface layer used to access the WSN layer, and in the upper part, there is an HTTP conversion layer. The HTTP interface layer handles communication with the WAS. The communication process starts with waiting to receive WSN data in the WSN interface layer. If a data event occurs, the received data is converted into an HTTP message. The message invokes a server push application of the WAS. The server push technology enables real-time transmission of server data to the client web browser.

Figure 7. Structure of the sensor gateway

Figure 8. Sequence diagram of two way communication

966

Our sensor gateway program connects different types of networks. The diagram shown in Fig. 8 indicates two-way communication between a web browser and the WSN.

The proposed sensor gateway system consists of two sub-gateways: an HTTP interface gateway and a WSN interface gateway. The WSN interface gateway converts raw sensor data to our standard message format to connect the WSN and HTTP interfaces. The HTTP interface gateway converts the message data to an HTTP packet format to connect the WAS and the WSN interface gateway.

1) WSN interface gateway The WSN interface gateway connects the client and the

sensor node. The gateway is an interface between the WAS and WSN. It sends byte streams from RS-232 to a web server. HTTPClient in the Jakarta Project [22] was used to send sensor data to a web server. The gateway can transmit XML documents and send hexadecimal data stream from RS-232. In addition, it embeds a HTTP server for two-way communication with a Web Application Server (WAS). The HTTP Server uses the ServerSocket class to receive byte streams. Received byte streams are transmitted to a base node through an RS-232 connector. To transmit data to a base node, a command message shown in Table 3 is created and transmitted to the base node. Several gateway attributes, such as the IP address, the host name, and the occurrence time, are also attached to the header field. The transmission procedure corresponds to Stages 2 to 3 and Stage 8 in Fig. 8. The WSN interface gateway includes a WSN interface, an HTTP client, and an HTTP server, as shown in Fig. 8. The WAS is located in the center, and a client engine (Flash player) and a web browser act as a relay.

2) HTTP interface gateway The HTTP interface gateway controls communication

between the WAS and WSN interface gateway. The gateway uses HTTPWebRequest objects and HTTPWebResponse objects provided by Microsoft .NET framework to implement an HTTP interface class. Before sending WSN data to the WAS, the WSN interface class converts byte stream data into an HTTP message format. This procedure corresponds to Stages 4 to 5 and Stage 7 of the sequence diagram shown in Fig. 8. An application for the HTTP interface gateway is implemented in .NET environment, as shown in Fig. 9. The text field labeled as Request Address accepts a web server address. Our web application is invoked, and an HTTP message data is sent to the WAS by activating the Java Message Service (JMS) [23]. The WSN data is shown in the text box labeled 1). Whenever a WSN data receipt event occurs, its data is reflected in this text box. Events occurred in the gateway program are shown in the text box labeled 2). Sensor data of each node is shown in the view area labeled 3). The corresponding sensor data is transmitted to the WAS, and all the sensor data is also available to real-time monitoring web applications. When several different types of sensors are also installed to sensor nodes, their sensor data is also shown in the view area labeled 4). The view area labeled 5) is used when transmitting a command message from a PC to a sensor node. A command message changes the mobile power of a certain node, sensing cycle or sleep mode.

TABLE III. REQUEST MESSAGE OF GATEWAY

Payload Data

Address Message Type

Group ID

Data Length Data CRC

0 1 2 3 4 5...N-2 N-1 N

RequestMessage

Gateway IP Gateway Name Current Time Payload Data

4 10 8 N

Figure 9. HTTP interface gateway

D. Establishing WAS for data archiving and communication control The WAS is located at the center of the sensor gateway and

web client network. The WAS is an internet and/or intranet environment software developed in various languages in order to handle database servers and business logics. It is located in the center of large-scale systems in enterprises and makes it easier to develop web-based distributed systems. Its middleware role is to guarantee stable transaction handling. There are several commercial WAS, such as WebLogic by BEA, WebSphere by IBM and AppServer by Blend. The Java Enterprise Edition (J2EE) is commonly used as a base technology for WAS.

Our WAS is implemented on the Apache Tomcat environment. Compared to a commercial WAS, it is too simple, but it can sufficiently handle sensor data in addition to the distribution of FLEX application. With FLEX applications, FLEX SDK needs to be distributed to the WAS to execute client applications, and LiveCycle needs to be distributed to the WAS in order for the real-time message service to use the JMS-based message service. Fig. 10 indicates the entire system components of WAS. The WAS is located between the gateway and the client Web browser. The WAS provides data transmission for various gateways and clients, and it also archives sensor data.

967

Figure 10. WAS architecture for the sensor middleware

E. RIA Implementation for WSN data processing and output In the application service layer, RIA handles the processing

of WSN sensor data. An RIA application for the WSN makes it possible to monitor sensor network layer data in the web browser on a real-time basis. It goes beyond existing web application and provides convenient interfaces, just like desktop applications.

1) Real-time message service FLEX provides the JMS-based message service to deliver

asynchronous communication via the web. A real-time message service for the WSN converts sensor network layer data into an HTTP message to transmit them on a real-time basis. Fig. 11 is a client web browser screen where a real-time service is executed.

Byte streams requested to HTTP from the sensor gateway are transmitted to a client engine through the JMS-based message service. Topic message delivery is based on the concept of producers and consumers. A producer sends messages only to consumers, and it is similar to a multicast. Messages are sent only to the web browsers executing real-time message service with RIA connected to the WAS. A JMS Producer object and Consumer object are used to implement producers and consumers, respectively. If a consumer is to receive messages from a producer, the producer channel information is required. Such message transmission technology is called Server-Push or Data-Push. The technology enables asynchronous communication and real-time asynchronous monitoring applications to be realized, as shown in Fig. 11. The graph indicates WSN sensing data from sensing nodes with sensor IDs.

2) Sensor node control in a web browser Controlling a sensor node hardware in a client web browser

corresponds to Stages 6 to 8 in Fig. 8. A user command conducts specific activities in Stage 8 according to the Zigbee message of MobileMote, a sensor node program. Stages 6 to 8 in Fig. 8 proceed as follows.

Figure 11. Real-time message of WSN to client-viewer

An HTTP command message received from the web browser is delivered to the sensor gateway through the WAS. The sensor gateway converts HTTP messages and delivers them to terminal sensor nodes.

IV. EXPERIMENTAL RESULTS AND ANALYSIS

A. WSN middleware for small internet devices We implemented an RIA web platform to provide real-time

WSN data to web clients and demonstrate sensor nodes using iPod by Apple. The portable small terminal device has a web browser and supports HTTP.

We tested two different service scenarios on our experimental middleware platform. The purpose of the first scenario was to analyze the effectiveness of the MobileMote program on our middleware platform. The process is as follows: A user enters a command on the panel screen in the client viewer to control mobile sensor-node activities. Fig. 12 shows a scene of the demonstration. A user can monitor sensor nodes through the HTTP communication and send control commands from the WAS to the sensor nodes. All the interfaces of surveillance and control are conveniently preceded on the touch panel of the small client device in Fig. 13.

Figure 12. Demonstration of sensor node control using a small internet-multimedia device

968

Figure 13. Panel screen of client-viewer for action control of mobile sensor-node

A user holding the small terminal device enters a desired sensor control command by touching the corresponding menu button. The client sends requests to the WAS through HTTP. The WAS interprets the received message and sends the command message to the gateway. The gateway transmits the message to the corresponding sensor node. Finally, the mobile sensor node conducts activities corresponding to the received command message. In our test, we issued a huge number of commands for the translational and rotational movements of sensor nodes and concluded that all the tests were successfully conducted.

The second scenario is to analyze the effectiveness of the relayed node-to-node communication. Sensor data from the WSN is transmitted to the WAS via the sensor gateway, and then the received data is transmitted to the destination sensor node via the sensor gateway again. For the experiment, we use two sensor nodes, each attached with acceleration and inclination sensors. The sensor data is used to control the movements of sensor nodes. In our scenario, if a user physically moves one sensor node, the other sensor node follows the movement of the first sensor node. The experiment was successfully conducted, and we confirmed that the proposed middleware is stable for the WSN containing various types of sensor nodes.

B. Analysis of the proposed web-based WSN middleware Our web-based WSN middleware platform shows the

ability to extend various supporting application services through the Internet connection, and it also shows the flexibility for various types of WSN. Many WSN applications can be easily developed and distributed.

We compared characteristics of our proposed sensor middleware with classical database-based middleware. As indicated in Table 4, database sensor middleware, including TinyDB, Cougar, and SINA, regards a sensor network as a virtual database and provides SQL-Like inquiry language [1]. However, the suggested system uses a standard SQL WAS database. Most conventional middleware highly depend on the types of sense nodes such as MILAN, IMPALA, and DSWare.

TABLE IV. COMPARISON OF OUR MIDDLEWARE WITH OTHER MAJOR SENSOR MIDDLEWARES

Comparison Proposed middleware Server-side, in-network sensor middlewares

Quring WSN information

-Using standard SQL on Web application server

-The whole network considered as a virtual database system -Using an SQL-like language

Haterogeneity on WSN middleware

-Using the sensor gateway integrating heterogeneous sensor network

-Each sensor network depends on the specific implementation

Separation between application service and WSN implementation

-Separating the gateway and the application to remove the dependency -Application service written in the RIA is easy to install and access

-Application services are dependent on the sensor middleware

However, in our middleware, we separated the internal middleware structure into abstract application parts and node communication parts, thereby reducing the dependency on a specific type of sensor nodes.

The proposed middleware transmits input sensor data to connected clients through the real-time message module, and the sensor data is also archived in a server-side database. Hence, when an application requests the sensor data, the WAS can immediately send the data without accessing the sensor network. As an additional merit of the proposed middleware, application services developed by RIA can easily access the sensor data and conveniently express graphical interfaces.

In the experiment, Sensor nodes use the LEACH-protocol for transmission of the message. 16 sensor nodes were placed manually on the indoor building. Consists of 16 sensor nodes is temperature, humidity sensors and mobile sensor nodes. The meaning of response time is sum of user's data request time and sensor nodes’ response time. The Step 6-8 in Fig. 8. is a user request. The Steps 2-5 in figure is a sensor response.

We compared the response time of our proposed middleware for collecting data based on SensorWeb2.0 data [24] whose purpose is to integrate heterogeneous sensor networks. The comparison of our proposed middleware with TinyDB and SensorWeb2.0 is shown in Fig. 14. There was no substantial difference in the response time after collecting sensor data. The small delay of client response time relative to SensorWeb2.0 is due to the fact that, in our case, the GUI presentation depends on Flash Player, which is the client engine of Flex. Another reason is that there is a data delay between a WAS database (Mysql in our case) and Apache Tomcat. Nevertheless, our middleware is significantly faster than TinyDB. The reason is that the suggested system does not send queries to every node like SensorWeb2.0 does; rather, it accesses the archived sensor data in the server.

969

Figure 14. Response time for collecting data: Index 1-t(TinyDB with 1 client), 1-s(SensorWeb 2.0 with 1 client), 1-o(Our system with 1 client); The index

prefix indicates the number of clients.

V. CONCLUSION Web-based services and softwares are in widespread use,

and many researchers regard the web as a promising software platform. However, WSN middleware and application services have been developed based on desktop environments. Since such desktop applications are commonly based on tightly-coupled structures related to sensor node hardware, many difficulties arise in integration, application service distribution, repair and maintenance, and management with regard to the WSN. In our proposed middleware scheme, applications are on the RIA paradigm to integrate existing WSN middleware into a web platform. As a result, application services become independent of both terminal devices and operation systems. The proposed middleware platform also provides a two-way communication for the sensor network layer and the client platform. Sensor node hardware can be controlled only by a client Web browser. Both common client terminals and small mobile internet devices can access the sensor network layer and control the sensor nodes.

However, several future studies still remain to ensure that the proposed web platform can act as a promising WSN middleware. Firstly, our web-based platform is still inclined to a server-side middleware; it needs more functional modules to cooperate with in-network middleware. Secondly, accurate time analyses of the middleware behavior should be performed. Specifically, real-time message access time and response time, which occur in numerous sensor nodes, need to be measured and analyzed. Finally, session management and security need to be considered. Our current middleware is based on the web platform and, hence, sessions might conflict if several clients concurrently access a specific sensor node. The problem can be overcome by employing secure session management.

Our web-based WSN middleware and application services will resolve limitations that occur when using different types of sensor node hardware and specific technologies. It also permits users to access the WSN more easily than desktop middleware.

In this regard, our web-based WSN environment is expected to guide future directions of WSN middleware.

VI. REFERENCES [1] S. Hadim and N. Mohamed, “Middleware: Middleware Challenges and

Approaches for Wireless Sensor Networks,” in IEEE Distributed Systems Online, Vol. 7, No. 3, 2006.

[2] E. Yoneki and J. Bacon, “A Survey of Wireless Sensor Network Technologies: Research Trends and Middleware’s Role,” Technical Report 646, University of Cambridge, 2005.

[3] S. Hadim and N. Mohamed, “Middleware: Middleware Challenges and Approaches for Wireless Sensor Networks,” IEEE Distributed Systems Online, Vol.7, No.3, Mar. 2006.

[4] P. Bonnet , J. Gehrke and P. Seshadri, “Towards Sensor Database Systems,” Proc. 2nd Int'l Conf. Mobile Data Management (MDM 01), pp. 314-810, 2001.

[5] S.R. Madden , M.J. Franklin and J.M. Hellerstein, “TinyDB: An Acquisitional Query Processing System for Sensor Networks,” ACM Trans. Database Systems, Vol. 30, No. 1, pp. 122-173, 2005.

[6] C. Srisathapornphat , C. Jaikaeo and C. Shen , “Sensor Information Networking Architecture,” Proc. Int'l Workshop Parallel Processing, pp. 23-30, 2000.

[7] S. Li , S. Son and J. Stankovic, “Event Detection Services Using Data Service Middleware in Distributed Sensor Networks,” Proc. 2nd Int'l Workshop Information Processing in Sensor Networks (IPSN 03), LNCS 2634, Springer, pp. 502-517, 2003.

[8] W.B. Heinzelman, et al., “Middleware to Support Sensor Network Applications,” IEEE Network, Vol. 18, No. 1, pp. 6-14, 2004.

[9] T. Liu and M. Martonosi, “Impala: A Middleware System for Managing Autonomic, Parallel Sensor Systems,” Proc. ACM SIGPLAN Symp. Principles and Practice of Parallel Programming (PPoPP 03), pp. 107-118, 2003.

[10] Xingchen Chu & Rajkumar Buyya, “Service Oriented Sensor Web,” University of Melbourne White Papers, August, 2006.

[11] Chris Loosley, “Rich Internet Applications: Design, Measurement, and Management Challenges,” Keynote Systems, 2006.

[12] RISC CPU ATmega, http://www.atmel.com [13] RISC CPU ARM, http://www.arm.com [14] S.M. Park, “Technical Trend of Sensor Network Node Platform & OS”,

ETRI electronic trend journal , Vol.21, No.1, pp. 14-24, 2006. [15] Crossbow sensor platform,

http://www.xbow.com/Technology/Overview.aspx [16] Hanback technical rearch center, “Ubiquitous sensor network system,”

ITC, 2007. [17] Huins electronics, USTAR-2400, http://www.huins.com/ [18] Sanyo motor controllers LB1638 datasheet,

http:// www.datasheetcatalog.com/datasheets_pdf/L/B/1/6/LB1638.shtml [19] Adobe Flex technical whitepaper,

http://www.adobeflex.co.kr /aboutflex/down/2.pdf [20] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo,

D. Gay, J. Hill, M. Welsh, E. Brewer, and D. Culler, “TinyOS: An operating system for wireless sensor networks,” Ambient Intelligence, Springer-Verlag, 2004.

[21] Intel sensor gateway, http://www.intel.com/research/exploratory/heterogeneous.htm

[22] Jakarta Project Open Source, http:// jakarta.apache.org/ [23] Richard Monson-Haefel, David A. Chappell, “Java Message Service,”

O'Reilly, 2001. [24] Xingchen Chu, Tom Kobialka, Bohdan Durnota, Rajkumar Buyya,

“Open Sensor Web Architecture: Core Services,” In Proceedings ICISIP, pp. 98-103, 2006.

970