Web based RFID Asset Management Solutionestablished on Cloud Services

Arunabh ChattopadhyayUniversity of California Los Angeles,

Los Angeles, California 90095

B. S. PrabhuUniversity of California Los Angeles,

Los Angeles, California 90095

Rajit GadhUniversity of California Los Angeles,

Los Angeles, California 90095

Abstract—In this paper, an RFID architecture has been pre-sented where the traditional role of the localised middleware hasbeen distributed to the RFID reader and a cloud based webservice supported by a web based user interface, eliminating therole of the former. Such an interface allows a user to control andcarry out all of the major RFID related operations in a typicalsupply chain based situation remotely. Load testing was carriedout to test the processing capability of the RFID reader basedReader Resident Application and the Reader Web Service forboth large scale tag traffic and large scale event generation andprocessing. Different schemes were proposed for small and largescale event processing. These results are presented to demonstratethe applicability of this architecture for multiple RFID basedoperations.

I. INTRODUCTION

RFID (Radio Frequency Identification) for the past decadehas been playing an important role in various kinds of supplychain based industrial applications such as warehousing, phar-maceutical tracking, retailing etc. An RFID system consistsof a single or multiple readers which communicate withmultiple tags by inquiring their identification (ID) [1]. Thistechnology has been widely adopted in supply chain systemsto streamline the flow of information regarding, identification,arrival/departure, status etc of objects in the system. The tagsare periodically queried by their respective readers, and inturn notify a software service/middleware of their presence orabsence so as to obtain some information which can be furtherprocessed to deliver useful services. Wal-mart had a big roleto play in the growth of RFID in the supply chain system asit mandated the incorporation of pallet level tracking of itsinventory throughout the supply chain [2].

A web service is any service that is available over theinternet, is not tied to any programming language or operatingsystem and uses a standardized XML (Extensible MarkupLanguage) messaging system [3]. One example of XML basedmessaging system is SOAP (Simple Object Access Protocol)[4]. A web service based solution provides a standard meansof inter operation between different software applications,running on a variety of platforms and/or frameworks. Cloudcomputing can be defined as applications delivered in theform of services over the internet including the hardware andsystems software situated in the datacenters that perform thoseservices [5]. The services offered are termed as Software as aService (SaaS). The datacenter with its hardware and softwareis called the Cloud.

Currently, an organization which plans to use RFID needs tohave supporting staff qualified in handling hardware, softwareissues, deployment and related aspects. Setting up an RFIDinfrastructure also needs extensive installations of enterprisemanagement systems, middleware, databases etc which gen-erally act as an obstacle for interested organizations. One canenvision that in the future, an RFID service could be likea mobile phone service, where a user can simply buy thehardware and plug it and begin using the RFID service. TheReader Web Service can be similar to the switching station.The different services available within an RFID solution can becreated and maintained by different stakeholders. As an exam-ple, the initiation service of the readers could be provided bythe manufacturers, data processing and filtration web serviceis offered by one stakeholder, database services are providedby another stakeholder and so on. This ensures that eachcomponent of the RFID solution is individually managed andoptimized by different stakeholders who have expertise in thatcomponent. Cloud based computing has been frequently citedas a favorable replacement for many types of software systemswhere the computation was previously localized. In this work,we are trying to create RFID solution for supply chain systemswith a web-service based architecture which pushes a lot ofthe traditional middleware based data processing to the morepowerful readers and to the cloud infrastructure. This allowsus to inject federation into the architecture.

II. LITERATURE REVIEW

Numerous studies have been done in analyzing and definingarchitectures for RFID based systems for various industries.These have covered various aspects of an RFID architecturesuch as data filtering, database design, RFID event processingetc. Here, we look at some works which were relevant orinspired our research. Wang et al. proposed the algorithm forcomplex event processing from primitive RFID events [6].Primitive events are typically detection of tags, whilst complexevents are the various logical and temporal combinations ofprimitive events to give achieve more meaningful activitynotifications. However, non-causal events such as notificationbased on non-activity of certain prescribed events are morecomplicated and difficult and call for creation of pseudoeventsetc. A six-layered framework for an RFID based web servicehas been proposed by Sundaram et al. [7]. The web servicecommunicates individually with RFID tags that pass through

