You are on page 1of 5

Agent-based Device Management in RFID Middleware

Zehao Liu, Fagui Liu, Kai Lin


School of Computer Science and Engineering South China University of Technology Guangzhou, China se03lzh@scut.edu.cn, fgliu@scut.edu.cn, bmlinkai@gmail.com This paper proposes an agent-based device management approach in RFID middleware. We design and implement two types of agents: Control Agent and Device Agent. Through the collaboration of multiple agents, we achieve the function of device management, such as providing a set of common operating interface for RFID middleware, supporting remote configuration and grouping management of RFID devices, monitoring the real-time state of devices, dealing with unexpected events and carrying out fault-tolerant processing. In addition, we can schedule jobs for different devices dynamically to improve the system performance. The rest of this paper is organized as follows. Section 2 gives an overview of the related works in RFID device management and RFID middleware, and section 3 introduces the application of agent technology in RFID device management and gives a detailed description of Control Agent and Device Agent and discusses the implementation issues. Section 4 presents a test for the device management approach proposed in this paper. Finally, section 5 concludes with a summary of this paper and presents the future work. II. RELATED WORK

AbstractAs an important part of RFID (Radio Frequency Identification) middleware, device management has a direct impact on the stability of RFID system. This paper proposes an agent-based device management approach in RFID middleware. We design two types of agents: Control Agent and Device Agent. Control Agent manages and maintains the life cycle of each Device Agent, and coordinates the work of multiple Device Agents. Device Agent lies between the RFID middleware and the physical device. It provides a common operating interface for RFID middleware, implements remote configuration and grouping management for RFID devices, monitors the real-time state of RFID devices, deals with unexpected events, and carries out fault-tolerant processing when necessary. Through the collaboration of multiple Device Agents, we can dynamically schedule jobs for different devices to optimize the allocation of system resources. Applying agent technology in device management reduces the coupling between RFID middleware and physical devices, therefore, increases the flexibility and scalability of RFID system. Keywords- Agent; Device Management; RFID Middleware

I. INTRODUCTION As the central component of RFID (Radio Frequency Identification) system, RFID middleware is very important for the spread and application of RFID technology. RFID middleware is application-agnostic. It manages readers, filters and aggregates captured RFID data and delivers these to the appropriate consumers [1]. It is a bridge between readers and back-end applications, and resolves the complex many-tomany connectivity problems [2]. Device management is an important part of RFID middleware. RFID reader devices detect tags which attach to the items, and the tag data is delivered to RFID middleware for processing and then is sent to back-end applications. As a data collector, the RFID reader devices efficiency and accuracy of collecting tag data greatly affect the stability and reliability of RFID system. Due to the diversity and universality of RFID applications, RFID middleware has to manage the devices from different manufacturers and of different types. It increases the complexity of system development and integration and the difficulty of system maintenance if RFID middleware directly connects to various devices. How to design an efficient, stable, and reliable device management strategy is one of the key issues in the study of RFID middleware.

Several recent related works are presented here. In 2006, EPCglobal proposed a protocol for reader managementReader Management 1.0. The document defines version 1.0 of the wire protocol used by management software to monitor the operating state and health of EPCglobal compliant tag Readers. In addition, the document defines version 1.0 of the EPCglobal SNMP RFID MIB, and specifies the set of SNMP MIBII groups required to comply with this EPCglobal Reader Management Specification over SNMP [3]. Cheong et al. [4] implemented the RFID middleware system that is not only compatible with EPCglobal ALE (Application Level Events) specification but also provides various types of RFID readers spanning from passive readers to active readers. The middleware supports both synchronous and asynchronous RFID event filtering and dispatching functionalities. The RFID middleware platform is divided into three layers: Device Monitoring and Management Layer, Data Monitoring and Management Layer and Application Integration Layer. In Device Monitoring and Management Layer, Reader Agent associates with a single physical RFID reader and processes tag data delivered from readers, and

978-1-4244-2108-4/08/$25.00 2008 IEEE


Authorized licensed use limited to: National Cheng Kung University. Downloaded on February 16, 2009 at 22:20 from IEEE Xplore. Restrictions apply.

