With the development of Internet of things, the number of radio frequency identification (RFID) network readers and tags increases very fast. Large-scale application of RFID networks requires that RFID middleware system can process a large amount of data efficiently, with load-balancing, efficient redundant data elimination, and Web service capabilities so that required information can be transmitted to applications with low overhead and transparency. In view of these objectives and taking especially advantages of virtualization and transparency of Cloud computing, this paper introduces an advanced RFID middleware management system (ARMMS) over Cloud computing, which provides equipment management, RFID tag information management, application level event (ALE) management, and Web service APIs and related functions. ARMMS has different focuses than existing RFID middleware in distributed design, data filtering, integrated load balance, and Web service APIs and designs all these over Cloud. The distributed architecture can support large-scale applications, integrated load-balancing strategy guarantees stability and high performance of the system, and layered and parallel redundancy data elimination scheme makes sure that needed information is transmitted to application level with low overhead; Web service APIs support cross-platform information processing with transparency to lower level RFID hardware.
Radio frequency identification (RFID) middleware plays an intermediary role between systems. Therefore, the upper-layer applications can add and delete contents or even be replaced by other software without the need to make any changes to the middleware; similarly, the underlying types of RFID readers can increase and decrease its various hardware and software operations; the upper layer does not need to make any changes. Therefore, RFID middleware can eliminate the need of many to many connections and reduces operating costs.
Figure
EPCglobal standards architecture [
As shown in Figure
RFID middleware organization [
Figure
A networking example of RFID networks.
When designing an RFID middleware solution, the following issues need to be considered [ Multiple types of hardware and vendors support: the middleware must provide a common interface to Real-time handling of incoming data from the RFID readers: the middleware should Interfacing with multiple applications: the middleware should be capable of Device neutral interface to the applications: the application developer should only Scalability: the middleware design must allow easy integration of new hardware and International standards compliant: the middleware design should follow international standards such as EPCglobal so that other related RFID hardware and software can also comply to the standards to make networking easier.
In view of these and taking especially advantages of virtualization and transparency of Cloud computing, this paper introduces an advanced RFID middleware management system (ARMMS) over Cloud computing, which provides equipment management, RFID tag information management, application level event (ALE) management, and Web service APIs and related functions. ARMMS has different focuses than existing RFID middleware in distributed design, data filtering, integrated load balance, and Web service APIs over Cloud.
proposing an RFID middleware architecture over Cloud computing including live migration; proposing a layered and parallel redundant data removal mechanism; introducing an integrated load-balance mechanism for RFID middleware; introducing Web service APIs to support cross-platform operation and information processing to improve transparency of RFID middleware to lower level hardware and software.
The rest of this work is organized as follows: Section
In this section, we mainly introduce related researches on general introduction, related standards, redundancy removal, and load balance of RFID middleware design. There are several surveys in the literature [
There are many researches on RFID middleware design. Reference [
Some researches on redundant data removal are as follows. Reference [
Many researches on load balance of RFID middleware have been conducted. Reference [
Figure
Proposed ARMMS middleware architecture.
ARMMS has a very clear hierarchy from bottom to up as shown in Figure
The structure of ARMMS.
Messaging in distributed ARMMS.
Edge server is made up of two types of backend applications, RFID Edge server and Monitor process. RFIDEdgeserver is responsible for providing message queues and collecting and distributing messages. An Edge server runs only one RFID Edge server process. Monitor backend process is the only object calls a specific RFID device API, one per type of RFID device. It uses an internal communication protocol to communicate with RFID Edge server. For a specific type of RFID device, a monitor process should be implemented. So, if we want to extend this middleware system to support a new type of RFID device, we should implement a new monitor process with the new device’s API and internal communication protocol. Figure
Structure of proposed Edge server.
The main function of the monitor backend process includes the following. Calling the corresponding RFID devices’ API and obtaining the tag data in the reading range. Monitoring the RFID devices connected with Edge server in real time and sending the error reports to Center Node (management center). Sending TagDetected message to the RFID Edge server process when a tag data is arrived.
RFID devices from different manufactures apply different API calling mechanisms. If middleware system calls the API directly, the scaling ability will undoubtedly become very poor. Applying support for new type of RFID device will lead to recompiling the source code. Despite operation mechanisms for reading and writing varying from one type of device to another, it is easy to find that they obtain tag data in a similar way. Edge server real-time tag algorithm is designed for the hardware abstract layer and implementing first level (reader level) redundant data elimination. We allocate a real-time tag cache for each RFID device object in the monitor thread, the real-time algorithm is responsible for assuring the tag data in the cache is in the device reading/writing range.
The requirements of central management node are in ECSpec and formatted as xml document. ALE server will transform the xml document to ECSpec object in memory when it gets the ALE requirement from central management node and initial an ECSpecUnit object with data in ECSpec to handle the requirement. The ECBoundarySpec part in ECSpec defines the ALE executing arguments, like recycle reading time, reading trigger, and so forth. The ECReportSpec part defines the report feeding back, like tag filtering pattern, grouping pattern, and so forth. So, the ECSpec is the only input in the ALE middleware system, it includes all the arguments, which are needed in ALE executing mechanism. There is a timer in the ECSpecUnit object. ALE mechanism is all depending on this clock. The ALE server flowchart is provided in Figure
Flowchart of ALE server process executing.
The center node includes backend process and soap process. Soap process is responsible for communication with the RFID application who calling the middleware API. The relevant standard is “ale_1_1_1-standard-XML and SOAP bindings-20090313.” Backend process is responsible for the load balance of the RFID device connection to Edge server. The Edge server load balance is shown in Figure
Edge server load balance mechanism.
Figure
Data redundancy in RFID networks.
When the reader gets an accurate reading of data to obtain object information on a tag, multiple times of same tag information can be read within a short period, so that redundant tags are generated.
Many readers are often densely installed to cover the entire region, and these readers’ reading range may overlap with nearby readers (as shown in Figure
Different logical groups can be formed by functionality or location differences. When two or more adjacent logical groups read the same tag information in the overlap region, redundant (repeating) tags information can be obtained. Redundancy of a reader and between readers cannot be completely removed because of locality view, this is shown as the redundancy elimination percentage in [
Proposed MapReduce flowchart.
Workloads of RFID middleware can change from location to location and can vary at different times. There is an urgent need to provide dynamic and integrated load-balancing solution to manage RFID network and serve upper layer applications. In our proposed model, the Edge server load-balancing module is responsible for monitoring the load on the Edge server and dynamic adjusting connections between Edge servers and RFID reader devices.
Reference [
Definition of RFID middleware load [
Load-balancing strategy in [ Average utilization of CPU and memory of each middleware:
Integrated load imbalance level of middleware Average imbalance level of host servers equals to the sum of imbalance levels of all servers divided by the number of hosting servers:
In (
Integrated load balance considers factors including CPU utilization, memory utilization, and network bandwidth utilization, which can be expanded.
Live migration of middleware by virtual machines.
Through extensive numerical examples, we find that this dynamic and integrated load-balancing mechanism achieves lower average and a total imbalance level than traditional load-balancing strategies such as Round-robin and the one introduced in [
In order to provide convenient management and service, Web service APIs are necessary. It has an interface described in a machine-processing format (e.g., WSDL format). Other systems can interact with the Web service APIs in a manner prescribed by description using messages, conveyed using HTTP with an XML serialization.
Figures
Logical view of RFID readers.
Physical RFID readers.
Tag data information.
ALE management.
Some Web service APIs.
For the performance evaluation, we have the following configuration: Edge server
The configuration of Edge servers.
Edge server | CPU (GHz) | MEM (GB) | CPU (UB) | MEM (UB) |
|
---|---|---|---|---|---|
|
1.5 | 1 | 0.7 | 0.7 | 5000 |
|
2 | 1.5 | 0.7 | 0.7 | 10000 |
|
2.5 | 2 | 0.7 | 0.7 | 20000 |
|
3 | 2.5 | 0.7 | 0.7 | 30000 |
Utilization information before load balancing.
Edge server | CPU utilization (%) | MEM utilization (%) |
---|---|---|
|
34 | 37 |
|
42 | 46 |
|
70 | 78 |
|
26 | 28 |
Utilization information after applying our load-balancing mechanism and method in [
Edge server | CPU (%) [ |
MEM (%) [ |
CPU (%) ARRMS | MEM (%) ARRMS |
---|---|---|---|---|
|
34.0 | 37.0 | 34.0 | 37.0 |
|
82.0 | 91.0 | 42.0 | 46.0 |
|
50.0 | 55.0 | 50.0 | 55.0 |
|
26.0 | 28.0 | 39.0 | 43.0 |
|
0.12 | 0.01 |
Table
Data format of an RFID tag.
Field | Device ID | EPC code | Timestamp |
---|---|---|---|
Bits | 2 | 28 | 14 |
Taking a tag “003000C2001602200001457FFC000420110627172133” as an example: bit 0-1-00 is the device number of a tag, which has length 2; bit 2-29-3000C2001602200001457FFC0004 are tag’s EPC code, whose length is 28 bits; bit 30-43-20110627172133 is the information of timestamp of a tag, 20110627 is the date, 172133 is the time, and the length of the time is 14 bits.
First, we define data redundancy based on the following RFID data model [ Label Label EPC codes are the same, that is EPC Reader The difference between Timestamp
Redundancy elimination example using MapReduce.
The process of parallel MapReduce redundancy data elimination can be summarized as follows (see [ In Map phase, the data structure Tag consists of three variables: Reader ID, EPC, and Timestamp. According to the definition of tag redundancy, if two tags are redundant, their Reader IDs and EPC codes must be the same, and if one of them is different, the two tags are not redundant tags. Input RFID tags are divided into different blocks and assigned to hosts of Hadoop clusters. Reader ID and EPC codes are Keys and timestamps are outputs as Values to form (Key, Value) pairs in MapReduce model. In this case, that is, Key is (Reader ID + EPC), while Value is Timestamp. After simple sorting based on the Key, Map (mapping) outputs of each host are transferred to Reduce. Reduce stage: based on outputs of Map stage, it compares values of each group of Key Value (calling time comparison function), and if they are less than constants Working nodes (hosts) in MapReduce cluster summarize
As for evaluation, set the total number of RFID tags is
Times spent for Hadoop cluster to eliminate redundancy.
Number of tags | Cluster size | ||||||
---|---|---|---|---|---|---|---|
1 server | 2 servers | 3 servers | 4 servers | 10 servers | 15 servers | 20 servers | |
30 | 4 sec | 7 sec | 7 sec | 7 sec | 7 sec | 7 sec | 7 sec |
50000 | 5 sec | 8 sec | 7 sec | 7 sec | 4 sec | 2 sec | 1 sec |
500000 | 16 sec | 18 sec | 14 sec | 12 sec | 6 sec | 3 sec | 2 sec |
1.2 million | 33 sec | 24 sec | 22 sec | 19 sec | 10 sec | 6 sec | 3 sec |
45 million | 52 min | 48 min | 42 min | 41 min | 21 min | 11 min | 5 min |
Figure
Tag lost ratio comparison.
Average process time comparison.
In this paper, a distributed and messaging RFID middleware design is proposed. ARMMS provides equipment management, RFID tag information management, application level event (ALE) management, and Web service APIs, and so forth, functions. For the equipment management, ARMMS provides real-time monitoring and load balancing of multi-site RFID devices also logical grouping of RFID readers. For tag information management, it provides filtering and statistical reports. ARMMS also provides Web service APIs based on EPCglobal standards. We are conducting more experimental tests and comparing different load-balancing strategies with proposed one. There are still several research directions awaiting further investigation. Considering distributed redundancy data elimination: when facing large-scale distributed applications, distributed redundancy data elimination other than parallel method should be investigated further, and elimination efficiency should be quantitatively evaluated. Considering real-time data allocation and evaluating further live migration costs and load balancing: real-time data allocation among different middleware (host Edge servers) causes a new challenge for load balance and should be considered further. Also, the live migration costs in time and other respects should be included to provide a complete view for load balance so that decision makers can have comprehensive information. Providing more comparative results against existing methods: currently, there is still difficulty to repeat some of the existing methods such as in [
This research is supported by the National Natural Science Foundation of China (NSFC) (Grants nos. 61150110486, 61034005 and 61272528) and by China Postdoc Funding (2011-2012).