the coupling field of readers which are controlled by the webservice and the latter shares this data with other systems thatrequire the data. Their framework addresses the problem ofintegrating heterogeneous and loosely coupled components toform a service chain. The unique aspect of their approachis the ability to integrate heterogeneous and loosely coupledcomponents to form a meaningful value chain. In their concep-tual approach, they have modelled the RFID data stream as anobject which can be further linked up and joined with a choiceof services like joining blocks. Our web based event creationinterface also allows a user to type the URL of a serviceand set its subscription to receive messages on successfulcompletion of an event. The messages could be either thetag data stream or a user pre-defined message. The choiceto send tag data or message is important as in an inter-organisational setup, organisations might prefer to not sendraw data streams to other organisations. Such a flexibility wasnot discussed in [7]. Welbourne et al. have showcased a webbased RFID tracking solution primarily for personnel in anindoor environment [8]. The main theme of their work is toattach RFID tags to certain objects which would be read by anetwork of reader antennas and their movements and locationpatterns would be recorded. These patterns can be used torecord and observe higher level events such as the detectionof a certain tag by a certain antenna signifies a certain typeof high level event and gets logged in a table. This workhas many similarities to our work such as a complete webbased access, tag metadata management by the individual userand tag data translation to higher level events. However, theirwork was primarily used for personnel tracking and the lowlevel tag movement to high level event translation was passivewhere the event was only stored and could be viewed by theuser. In an industrial supply chain based environment the lowlevel tag movement to high level event translation should beactive, i.e., it should be capable of triggering another actionsuch as informing a supervisor or starting another operation(detection of tags leading to automatic opening of gate doors)etc. Our solution has addressed these situations. Also anotherarea where our solution stands out is web based control ofreaders. Welbourne et al. had installed 44 readers in a hugebuilding with proprietary software installations and in houseservers with complete connections. We have demonstrated thatin such scenarios, one can greatly reduce the setup costs andinfrastructural requirements by using cloud computing basedresources instead of in house servers and web services tocommunicate with readers instead of localised middlewares.Also in an industrial scenario allowing reader level controlto an authorised remote user greatly improves the scope offlexibility of a system.

III. SYSTEM ARCHITECTURE

Fig. 1 shows a graphical representation of our systemarchitecture. The system architecture has four main stages.The four stages are 1) Reader resident application (RRA), 2)Reader Web Service (RWS), 3) Cloud Service (comprising ofdatabase service and a subscription based notification service)

Fig. 1. Symbolic system architecture of the proposed RFID solution

and 4) Web based Interface. As shown in Fig. 1, the RRAcollects and filters RFID tag events and transmits it to theRWS by means of a SOAP message The RWS updates thecorresponding tables in the cloud database which is the thirdstage of the system architecture and checks if there is anyremote command stored for the reader. If a command exists,then the RWS transmits the command back to the reader in theacknowledgment message. The fourth stage is the web basedinterface which displays the operational data from the clouddatabase to the client, allows the client to modify this data andcollects remote commands for the reader from the client. Thedetailed functioning of each component would be discussed indetail in the sections below.

A. Reader Resident Application (RRA)

Reader Resident Application (RRA) is a standalone soft-ware module that facilitates communication with the RWS.The application resides on a Motorola MC9090 Ultra HighFrequency (UHF) reader which runs Microsoft Windows Mo-bile 5 Operating System (OS) on an Intel 624 MegaHertz(MHz) processor. The application was created using MicrosoftVisual Studio and the Symbol Motorola Development Kit(SMDK). Usually, an RFID reader simply forwards the raw tagdata to the next upper layer for data filtering, however, usingthe RRA, we explore the possibility of reassigning some of thetasks of the upper layer to the reader itself by exploiting theRFID reader’s processing capabilities. This type of applicationcan be downloaded for any reader which can connect andbrowse over the internet. Unlike the MC9090, there are manyreaders which require the installation of middleware on ahost computer, after which, the device can be accessed. Insuch situations, the RRA stands out as it enables control andcommunication of such readers through a web based interfaceon a physically unconnected remote machine without installingany application on the machine.

1) Role of RRA: The tasks of the RRA are to collect,compile and transmit tag information to the RWS and toexecute commands received from it. One common requirementfor collecting raw reader delivered tag data is the data filtrationand compilation. The raw tag IDs collected by most readerscontain many duplicate reads. Before the tag information istransmitted to the next higher layer, it needs to be compiledand filtered to avoid redundant data transmission. Traditionally,