Reader Agent Manager controls individual active Reader Agents and manages the life cycle of them. Hoag et al. [5] proposed a RFID middleware architecture that uses a mixture of agent and object technologies, making each device (RFID reader, printer, camera, motion detector, forklift, conveyor belt, sensor, and so on) an agent. All agent communications occur via XML messages over UDP/IP. Agents act as wrappers or translators for their associated devices and handles only specific messages. The Sensormatic Device Commander provides comprehensive device management for RFID deployments and operations. It monitors and controls multiple reader groups to support the administration and performance needed for a complex RFID network. The system can detect, configure or restore new and failed RFID readers, and also log and forward critical alerts to a network management system [6] [7]. IBM Websphere RFID Device Infrastructure (WRDI) is part of IBM RFID middleware. WRDI is divided into three layers: Device Adapter Layer, Control Agent Layer and Enterprise Adapter Layer. WRDI supports a variety of RFID readers and other devices, locally controls devices and scenarios, supports remote deployment, configuration and management, and delivers RFID data and event to business application [8]. Bea System Inc. proposed a RFID middleware composed of RFID Edge Server and RFID Integration Server. It supports up to 12 major readers and tags of different protocols. RFID Edge Server acts as a bridge between devices and RFID Integration Server, and it controls RFID read/write devices to run in a predefined way to ensure the coordination of different devices, filters raw data according to the rule sets, drops redundant data, and delivers meaningful data to back-end information system [9]. We found that in the above works mentioned, most middleware manufacturers integrate RFID technology in their existing middleware products, for example, IBM integrates RFID technology into Websphere architecture, and Bea integrates RFID technology into Weblogic architecture. Developing RFID middleware based on the existing products takes advantages of less development work and higher technical maturity. However, it has high dependences on the existing system and increases the size of RFID middleware, so it is not conducive for low-cost and lightweight applications in small and medium enterprises. The RFID middleware architectures proposed in [4] and [5] both apply agent technology in device layer, and the agents act as functional entities to manage their associated devices and process data. But in these works, little is known about the application of agent technology and the collaboration of agents in RFID device management. In this paper, we study the application of agent technology in RFID device management, especially how to achieve complex device management tasks through the collaboration of agents, and propose a device management approach based on agent technology. In this approach, we can configure devices remotely and manage them by groups, and monitor the devices in real-time and carry out fault-tolerant processing when unexpected event occurs. Besides, we can

also schedule jobs for different devices dynamically. Overall, we achieve a more comprehensive device management. AGENT TECHNOLOGY IN RFID DEVICE MANAGEMENT Agent technology originates from the field of artificial intelligence. Nowadays, agent oriented technology has become an emerging technology in software engineering. Agents are simply software components that must be designed and implemented in much the same way that other software components are [10]. So we can make use of the autonomy and social ability of agents in RFID device management. By applying agent technology, we not only use agents to perform one-to-one management with the devices, but also carry out comprehensive management on complex device networks through the collaboration of multiple agents. In view of the characteristics of agent, we apply agent technology in RFID device management. Fig. 1 shows the architecture of device management. III.

Figure 1. Architecture of Device Management

In this architecture, we design a Control Agent and a lot of Device Agents based on JADE platform. JADE (Java Agent Development Framework) is a software development framework aimed at developing multi-agent systems and applications conforming to FIPA (Foundation for Intelligent Physical Agents) standards for intelligent agents [11]. It includes two main products: a FIPA-compliant agent platform and a package to develop Java agents. In our implementation, the agents communicate with one another on the JADE platform to achieve device management task. In this section, we give a detailed introduction to the structure and function of Control Agent and Device Agent and discuss the implementation issues. Control Agent Control Agent is the core component, which manages all Device Agents and maintains their life cycles. It issues commands to the Device Agents, receives and analyzes the reply messages, and then makes decisions accordingly. It controls the devices and makes them collaborate with each other to perform complex tasks, including remote configuration,

978-1-4244-2108-4/08/$25.00 2008 IEEE


Authorized licensed use limited to: National Cheng Kung University. Downloaded on February 16, 2009 at 22:20 from IEEE Xplore. Restrictions apply.

grouping management, carrying out fault-tolerant processing and scheduling jobs for different devices dynamically. Device Agent Each Device Agent is corresponding with a physical device. It lies between the RFID middleware and the physical device, acting as a bridge. According to the types of physical devices, Device Agent can be categorized as Reader Agent, Sensor Agent, etc. Device Agent is composed of four components. They are configuration module, monitor module, message module and data management module. Configuration module provides a common configuration interface, and executes commands related to configuration. Monitor module monitors the real-time running state of the corresponding device and notifies the abnormal events. Message module is responsible for encoding and parsing the communication messages between Device Agent and Control Agent. Data management module is responsible for data processing, such as gathering tag data, filtering tags, and smoothing tag events. By coordinating the four components, Device Agent receives commands from Control Agent and configures the corresponding device, drives the device to collect tag data and gives feedback information of device abnormality to Control Agent. A. Device Configuration Management Device configuration management is a basic function of device management. The device management approach proposed in this paper supports remote configuration and grouping management of RFID devices. The features of device configuration management are described as follows: Common Operating Interface RFID middleware has to manage devices of different types and from different manufacturers, but the APIs provided by these manufacturers are different. So it is difficult for system development and integration. Device Agent addresses this problem. It eliminates the heterogeneity of different physical devices and provides a set of common operating interface based on the APIs provided by the major device manufacturers. Due to the Device Agent, RFID middleware does not have to directly connect to various physical devices. Instead, it designates the tasks to Device Agents, which greatly simplifies device configuration procedure. Grouping Management Grouping management is carried out through the collaboration of Control Agent and Device Agents. Control Agent provides a service to store and query the basic information of all Device Agents it controls. Every Device Agent registers the information of its associated physical device to Control Agent, such as the type of the device, the area that the device is deployed in, etc. Control Agent maintains these information and searches for the specific devices if necessary. In grouping management, Control Agent searches for the devices according to their common features, groups them and sends a configuration command to the group. This function is very useful for RFID systems. If we want to change a parameter value of several devices of the same type or shutdown the devices locating in the same area, we can easily carry out such tasks by grouping management.

Remote Configuration

Remote configuration is built on two bases. The first one is the common operating interface provided by Device Agent. And the second one is the communication mode based on XML messages between Device Agent and Control Agent. Due to the capability of remote configuration, the deployment of RFID system is very flexible. A Device Agent associates with a physical device so as to perform one-to-one management. It can be distributed on a remote host that directly connects to the associated physical device, and meanwhile it communicates with the Control Agent locating at the central server. Therefore, we simply send a configuration command from the Control Agent to Device Agents to configure the physical devices without any manual interference with the remote hosts and devices. A typical example of device configuration procedure is shown in Fig. 2.

Figure 2. Device Configuration Procedure

1) In order to set the read mode of reader A and reader B to be autonomous, the Control Agent calls the configuration interface setAutoReadMode(true) that is defined by Device Agent and sends a command to Device Agent A and Device Agent B. 2) The command is sent to Device Agent A and Device Agent B as XML message stream via internet. 3) Upon receiving the messages, Device Agent A and Device Agent B each processes the XML messages by message module, and parses the command as setAutoReadMode(true). 4) Device Agent A and B each calls the specific API for its associated device by configuration module. For example, setReadMode(RFID_AUTO) and enableAutoReadMode(true) respectively to set the read mode of reader A and reader B. 5) According to the configuration results, Device Agent A and B each produces reply information, and encodes it as XML messages by message module and then sends it back to the Control Agent. 6) Upon receiving the reply messages, Control Agent checks the configuration results and then takes corresponding operations.

978-1-4244-2108-4/08/$25.00 2008 IEEE


Authorized licensed use limited to: National Cheng Kung University. Downloaded on February 16, 2009 at 22:20 from IEEE Xplore. Restrictions apply.

It is obvious that Device Agent plays a crucial role in device configuration procedure. No matter which device to configure, the Control Agent just sends the same configuration command to the Device Agents, e.g. setAutoReadMode(true) in this example, regardless of the exact type of the devices and how the devices will response to the command, and the Device Agent is responsible for the remaining work. After configuration, the information is stored as an XML file for each device for reuse. So next time when the system initiates, we can configure all the devices with their associated XML configuration files at once, greatly improving the efficiency. B. Device State Monitor To ensure the stability of RFID system, we must monitor the state of the devices. In our implementation, each Device Agent monitors the running state of its associated device, deals with unexpected events, and collects related statistical data that are useful for the health of the device, such as the accumulated amount of tags already read, the power of antennas, the latest time that a report is sent, etc. In device monitoring approach, we adopt two modes, one is subscription mode, and the other is synchronous query mode. In subscription mode, the Device Agent subscribes to its interested events. So when those events occur in the process of monitoring, a notification is sent to the Device Agent. If the Device Agent can not handle these events, it will send an alert message to the Control Agent. In synchronous query mode, when the Control Agent sends a request to query the state of the device, the Device Agent responses to the request immediately and quickly returns the related information. Besides, fault-tolerant processing can be carried out when abnormal event occurs. During device monitoring, if device fault or other abnormal event occurs, Device Agent tries to re-establish a connection with the associated device. If the problem can not be solved after several attempts, the abnormal information will be logged and an alert message will be sent to the Control Agent for further processing. If a backup device is deployed, the Device Agent will connect to it immediately and start it up to replace the failed device. It reduces the losses caused by device failure and enhances the robustness of RFID system. The monitor process is shown in Fig. 3.