Fig. 2. Data model of the RFID solution

this is done by the middleware, however, this functionality isincorporated in the RRA itself. In order, for the tags to be readand compiled by the RRA, they need to be read for a certainperiod of time (sampling) before they can be compiled. Thiswill require a sampling period before the RRA compiles andtransmits the message containing all the previously read tagsto the RWS which would be called the reader report interval.Ideally, the reader report interval should be minimal to preventdata transmission delay and preserve data fidelity. However, ifthe sampling period is too small, in an industrial environment,the arrival of shipments of large quantities of tagged itemswould cause a surge of new tag events at a very high rate. Ifeach new tag detected by multiple readers is sent individuallyto the RWS at a high rate, there is a high likelihood of theserver getting overwhelmed and numerous messages beinglost or being missed. This was explained in greater detailby Chawathe et al. [9]. So sending the entire situationalinformation as a single consolidated message increases thechances of data fidelity and occupies lesser bandwidth asthe tag detection events are aggregated and hence sent lessfrequently than individual tag data packets. The compromise inthis technique would be a finite latency in transmitting new tagevents. However, for most practical supply chain operations,a finite latency would be tolerated. Also the RRA wouldhave its own processing delay in compiling the messages.However, the frequency of transmitting last read tags by theRRA to the RWS might depend on the kind of application.Some applications would require a low latency while someapplications can tolerate higher latencies and would prefer alower load on the RWS. Hence, the client can also specify

Fig. 3. Reader Resident Application (RRA) flowchart

the reader report interval in the web based interface which istransmitted to the RRA in the next message cycle and the RRAwould use that number as the reader report interval regardlessof the number of tags. There also might be situations, where,despite affording a finite latency in tag reporting by the RRA,the client would like an immediate response on the occurrenceof certain events. Examples could be to open the gate ondetection of tag A, or switch off reader B on detection oftag C etc. The RRA has a separate functionality for processingsuch events, where the client can create a rule, where the RRAshould report to the web service immediately on detection ofcertain combination of tags at certain time spans which wouldlead to a certain user defined trigger. This would be discussedin greater detail in the event processing section.

2) Data structure: Fig. 2 shows the data structure of theRRA. It maintains two data tables: A tag table and an eventstable. The tag table stores the list of tags it detected and thetime-stamp corresponding to the last time of detection. In thetag table, there are three columns, i.e. the tag ID, the timeof tag read which stores the last time the tag was read andthe tag update column. The tag update column (which is aboolean) is used to indicate if the corresponding tag has beenre-read by the RRA since the last time it was transmitted tothe RWS using a ’1’ or a ’0’. If the value is ’0’, then itmeans the tag has not been read by the reader since the lasttransmission. This ensures that only newly read tags (with tagupdate column set to ’1’) are transmitted to the web service.The events table is a datatable which contains event basedinformation that are to be used by the reader to detect theoccurrence of an event and transmit a message to the webservice. The events table consists of four columns, i.e. theevent tag (the tag to be detected), the decision time (the timebefore/after which the tag should get detected for successfuloccurrence of the event), the time logical operator (if the tagis to be detected before or after the specified time) and theevent ID. An alternate format for the events table would alsobe discussed later, where the decision time column and thetime logical operator column do not exist.

3) Sequence of operation: The flowchart shown in Fig. 3explains the cycle of operation of the RRA. When the RRAis in operation, it reads tags by default unless commanded todo otherwise. A timer runs in a parallel thread whose taskis to send the batch of last read tags to the reader every T1

seconds (reader report interval) by means of a SOAP message.Whenever the RRA reads a tag, it is listed in the tag tablewith the time of read. This time of read is updated wheneverthe tag is re-read and the tag update column is set to ’1’which indicates that this tag read needs to be a part of thenext message transmitted to the web service. When the RRAcompiles the message for the next transmission, it selects onlythose tags from the table which have a tag update column setto ’1’. Then, it compiles the last read tags since the previousread into a batch along with their corresponding time of readsand transmits it as a message. After the message transmission,the tag update column of these tags are set to ’0’. So thisenables the RRA to transmit only those tags from the tag

table which have been read after the previous transmission andhence filter out older tags, thereby eliminating data redundancyduring transmission.