C. Dynamic Job Scheduling In dynamic job scheduling mechanism, multiple Device Agents collaborate with each other, and the job of each reader device can be scheduled dynamically and separately, which greatly improves the work efficiency and the system performance. In most RFID application scenarios, a lot of RFID readers are deployed in different areas, such as the entrance and the exit in warehouse applications, to monitor the running state of these key areas. According to the predefined process, the items attached by tags pass every reader one by one, so the amount of tags read in unit time and the time a tag is read are different for the readers deployed in different areas. It consumes a large amount of system resources if the readers in different areas are always running, trying to detect the tags within their read fields frequently. Dynamic job scheduling mechanism addresses this problem. In this mechanism, Device Agents collaborate with each other under the control of Control Agent. Each Device Agent schedules jobs for its associated reader by setting the proper working time and the proper frequency of read cycles. This mechanism is described as follows: 1) Suppose that N RFID readers are deployed in an application scenario, each reader is denoted as Readeri, where i=1, 2 N, and the device agent which is corresponding with Readeri is denoted as DeviceAgenti 2) DeviceAgenti gathers statistical data according to the tag data read by Readeri, including the time each tag is read, the average time interval Ti that two consecutive tags are read by Readeri. Then DeviceAgenti sends these data to DeviceAgenti+1 periodically. 3) When DeviceAgenti+1 receives the information coming from DeviceAgenti, it compares with its own statistical data, then calculates the average time required for a tag to move from Readeri to Readeri+1, denotes it as TSi. 4) Schedule jobs for different readers according to the historical data. Set the frequency of read cycles of Readeri to Ti, indicating that Readeri reads tags once every Ti time. 5) When Readeri reads a tag, DeviceAgenti sends a notification to DeviceAgenti+1 immediately. Upon receiving the notification, DeviceAgenti+1 sets a timer according to TSi so that Readeri+1 starts a read cycle when times up. 6) Repeat step 2 to 5 until system exits. By carrying out the dynamic job scheduling mechanism, the frequency of read cycles of each reader can be tuned so that the reader starts to read tags at the appropriate time. It avoids readers to perform read cycles when no tags enter the read field, therefore, reduces the work load of the readers. IV. TEST AND ANALYSIS In order to evaluate the agent-based device management approach proposed in this paper, we design and implement a prototype system. The deployment of the system is described as follows: we use four computers PC1, PC2, PC3, PC4, and they play the role of Control Agent, Device Agent A, Device Agent B and Device Agent C, respectively. Due to the limited

Figure 3. Monitor Process

978-1-4244-2108-4/08/$25.00 2008 IEEE


Authorized licensed use limited to: National Cheng Kung University. Downloaded on February 16, 2009 at 22:20 from IEEE Xplore. Restrictions apply.

number of RFID readers and tags, we use simulated physical readers in our test. And the three simulated readers SimulateReader1, SimulateReader2 and SimulateReader3 are running on PC2, PC3 and PC4, respectively. At first, we send the configuration commands from PC1 to PC2, PC3 and PC4 according to their associated XML configuration files. The configuration procedure is very simple as described in section 3.1. We just send the commands remotely from PC1 without any manual interference with PC2, PC3 and PC4. Next, we focus on testing the dynamic job scheduling mechanism. In our testing environment, the three simulated readers SimulateReader1, SimulateReader2 and SimulateReader3 are deployed along the tags moving path in sequence. Suppose that the time required for a tag to move from SimulateReader1 to SimulateReader2 and from SimulateReader2 to SimulateReader3 are about 15 seconds and 30 seconds. In order to simulate the movement of tags in real application scenarios, we use a TagGenerator to produce tag data every 5 seconds, and the tag data is sent to SimulateReader1 immediately. Then SimulateReader1 sends the tag data to SimulateReader2 after about 15 seconds, and SimulateReader2 sends it to SimulateReader3 after about 30 seconds. In the situations without carrying out dynamic job scheduling mechanism, each Device Agent drives its associated simulated reader to read tags in a fixed frequency. Instead, if dynamic job scheduling mechanism is carried out, the Device Agent changes the polling frequency according to the real-time situations. In our test, at most 3 read cycles are performed in each polling. Table 1 shows the test result of SimulateReader2.
TABLE I. PERFORMANCE COMPARISON With dynamic job scheduling mechanism 15 min (not fixed) 359 180 50.14%