4) Message structure and transmission: While transmittingdata to the RWS, the reader needs to identify itself correctly,so that the RWS can differentiate the packets sent by multiplereaders and store the data in tables corresponding to eachreader. One obvious choice for identifying each reader wasthe IP address of each reader. However, this option will notwork if multiple readers within the same intranet transmitmessages to a server outside the network as the server willfail to differentiate their addresses. The readers will send theiridentifiers in the message packet to overcome this problem.This identifier helps the RWS differentiate between differentreaders within the same network. The Media Access Control(MAC) address of the device (reader) was chosen as theidentifier as it is unique for every device. The MAC address asthe identifier of a reader might cause concern for the securityof the RFID reader and its data; however, it can be easilyreplaced by some other form of identifier such as randomnumber generator etc. The message format has been displayedin Eq. 1. The packet begins with the reader identifier shownas Rk. This is followed by the contents of the data table ofthe reader i.e. the tag ID, IDn, followed by the time-stampof the read operation. The date and time are specified in thesortable date time pattern, ”yyyy-mm-ddTHH:mm:ss”, shownas tn. This is followed by the next tag ID and so on.

SOAPMessagek = {RkID1t1ID2t2....IDntn} (1)

The RWS processes the message and retrieves any pendingcommands issued for that particular reader from the readertable in the cloud database and sends it in the acknowledgmentmessage to the reader. The reply received by the RRA typicallycontains two types of information, i.e. the reader report intervalT1 and a reader command.

B. Cloud Service

In this section, the cloud service is explained which offersthe database and event notification services for the RFIDsolution. Such a model enables the supply chain manager todistribute the system tasks to other organizations willing tohandle them as a separate service and reduce his setup timeand costs.

1) Database: A cloud based distributed database (Ama-zon SimpleDB) has been used to host our event data [10].Conventionally, this type of functionality is performed by aclustered relational database that requires an upfront invest-ment for setup and also necessitates a database administratorto maintain and administer. The database usage is chargedby measuring three quantities, viz. the amount of structureddata storage, the amount of data transfer and the machineutilization for the data operations also known as boxusage.We would be analysing the boxusage patterns for differentoperations in the following sections. In the Amazon database,tables are called domains, every row in a table correspondsto an item and every column in a row is called the attribute

of the item. The tables have been represented in Fig. 2.The database has primarily five kinds of tables: Tag tables,Reader table, Events table, User’s table and User reader linkstable. The tag table corresponds to the table created for eachparticipating reader listing their corresponding tags. The tagsdetected by the reader are represented as items.The readertable is a table listing all the readers that have communicatedwith the web service. The primary function of this table is tostore operational information corresponding to each individualreader.The event table is a table listing all the events createdby authorised users. The unique event IDs are the items of thetable. Each event has some attributes such as the associatedreader, the event rule, the event message which is to bedelivered on successful occurrence of the event, the eventexpire condition and the last event occurrence time. Finally,there are two tables, user table and user reader links whichare used for user administration. These tables are only usedby the web based user interface and are not accessed by theRWS. User table stores the username as the item and thecorresponding password and the privilege level of the user asits attributes. User reader links is a table which stores the listof associations of the users and the tag tables names (readers)that they are allowed to access. The user name is the itemwhile the tag table name is the corresponding attribute.

2) Event Notification Service: The second component ofthe cloud service is the cloud notification service. This is usedas the event notification service for the RFID system. In thisservice an event can be created. This event can be subscribedby subscribers. The subscribers could be an external URL, webservice or an email address. Any message posted on the eventby the RWS is forwarded to the subscribers. A message isposted on the event notification service by the RWS wheneverthe RWS validates a successful trigger of an event. The eventnotification service usage is also charged by measuring threequantities, viz. the number of requests made to the service,the number of notifications issued by the service and the datatransfer carried out by the service.

C. Reader Web Service (RWS)

The RWS acts as an interface between the readers andthe cloud service. It contains methods which perform threeprimary functions: 1) It accept messages from the readersto process them and store their contents to various tables inthe cloud database, 2) It executes messaging to subscribersbased on successful event triggers by posting on the cloudnotification service and 3) It retrieves and sends commandsissued by clients on the web based user interface or throughsuccessful event triggers to the readers. These three methodsare asynchronous and happen in parallel to reduce processingbottlenecks.