V.

CONCLUSION AND FUTURE WORK

This paper proposes an approach for RFID device management based on agent technology according to the characteristics of agents and the requirements for device management in RFID middleware. Control Agent and Device Agent are designed to achieve device management tasks. Because of the agents, RFID middleware is released from the complexity of managing various devices. In this approach, Control Agent is the core component. It manages and maintains the life cycle of Device Agents and coordinates their works. And Device Agent is another type of agent, which is composed of configuration module, monitor module, message module and data management module. It provides a common operating interface for RFID middleware, implements remote configuration and grouping management for the devices, monitors the real-time state of devices, and carries out faulttolerant processing and ensures the stability of RFID system. Through the collaboration of multiple Device Agents, the jobs of different devices can be scheduled dynamically to improve the system performance. But the application scope of the dynamic job scheduling mechanism proposed in this paper is relatively narrow. Now it can be applied in applications with stable business process. We will study the dynamic job scheduling mechanism in depth and improve the algorithm so that it can be applied in more complex application scenarios. Besides, we can extend more functions on the basis of Device Agents, such as implementing load balancing in complex reader networks by coordinating multiple Device Agents. REFERENCES

Without dynamic job scheduling mechanism Test time Polling interval Total Read Cycles Valid Read Cycles Valid Percentage 15 min 2 sec 1013 180 17.77%

As shown in table 1, it is evident that carrying out dynamic job scheduling mechanism improves the work efficiency of the reader. Without the mechanism, only 17.77% of the read cycles are valid, indicating that the reader successfully reads tags in these read cycles. But in 82.23% of the read cycles, the reader can not read any tags because no tags are in the read field. However, if we carry out dynamic job scheduling mechanism, the percentage of valid read cycle increases to 50.14%. By carrying out the mechanism, Device Agents can calculate when a tag will enter the readers read field, and drive the readers to read tags at the appropriate time. The dynamic job scheduling mechanism optimizes the allocation of reader resources and improves the system performance.

Christian Floerkemeier, Matthias Lampe, RFID Middleware Design Addressing Application Requirements and RFID Constraints, In Proceedings of the 2005 Joint Conference on Smart Objects and Ambient Intelligent: Innovative Context-aware Services: Usages and Technologies. Grenoble, France. 2005. 219-224 [2] Xiao Rongxing, Su Weiren, Xu Yujia, Neural System in RFID Applications--RFID Middleware, China Computer & Communication, September 2005 [3] EPCglobal Reader Management 1.0December 2006 [4] Taesu Cheong, Youngil Kim, Yongjoon Lee, REMS and RBPTS: ALECompliant RFID Middleware Software Platform, Proceeding of The 8th International Conference Advanced Communication Technology (ICACT), 2006, Volume 1, 20-22 Feb. 2006 Page(s):699 704 [5] Joseph E. Hoag, Craig W. Thompson, Architecting RFID Middleware, Published by the IEEE Computer Society SEPTEMBER-OCTOBER 2006 [6] Sensormatic RFID Device Commander, ADT Security Services, Inc. [7] Mark Roberti, New RFID Reader Management App, RFID journal, June 1, 2004 [8] Aldo Eisma , Building RFID Solutions with the IBM WebSphere RFID Device Infrastructure [9] BEA WEBLOGIC RFID Technical White Paper http://www.bea.com.cn/download/RFIDTechnicalWhitePaper.pdf [10] M. Wooldrige, Agent-based Software Engineering, IEE Proceedings Software Engineering Vol. 144, No. 1 , February 1997 [11] JADE PROGRAMMERS GUIDE, http://jade.tilab.com/doc/programmersguide.pdf

[1]

978-1-4244-2108-4/08/$25.00 2008 IEEE


Authorized licensed use limited to: National Cheng Kung University. Downloaded on February 16, 2009 at 22:20 from IEEE Xplore. Restrictions apply.

You might also like