1) Sequence of Operation: The RWS is sitting on a hostcomputer in the World Wide Web. As discussed in the abovesection, the RRA sends the last read tags to the RWS as aSOAP message. The SOAP message when received by theRWS is processed in the following way (as shown in Fig.4): The service first extracts the reader MAC address from

Fig. 4. Reader Web Service (RWS) flowchart

the message. If the MAC address matches to a previouslyregistered reader, then the service retrieves two operationalparameters corresponding to the reader from the Reader tablei.e. 1) The reader report interval and 2) the ’pending readercommand’ issued by an authorised remote user through thebrowser interface or an earlier event (if any). These two pieces,if available, are compiled as a single message and sent backto the reader as a reply.

If the message is not empty and contains tag IDs and theirtimestamps then the RWS updates the tag table correspondingto that reader in the cloud database through a parallel thread.The name of a tag table corresponding to a particular readeris the same as the MAC address of that reader. After the tablehas been retrieved, the service extracts each tag ID and itscorresponding time-stamp from the message. If the tag IDalready exists in the table, then the service updates the ’lasttime of read’ column of the table with the latest time-stampof the tag ID, otherwise, the service adds the new tag ID tothe table and enters data for ’first time of read’, ’last time ofread’ and ’occurrences’.

D. Event Processing

1) RRA: In the previous sections, it was discussed thatthe RRA periodically sends a batch message consisting oflast read tags to the RWS. However, there might be somesituations where a finite delay might not be tolerated and aninstantaneous reaction to an event would be desired. The RRAhas a provision to detect the occurrence of such user specifiedevents. An example of an event could be the detection of tag xafter/before time t. Each time the reader reads a tag, it looks upthe events table to check if that particular tag read occurred inthe specified time range for a corresponding event ID. If thereexists a match, then the reader will instantaneously send anevent message containing the event ID and the last read tags(since the last transmission) and their times of read. The RRAcompares the tag data against the event parameters stored inthe event table as explained in the RRA section. Such eventscould act as trigger for initiating an imminent operation in the

supply chain by the RWS. Event triggered messages have anadditional keyword ”EVENT” and the event ID prefixed to themessage which enables the RWS to redirect the message to theevent processing method for processing. If multiple events arereported in a single message, then all the event IDs includedin the message separated by ’,’.

2) RWS: The RWS contains the event processing methodwhich runs in a parallel thread as shown in Fig. 4. Thismethod processes the event triggered messages sent by thereader. The event-ID number enables the RWS to retrieve theevent processing logic of the corresponding event from theevent table and perform a logical event condition check. Ifthe event condition is not satisfied, then the method ignoresit. If the event condition is satisfied, then the RWS methodsends the preset message (specified in the ’Message’ column)to the preset event subscriber by posting to the event topic onthe cloud notification service. The cloud notification servicemanages the list of subscribers subscribed to an event with aparticular event ID and simply forwards the message posted bythe RWS to the event ID which reaches all subscribers. Theevent subscriber could be a web server address or an emailaddress. After the successful trigger of the event, the RWSlogs the trigger time by updating the ’last time of trigger’column in the event table. The ’last time of trigger’ couldbe used for validating a complex event rule. The web servicewill also search if the event is a part of a complex event inthe database by searching for event rules. A complex rule is alogical and temporal combination of simple/primitive rules. Anexample of a complex rule could be if Event 1 AND Event 2occur AFTER Time t, then perform certain action. If true, thenthe web service will evaluate the occurrence of the complexevent too. An event can also have an expiry condition which isstored in the ’Expires after’ column. The value in the ’Expiresafter’ column could be either a date-time or an integer.

An event can also be created with a reader as a subscriber.This kind of an event can be used for creating automatedtriggers to command other readers on occurrence of certainevents. An example could be, after the arrival of certaintags, all the readers in the warehouse are commanded to stopreading. If the user has created a rule with an event successmessage destined for a reader, then the client interface doesnot create message topic on the cloud notification service asthe readers do not have a unique address. In this case, thereader ID of the message receiver reader is simply appendedto the event ID. This variation of the event ID allows theRWS to differentiate a rule addressed to a reader. If the eventis successful, the RWS can simply extract the reader ID fromthe rule ID and issue the event message as a pending readercommand on the reader table which would be sent to the readerin the next transmission cycle.

E. Web based User Interface

The Web based user interface is shown in Fig. 5. Thebrowser based interface acts as an interface between the remoteuser and the data stored in the cloud database (which is in turnupdated/populated by the RWS). This serves as the primary

Fig. 5. Web based interface for user

user interface to monitor, control and create all kinds of RFIDoperations by the user. This is hosted on a web server by theRFID service provider. By allowing the authorised users toaccess and view all events and controls in a web based formatremoves the need for local middleware/client installations oncustomer machines (except for an application installation onthe reader which could come factory installed) and allows themto remotely monitor and control the RFID reader’s behavior.

1) Main Page: After signing into his account, the useris usually presented the default page which shows the tagtable of the selected reader. The tag table has 4 primaryattributes/columns:- the tag ID, the last time of read, the firsttime of read and the number of times it has been read by thereader. Furthermore, the user can make modifications to thetable such as delete tags from the table, add additional columnsto the table, edit values in the additional columns etc. Oneexample of adding a column to the table could be assigningeach tag to an associated object. So the user could create anew column called ’Object’ and then enter the description ofthe object. This has been shown in Fig. 5. Remote commandscan be also sent like ”Stop Read”, ”Start Read” and changethe reader report interval. Other custom commands such as”Kill tag”, ”Write tag” can also be issued by typing on thetext box and pressing the ”Send Command” button.

The default page also acts as an interface for setting uprules for event based triggering. On pressing the ”Create eventnotifier rule”, the user is presented with the event creationpanel. In order to create a rule, the user specifies the readerfor which he wants to create the event in the text box next tothe ’Set Reader’ button. Then, the tags that should be part ofthe event are selected from the tag table list displayed in thebackground and entered. The relationships between the tagscan be set by selecting logical operators (for example, Tag AAND Tag B or Tag A OR Tag B etc). After the tags have

Fig. 6. Creating an event on the user interface

been selected, the time range within which the event shouldoccur is entered. Once the event trigger condition has been set,the event action items need to be set i.e., on the successfultrigger of the event, what kind of action needs to be taken.The action in this context involves sending a preset messageto a pre-defined subscriber. The subscriber could be an emailaddress or a web address (such as web address of a server or aweb service etc) or another reader. Some example of messagescould be to open a gate (or toggle some other type of switch ofsome device) on detection of certain tag ID or send a certaincommand to a reader (like stop read) on detection of certaintag ID etc. Finally, after setting the preset message and thesubscriber, the user needs to define the expiry condition of therule. The user can either define a date-time after which the rulewould expire or define an integer which gives the number ofsuccessful occurrences of the event after which it expires.

After the complete rule has been created by the user, theclient interface first stores the rule in the events table. Theevent table contains the columns of ’Event ID’,’Reader ID’,’Rule’, ’Message’ and ’Expires after’. The contents of thesecolumns are self-explanatory from the name of the columns aswas discussed previously. The client interface will parse theuser created rule for the above listed details and fill the tablecolumns. After registering the event rule in the events table, theclient interface would extract the tag IDs and compile each onewith the event ID and update the corresponding reader entryin the reader table by filling the ’Pending Reader Command’column to be sent to that particular reader for detecting eventsassociated with that tag. In this way, the event rule hasbeen broken down into smaller single tag rules for the lessercomputationally capable readers to identify. There are alsoother pages for managing other aspects of RFID administrationviz. a Reader management page, Events management page,User management page and History Search page.

IV. LOAD TESTING

A. Tag processing by RWS

Although this architecture works smoothly with the readersand the web service server in our lab setup, we wanted toperform load tests on the service. For this purpose, we createda program in Matlab which can generate and send SOAPpackets to simulate reader generated message traffic. In order

Fig. 7. Graph showing cloud database boxusage as a function of number oftags

to test the performance of the system, we generate SOAPmessages with the number of tag IDs per message spanningfrom 1 to 100. So the smallest message has one tag ID and itscorresponding time-stamp in the message, whilst the biggestmessage has 100 tag IDs and their corresponding time-stampsembedded in the message. The test was performed over anetwork with a speed of 54 Mbps. Fig. 7 shows the boxusageof the cloud database service as the number of tag IDs permessage increase. The red line shows the boxusage when themessage contains new tags i.e. tags that were read by thereader for the first time. The blue line shows the boxusagewhen the message contains previously read tags that were readby the reader again. The boxusage for updating previouslyread tags is high because for previously read tags, the RWShas to update the two columns of of ’last time of read’ and’occurrences’ (two update operations), however, for new tags,the RWS has to simply add a new entry (one store operation)on the tag table, the latter having smaller boxusage. The slopeof the curve for the old tags is 7.5×10−5 which means thatevery additional previously read tag in the message costs anadditional boxusage of 7.5×10−5. Similarly, every additionalnew tag contained in the received message costs an additionalboxusage of 5.3×10−5. It takes the RWS a mean of 0.43seconds (with a variance of 0.0321, sampled over 200 randommessages) to receive a message and reply back to a reader. Thisavoids a bottleneck at the reader and RWS interface, despitea longer message processing delay as the reader is not keptwaiting for the RWS to reply back. This is possible due toasynchronous message processing as explained in the RWSsection. It must also be realised that the message processingdelay of the RWS is also dependent on the internet connectionspeed as it involves frequent communication between the RWSand the cloud service.

B. Primitive Event Processing

In this part, the performance of the various componentsduring event processing would be analysed. Previously, it wasdiscussed, that for processing a primitive event, the RRAcompares the tag and its time stamp against the event conditionand if true, forwards it to the RWS for further processing. Anexample is, ”If Tag A is reader AFTER Time T then report”.When the reader is reading multiple tags, this event evaluationinvolves double comparison i.e. ID based comparison (foridentifying the event associated tag ID from the remaining tagIDs) and temporal comparison (comparing tag read timestampof the associated tag ID with event time span). However,

Fig. 8. Contour plot comparing processing delay of RRA as a function ofnumber of tags and number of events

this type of individual event evaluation could slow down amobile reader’s processor and create a bottleneck. If the RRAperforms double comparison for the event, it would be sendingthe event ID of the successful event to the RWS to simplypost the preset event message (corresponding to the event ID)to the preset destination. So, another alternate way of eventevaluation is proposed in which, the RRA simply performsan ID based comparison and forwards the tag data packet tothe RWS for performing the remaining temporal comparison.The latter technique would free up the RRA’s resources andreduce its processing time and transfer the processing loadto the RWS server processor. A detailed analysis of the twotechniques is discussed in the next part.

First, a test was carried out to measure the processing delayexperienced by the RRA as a function of tags and events. Inorder to test this, a simulated RFID driver was used to simulatetags from 1 to 100. Similarly, 1 to 100 events were sent tothe RRA to report back successful events. Fig. 8 shows twocontour plots representing the processing delay of the RRAresiding on the RFID reader as function of number of tagsand number of events. The processing delay is in milliseconds.A point on the contour plot with coordinates (x,y) shows theevent processing delay (given by the color) when the RRA hasy distinct events to track in its events table and read x tagsin a single read operation. The left box shows the processingdelay for double comparison (ID based and temporal) whilethe right box shows the processing delay for single comparison(ID based only). In double comparison, the RRA took 4.75 msto evaluate 1 successful event while reading 1 tag and having 1event and it took 4720.75 ms to evaluate 100 successful events

Fig. 9. Processing delay of the RWS processing events as a function ofnumber of events

Fig. 10. Box usage of the RWS processing events as a function of numberof events

while reading 100 tags and having 100 events. In contrast,for single comparison, the RRA took 1.5 ms to evaluate 1successful event while reading 1 tag and having 1 event and ittook 233.5 ms to evaluate 100 successful events while reading100 tags and having 100 events. Double comparison takesmore than 20 times more delay than single comparison forsuccessfully evaluation 100 events from 100 tags. The datafor the contour plot was obtained as a mean of 4 similar tests.

In the next test, the behavior of the RWS was analysed whileevaluating events. In this test, reader generated event messageswere sent to the RWS for processing. The RWS performancewas then logged to measure the processing time and box usagefor evaluating the event messages. The test was carried outfrom 1 event to 1001 events in increments of 100. Again, inthis case, two cases were studied. First case involved, doublecomparison of the event being performed at the RRA. In thiscase, the RWS fetches the preset event message from the eventtable in the cloud database and posts it to the cloud notificationservice and then, updates the ’occurrences’ and ’last timeof trigger’ columns of the former. The average processingdelay (averaged over 5 runs) is shown by the blue curve inFig. 9. The average processing delay for 1 event is 0.4875seconds, which increases to 741.6 seconds for 1001 events.The boxusage for this operation is shown by the blue curvein Fig. 10. The box usage for 1 event is 4.505×10−5, whilefor 1001 events, it is 0.06711. The RWS shows an increaseof boxusage of 6.7×10−5 for every additional event. In thesecond case, if the RRA performs only ID based comparisonand forwards the tag data to the RWS as an event message,then, the RWS needs to perform temporal comparison for theevaluation of the primitive event. The average processing delayfor this operation by the RWS is shown by the red curve inFig. 9. The average processing delay for 1 event in this case is0.4063 seconds while for 1001 events, it rises to 2702 seconds.The box usage is shown by the red curve in Fig. 10. The boxusage for 1 event is 6.683×10−5, while for 1001 events, itrises to 0.07503. The RWS consumes 7.5×10−5 additionalbox usage for every additional event. Partial primitive eventprocessing by the RRA is more 1.12 times more expensive inbox usage than full event processing by the RRA. The higherdelay and boxusage compared to the previous case is due tothe additional step of fetching the event rule from the eventtable and performing the event comparison.

Through these tests, we can conclude that for low numberof tags and higher processing delay tolerance, primitive event

processing in the RRA would be viable as it leads to lowerboxusage and hence lower costs. However, if large number oftags are involved and low processing delays are expected, thenpartial processing of the primitive event at the RWS is moreviable for an additional cost.

V. CONCLUSION

In this paper the design and implementation of an RFIDtracking solution based on web services and cloud computingresources has been shown. The emphasis was on shifting agreater part of data processing to the lower level (i.e. thereaders) and cloud resources. The ability of the readers toperform previously high level tasks and the possibility ofresources on a cloud computing platform gives it the benefitsof low setup cost and time and remote controllability, hencean increased business value. The architecture accommodatedfor both routine data processing as well as event processing.The RFID reader based Reader Resident Application and theReader Web Service were both load tested for processingnormal messages and primitive events based messages. Twodifferent mechanisms were tested for processing primitiveevents and their suitabilities explained for different types ofRFID operations.

REFERENCES

[1] K. Finkenzeller, RFID Handbook: Fundamentals and Applications inContactless Smart Cards and Identification. New York, NY, USA:John Wiley & Sons, Inc., 2003.

[2] R. Weinstein, “Rfid: A technical overview and its application to theenterprise,” IT Professional, vol. 7, no. 3, pp. 27–33, 2005.

[3] E. Cerami, Web Services Essentials, S. St.Laurent, Ed. Sebastopol, CA,USA: O’Reilly & Associates, Inc., 2002.

[4] H. F. Nielsen, N. Mendelsohn, J. J. Moreau, M. Gudgin, and M. Hadley,“SOAP version 1.2 part 1: Messaging framework,” W3C, W3C Recom-mendation, June 2003.

[5] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz,A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica,and M. Zaharia, “Above the clouds: A berkeley view of cloudcomputing,” EECS Department, University of California, Berkeley,Tech. Rep. UCB/EECS-2009-28, Feb 2009. [Online]. Available:http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.html

[6] F. Wang, S. Liu, and P. Liu, “Complex rfid event processing,” VLDB J.,vol. 18, no. 4, pp. 913–931, 2009.

[7] D. Sundaram, W. Zhou, S. Piramuthu, and S. Pienaar,“Knowledge-based rfid enabled web service architecture forsupply chain management,” Expert Systems with Applications,vol. 37, no. 12, pp. 7937 – 7946, 2010. [On-line]. Available: http://www.sciencedirect.com/science/article/B6V03-50297C4-2/2/6bcc1b5293adec94ca189b36b213f25c

[8] E. Welbourne, L. Battle, G. Cole, K. Gould, K. Rector, S. Raymer,M. Balazinska, and G. Borriello, “Building the internet of things usingrfid: The rfid ecosystem experience,” Internet Computing, IEEE, vol. 13,no. 3, pp. 48 –55, 2009.

[9] S. S. Chawathe, V. Krishnamurthy, S. Ramachandran, and S. Sarma,“Managing rfid data,” in VLDB ’04: Proceedings of the Thirtiethinternational conference on Very large data bases. VLDB Endowment,2004, pp. 1189–1195.

[10] M. T. Ozsu and P. Valduriez, “Distributed database systems: Where arewe now?” Computer, vol. 24, no. 8, pp. 68–78, 1991.