SMART DEVICE VIRTUALIZATION: BUILDING AN LLRP RFID READER EMULATION TOOL
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
SMART DEVICE VIRTUALIZATION:
BUILDING AN LLRP RFID READER EMULATION TOOL
SMART DEVICE VIRTUALIZATION:
BUILDING AN LLRP RFID READER EMULATION TOOL
A thesis submitted in partial
fulfillment of the requirements for the degree of
Master of Science in Computer Science
By
Kyle Neumeier
Bachelor of Science in Computer Science
University of Arkansas, 2006
May 2008
ABSTRACT
As businesses strive to make themselves more competitive by becoming
increasingly data-driven, they rely on new technologies to capture and analyze data
around their operational processes. Radio Frequency Identification (RFID) is one such
technology currently being investigated by a broad range of industries for this purpose.
In order to lower the cost of adoption of RFID for businesses, RFID hardware and
software vendors as well as the businesses themselves often push for industry standards.
One such standard recently ratified by EPCglobal – the Low Level Reader Protocol
(LLRP) – aims to specify a common interface between readers and clients. The LLRP
specification by itself, however, is not enough for businesses to benefit from the standard;
emulation and simulation tools that allow IT professionals and software developers to
experiment and digest the specification can go a long way to help them make better and
more informed purchasing decisions. This paper introduces the Rifidi Emulator virtual
LLRP reader – an open source software tool that implements the LLRP specification.
The LLRP reader is built on an extensible emulation architecture and can serve as a basis
for higher level simulation tools.
This thesis is approved for recommendation to the Graduate Council.
Thesis Director:
____________________________________
Dr. Craig Thompson
Thesis Committee:
___________________________________
Dr. Amy Apon
____________________________________
Dr. Dale Thompson
THESIS DUPLICATION RELEASE
I hereby authorize the University of Arkansas Libraries to duplicate this thesis when
needed for research and/or scholarship.
Agreed
________________________________________
Refused ________________________________________
vi
ACKNOWLEDGEMENTS
First and foremost, I would like to thank my advisor, Dr. Craig Thompson for all
the time, support, and advice he has given me over the last several years which has meant
a great deal to me. I would also like to thank my thesis committee, Dr. Amy Apon and
Dr. Dale Thompson for their time reading and reviewing this thesis. I also acknowledge
the folks at Pramari, especially Prasith Govin and Brian Pause, for their financial support,
leadership, and technical advice in completing this project, as well as Andreas Huebner
for listening to my ideas and telling me when I was wrong. Finally I’d like to thank my
parents for their continuous support and encouragement, which opened up so many doors
for me.
vii
TABLE OF CONTENTS
1. Introduction .................................................................................................................... 1
1.1. Problem ......................................................................................................................... 1
1.2. Objective ....................................................................................................................... 3
1.3. Approach ....................................................................................................................... 3
1.4. Potential Impact ............................................................................................................ 4
1.5. Organization of this Thesis .......................................................................................... 5
2. Background ..................................................................................................................... 6
2.1. Key Concepts ................................................................................................................ 6
2.1.1. RFID ....................................................................................................................... 6
2.1.2. LLRP ...................................................................................................................... 9
2.1.3. Rifidi Product Suite ............................................................................................. 16
2.2. Related Work .............................................................................................................. 19
2.2.1. Other Simulation Tools ....................................................................................... 19
2.2.2. LLRP Toolkit ....................................................................................................... 21
3. Architecture .................................................................................................................. 23
3.1. Development of Rifidi ................................................................................................ 23
3.1.1. Preexisting Components ..................................................................................... 23
3.1.2. Extensions by the Author .................................................................................... 24
3.2. Overview of Rifidi Architecture ................................................................................ 25
3.2.1. Server Manager.................................................................................................... 27
3.2.2. Reader Manager ................................................................................................... 28
viii
3.2.3. Client Callback Manager .................................................................................... 28
3.3. Engine Architecture .................................................................................................... 28
3.3.1. Communication Layer ......................................................................................... 30
3.3.2. Message Processing Layer .................................................................................. 33
3.3.3. Radio Layer.......................................................................................................... 34
3.3.4. GPIO Layer .......................................................................................................... 37
3.4. LLRP Architecture ..................................................................................................... 40
3.4.1. LLRP Messages ................................................................................................... 41
3.4.2. Connection Mode ................................................................................................ 43
3.4.3. Reader Operation ................................................................................................. 45
3.4.4. Access Operations ............................................................................................... 52
3.5. Lessons Learned: Modeling Future Virtual Devices ................................................ 53
4. Implementation and redesign Iterations .................................................................. 55
4.1. Open Source Licensing .............................................................................................. 55
4.2. Iteration 1: Basic Command Support ....................................................................... 55
4.3. Iteration 2: Improved Triggering and Notification .................................................. 56
4.4. Iteration 3: Access Command Support..................................................................... 57
4.5. Iteration 4: General Purpose I/O ............................................................................... 58
4.6. Iteration 5: Suspend/Resume Functionality ............................................................. 58
4.7. Iteration 6: Unit Tests ................................................................................................ 60
4.8. Deployment and Feedback ......................................................................................... 61
5. Conclusions ................................................................................................................... 63
5.1. Summary ..................................................................................................................... 63
ix
5.2. Contributions............................................................................................................... 63
5.3. Future Work ................................................................................................................ 64
6. References ..................................................................................................................... 67
x
LIST OF FIGURES
Figure 1. The structure of an LLRP Message (from [16]).................................................. 10
Figure 2 A typical timeline for an LLRP session (from [17]) ............................................. 12
Figure 3 A UML class diagram showing the structure of a ROSpec parameter ................ 13
Figure 4 A state diagram showing ROSpec transitions (from [16]) ................................... 14
Figure 5 A flowchart showing how an AISpec is executed (from [16])............................. 15
Figure 6 Screenshot of Rifidi Emulator ................................................................................ 17
Figure 7 Screenshot of Rifidi Designer ................................................................................ 18
Figure 8 Screenshot of Rifidi Tag Streamer ......................................................................... 19
Figure 9. A diagram depicting the how RMI is used in Rifidi. .......................................... 26
Figure 10. UML Class diagram of Server Manager............................................................ 27
Figure 11. UML Class diagram of Reader Manager ........................................................... 28
Figure 12. UML Class diagram of Callback Manager ........................................................ 28
Figure 13. A high level diagram of the virtual reader as a command processor ............... 29
Figure 14. A high level diagram of a Rifidi virtual reader ................................................. 30
Figure 15. A UML Class Diagram of the StreamReader.................................................... 32
Figure 16. A UML Diagram showing the Protocol interface ............................................. 33
Figure 17. A UML Diagram showing the CommandFormatter interface ......................... 34
Figure 18. A UML Class diagram depicting the radio layer .............................................. 35
Figure 19. A UML Class diagram of the antenna ............................................................... 36
Figure 20. A UML Class diagram showing the Radio........................................................ 36
Figure 21. A UML Class diagram of the tag memory interface ........................................ 37
xi
Figure 22. A UML diagram depicting the GPIO Layer ...................................................... 38
Figure 23. An example of a GPI event. ............................................................................... 39
Figure 24. How the LLRP Toolkit is used in the LLRP Virtual Reader ........................... 43
Figure 25. The connection layers of a non-LLRP reader ................................................... 43
Figure 26. The connection layers of an LLRP reader ......................................................... 45
Figure 27. A UML class diagram depicting the ROSpecController class. ............... 48
Figure 28. A UML class diagram depicting the ROSpecExecutor Class .......................... 49
Figure 29. A table enumerating the triggers and their uses ................................................ 49
Figure 30. A UML Class diagram depicting the triggering mechanism used in the virtual
LLRP Reader .................................................................................................................. 51
Figure 31. A UML Class diagram showing the RFID tag classes in Rifidi ...................... 53
1
1. INTRODUCTION
1.1. Problem
As businesses strive to make themselves more competitive by becoming
increasingly data-driven, they rely on new technologies to capture and analyze data
around their operational processes. Radio Frequency Identification (RFID) is one such
technology currently being investigated by a broad range of industries for this purpose.
RFID technology enables businesses to identify and track every individual inventory item
by labeling the item with a unique tag, periodically scanning the tag with RFID readers
strategically placed at key locations throughout a supply chain. The information
generated from the readers as the items move through a process can help businesses gain
a deeper understanding of how their processes work, and more importantly, how they can
be streamlined.
Despite the costs of RFID deployment falling [1], there is a high overhead
involved in implementing an RFID system. First, there is the cost of the hardware and
software infrastructure: RFID implementations involve buying and deploying RFID
hardware including readers and tags, and the readers must be connected to networks by
communications and middleware to collect, route, and analyze the tag reads and connect
the resulting information back to enterprise software that tracks item inventories as
tagged items move through the supply chain. After the infrastructure is purchased, the
employees must be trained and business processes must be reengineered and optimized.
Forrester Research believes this integration and business process reengineering cost can
often be even higher than the cost of the hardware and middleware technology itself [2].
In addition, RFID implementations are anything but off-the-shelf solutions. Because
2
readers have a physical aspect to them, environmental issues, antenna configuration, and
tag placement on the item all affect the accuracy of the reads [3]. Finally, due to a lack
(until very recently) of RFID reader and middleware standards, RFID deployments often
involved custom programming tailored for a particular use case [4]. In short, RFID
technology is not a silver bullet. For it to be a significant return on investment, the
implementation must be well planned and executed [5].
As the market around RFID matures, standards are needed around certain aspects
of hardware and software in order to make products interoperable and ultimately to drive
business. EPCglobal [6], the leading standards body for RFID-related technology,
recently ratified a new standard called Low Level Reader Protocol (LLRP) that specifies
the interface between an RFID reader and a client [7].
Even if the LLRP standard becomes widely accepted, there is still a considerable
need to know how to deploy readers throughout installations. One method of alleviating
the cost of deployment of RFID systems is to use modeling tools to simulate processes.
Simulation enables business analysts and IT professionals to gain experience working
with RFID-enabled processes without bearing the heavy cost of hardware and software
and helps to prevent the even greater cost of a non-useful deployment. A useful
simulation tool will not only allow business analysts and engineers to develop more
efficient processes but also allow IT professionals to learn the particular syntax,
semantics, and capabilities of potentially useful hardware and software. In this way, a
company can make a more informed decision about what combination of hardware and
software is useful when the time comes to make the purchase.
3
As more companies become interested in LLRP, a simulation tool with LLRP
capabilities will enable businesses to curb the cost of RFID adoption by allowing their IT
staff, business analysts, and engineers to gain an edge by familiarizing themselves with
LLRP before investing in hardware.
1.2. Objective
The objective of this thesis is to describe the design and software implementation
of a virtual device that emulates an RFID reader (physical device) that obeys the new
ECPglobal standard Low Level Reader Protocol (LLRP) interface specification. Such a
device will be useful in simulating RFID scenarios. A secondary objective is to
document how techniques used to build the LLRP emulator can be generalized to build
emulators for a broad class of smart devices.
1.3. Approach
Pramari LLC is an RFID software and consulting company that aims to lower the
barrier of entry for companies into RFID technology through the use of simulation tools.
Their open source software suite – called Rifidi – is currently made up of three products:
a 3D modeling tool called Designer, a load testing tool called Tag Streamer, and an RFID
reader emulation and development tool called Emulator. The virtual LLRP reader is built
using Rifidi Emulator. It allows a user to experiment with RFID readers by mimicking a
particular reader’s command set, communication mechanism, behavior, and output.
Virtual readers previously implemented by Pramari include Alien 9800, Symbol XR440,
Awid MPR, and EPC v. 1.1.
4
Using Rifidi Emulator as a base offers several advantages. A framework is
already in place for building a reader; several software components, such as a user
interface, a communication framework, and a message processor were reused and are
shared between all the virtual readers. In addition, applications built on top of the
Emulator, such as Rifidi Designer, are able to use the virtual LLRP reader for free.
Finally, the virtual LLRP reader benefits from the community already surrounding Rifidi
Emulator through having users to find bugs and provide other suggestions.
In order to build the virtual LLRP reader, a deep understanding of both the
structure of the Rifidi Emulator code and the LLRP specification is required. Using this
knowledge, key differences between the way other virtual readers are implemented and
how the LLRP reader needs to behave are identified. Then the core of the reader is
designed and implemented. New features are and old ones are improved in an iterative
process as a clearer understanding of LLRP was gained and user feedback revealed bugs.
Finally, unit tests are implemented to support future regression testing as the LLRP
reader emulator is improved or evolved in the future.
1.4. Potential Impact
The immediate potential impact of this work is that anyone who is interested in
the new LLRP specification (introduced in early summer, 2007) can begin to gain hands-
on experience with an LLRP reader. Because the LLRP specification is so new, the open
source Rifidi virtual LLRP reader has the potential to become a de facto standard, as no
other virtual readers are yet available to the general consumer. In fact, plans are
underway for EPCglobal to certify Rifidi’s reader as compliant with the specification.
Another impact is that applications can be built on top of the reader. For example, a large
5
middleware vendor has plans to use the LLRP reader to conduct load testing on their
middleware product. Also, as previously mentioned, Rifidi Designer, will incorporate the
virtual LLRP reader in order to allow users to build and simulate 3D RFID processes in
real-time. Yet another possibility is to port the LLRP virtual reader to an embedded
device; it could become a sort of open source LLRP operating system for readers.
A broader impact of this thesis is that the virtual LLRP reader could pave the way
for other types of devices to be virtualized. As the quality of the virtual RFID reader
improves, the potential usefulness for other virtual devices that could interact with the
reader increases. For example, a virtual conveyor belt, photo eye, light stack, and sorter
could all interact to create a useful scenario simulation tool. Furthermore, because efforts
such as Rifidi Designer and RFID simulation in Second Life [8] are already underway,
these type of higher-level modeling tools could be developed with relative ease.
1.5. Organization of this Thesis
This thesis is organized as follows. Chapter 2 provides background by providing
a review of RFID technology, an introduction to the LLRP specification, and an overview
of the Rifidi emulation product suite. That chapter also describes related projects
including other simulation tools and the LLRP Toolkit project. Chapters 3 and 4 describe
the architecture and implementation of the virtual LLRP reader, including explaining how
the Rifidi Emulator is structured, how the LLRP reader differed from previously
implemented readers, and how these differences were reconciled. Chapter 5 provides
conclusions, lessons that were learned as well as ideas for future work relating to this
project.
6
2. BACKGROUND
This chapter introduces background information that is needed to understand this
thesis. Section 2.1 Key Concepts begins by giving an overview of the technology,
history, and current and possible uses of RFID. It then describes the LLRP specification
and how it is intended to standardize the interface between RFID readers and clients.
Finally, it introduces the three products in the Rifidi Product Suite. Section 2.2 Related
Work gives an overview of some projects similar to Rifidi in functionality, design, and
purpose. There are several projects in this area, such as the Second Life RFID simulation
project at the University of Arkansas, a PLC emulator produced by The Learning Pit, and
the modeling and simulation software made by Applied Materials.
2.1. Key Concepts
2.1.1. RFID
Radio Frequency Identification (RFID) is a method of automatic identification
whereby a transponder (tag) emits a radio wave that a transceiver (reader) receives and
decodes into data. The RFID tag consists of two parts: an integrated circuit that is used to
process and store data and an antenna that is used to send and receive data. Although
RFID tags can come in all shapes and sizes, they can be classified into two groups –
passive and active. Passive tags do not contain an internal power source; instead the
internal chip uses the electricity generated when incoming radio waves induce a current
into the antenna. Active tags do have an internal power source and can broadcast a signal
without the need of a nearby reader to provide a radio signal. Due to the fact that they
need to be in close contact with a reader, passive tags cannot transmit data as far as active
7
tags (typically around 12 feet). In addition, because active tags’ signal strength is greater,
they are more reliable than passive tags, especially in environments that are not friendly
to RF signals, such as ones containing water or metal. Passive tags are, however,
considerably less expensive than active tags [9,10].
One of the early predecessors of RFID technology was the Identification, Friend,
or Foe (IFF) transponder used by the allies in World War II to differentiate between
enemy and friendly aircraft. In 1948, Harry Stockman published a paper called
“Communication by Means of Reflected Power” [11] that is considered by many to be
the birth of RFID. Scientific and engineering exploration of RFID continued through the
1950s. Commercialization of RFID began in the 1960s when companies such as
Sensormatic, Checkpoint, and Knogo used simple 1-bit tags in electronic surveillance
systems to help prevent theft. In the 1970s several implementations were tested, such as
one developed for the Port Authority of New York, built by General Electric,
Westinghouse, Phillips, and Glenayre, however these were not widely used. Around
1987 RFID-enabled toll collection systems began to appear in Europe, and by 1989
similar systems were in place in Dallas, New York, and New Jersey [9, 12].
It was not until the 1990s, however, that RFID gained acceptance as an enabler in
the supply chain. In 1996, the Article Number Association (ANA) and European Article
Numbering (EAN) standardized RFID as a data carrier. In 1999 the Auto-ID Center was
established at the Massachusetts Institute of Technology to develop the Electronic
Product Code (EPC) – a global standard for product labeling. The Auto-ID Center later
split to become EPCglobal, a non-profit devoted to the commercializing of EPC
technology, and Auto-ID Labs which continued with scientific and engineering research.
8
The importance and future of RFID in the supply chain was cemented in 2003 when Wal-
mart Inc. mandated the use of RFID in its supply chain [13].
In addition to supply chain management and toll collection systems, other RFID
applications that are currently being used or investigated include:
Passports – In 2006, RFID tags began to be included in new US passports.
The data contained on the chips will be the same as the information printed on
the passport along with a digital picture [9].
Electronic Toll Collection – Although RFID-enabled toll collection systems
were tested as early as the 1970s, the first major implementation on an open
highway was deployed in Oklahoma in 1991. Since then, toll collection using
RFID technology has become popular, and in some places (such as the North
Eastern United States with the E-Z Pass System), is nearly ubiquitous [12].
Car Keys – Some car manufactures have used RFID as security measure;
without the proper RFID chip on the key, the car will not start. Others use
RFID as a convenience. For example, Toyota began to produce cars in 2004
that allow a drive to unlock and start the car using a key chain with an active
tag in it [9].
Animal Identification – RFID chips is being used to identify pets and
livestock [14].
Baggage Handling – Airports such as Hong Kong’s Chek Lap Kok
International and San Francisco International have begun piloting an
implantation of an RFID system to help track baggage. [15].
9
Hospitals – Hospitals can use RFID to track patients and equipment. RFID
tags could be used to make sure that medication is given to the correct patient,
in the operating room to make sure doctors perform the correct surgery on the
patient, and to aid with mother-baby pairing. [15].
2.1.2. LLRP
On April 12, 2007, EPCglobal ratified the Low Level Reader Protocol (LLRP)
specification in an effort aimed at standardizing the interface between RFID readers and
clients. It is so named because it allows for the control of low-level, air protocol
functions, such as those in the Class-1 Generation 2 (C1G2) specification1. In addition to
specifying how a client should command a reader to inventory, read, write and perform
other air-protocol specific operations, the LLRP specification defines a method for
reporting tag reads and errors back to the client, facilitates the addition of new air
protocols specifications and other vendor defined messages, and allows for the retrieval
of reader capabilities [16].
Without standardization, the interface between a client and a reader can be
extremely different, even though the basic functionality performed by the reader at a
lower level (i.e. the air protocol level) can be similar, or even standardized. If every
reader vendor produces readers with different interfaces, the end result is that the
business implementing the RFID solution has to commit to a proprietary reader control
system. Such a commitment makes switching to different readers or software
1 An air protocol is the standard that a reader uses to communicate with tags. The only air protocol
currently supported by LLRP is C1G2, though LLRP allows for others to be added. Air protocol specific
functions are commands that are allowed by the specific air protocol. For example, the lock and kill
operations in C1G2 are specific to it.
10
components such as edgeware costly in terms of time and money. In short, without a
reader interface standard, RFID solutions are still tightly bound to reader companies and
proprietary interfaces, despite lower level standards designed to prevent vendor lock-in
[17].
The LLRP protocol uses data units called messages. Command messages sent
from the client to the reader perform such functions as getting reader capabilities and
configuration, setting reader configuration, and managing the reader’s tag read and
reporting operations. Messages sent from the reader to the client send tag data and event
notifications to the client as well as response messages to the messages that the client
sends [16].
Figure 1. The structure of an LLRP Message (from [16])
As depicted in Figure 1, LLRP Messages consist of an 80-bit header and a
variable-bit payload. The message is broken down as follows [16]:
Rsvd – reserved bits for future extensions.
Ver – version of the LLRP spec being used.
Message Type – a number corresponding to the type of LLRP message
being transmitted in this message.
Message Length – the size in bytes (octets) of the entire message.
Message Value – carries the payload for this message.
11
All numbers are encoded with the most significant bit first (big-endian) [16]. The
payload is broken up into parameters and fields. Parameters consist of a parameter type
followed by other sub-parameters and fields that describe some specific details of an
LLRP operation. Fields are the values in the parameters, such as integers, bytes, and
strings. In more formal terms2:
MESSAGE rsvd ver type length id VALUE
VALUE (PARAMETER | field)+
PARAMETER id (PARAMETER | field)+
LLRP enabled clients and readers use these messages to communicate. Figure 2
shows a typical timeline for client-reader communication using LLRP messages. First, a
client will configure the reader with a SET_READER_CONFIG message, which sets up
reporting triggers, antenna configuration, and event notifications among other things.
Then the client will send an ADD_ROSPEC message which configures the reader to read
tags by setting up parameters such as start and stop triggers, which air protocols to use,
and which antennas to scan. This information is contained in a Reader Operation
Specification (ROSpec). The client then sends an ENABLE_ROSPEC message so that
the reader starts listening for a start trigger. When the start trigger does occur, the reader
begins to inventory tags until a stop trigger occurs. Tag reads are sent back in the form of
ROReport periodically as has been configured.
2 Formal grammar notation where upper-case terms are non-terminals, lower-case terms are terminals and +
is a BNF operator meaning that the term is repeated one or more times.
12
Figure 2 A typical timeline for an LLRP session (from [17])
As mentioned above, in order to get tag reads back from the reader, a client must
configure the reader using a ROSpec, which is a collection of inventory commands to
execute on the tags and parameters that control when to start and stop the execution of the
commands [17]. Specifically, The ROSpec contains an ID, an integer that defines the
relative execution priority of this ROSpec with respect to others, an integer representing
the current state of this ROSpec, a ROBoundarySpec that defines on what conditions
to start and stop reader operations, and a list of Antenna Inventory Specifications
(AISpecs) that contain more information as to how to actually perform the operations.
The AISpec contains a stop trigger, a list of antennas to perform the operations on, and
13
a list of InventoryParameterSpecs that define which air protocol to use and how
the antennas should be configured [16].
Figure 3 A UML class diagram showing the structure of a ROSpec parameter
As shown in Figure 4, in order to actually begin execution, the ROSpec must first
be added to the reader using an ADD_ROSPEC message, which will put the reader in the
disabled state. Then an ENABLE_ROSPEC message moves the ROSpec into the inactive
state where it waits for a start trigger as defined in its ROBoundarySpec. For example,
the start trigger could be ‘immediate’ in which case the ROSpec would move into the
active state without delay, or it could be ‘periodic’, in which case it would wait for a
specified amount of time before moving on. If the start trigger is set to null, it will wait
for a START_ROSPEC message from the client. Once it is in the active state, it will
execute its list of AISpecs in the order given until it is either finished executing all the
ROSpecs or until the stop trigger specified in the ROBoundarySpec occurs. A
14
DISABLE_ROSPEC message will move the ROSpec back into the disabled state, and a
DELETE_ROSPEC message will remove it from the reader all together.
Figure 4 A state diagram showing ROSpec transitions (from [16])
Figure 5 shows the logic that executes when a ROSpec is in the active state. The
ROSpec executes each AISpec in its list of specs to execute in the order defined. Once
an AISpec is in the active state, it will continue to execute until the stop trigger defined
for that AISpec fires. Then the ROSpec will execute the next AISpec in its list. If
there are no more AISpecs left, the ROSpec will move into the inactive state.
15
Figure 5 A flowchart showing how an AISpec is executed (from [16])
ROSpecs define how the reader should inventory tags – that is scan the antennas
and gather EPC Tag IDs. However, other, more advanced functions are defined in the
C1G2 specification. To perform these functions – like writing tag information and
reading non-EPC ID information – the LLRP specification defines the AccessSpec
parameter. Like the ROSpec parameter, the AccessSpec must be added to an LLRP
reader via an ADD_ACCESSSPEC message and put into the inactive state using an
ENABLE_ACCESSSPEC message. However, AccessSpecs do not act independently;
instead they act as part of the Reader Operation. When a reader operation finds a new tag
on its antenna, and an AccessSpec is enabled, the AccessSpec will check to see if
the tag ID matches a pattern defined in it. If it does match, the access operation will be
carried out.
16
2.1.3. Rifidi Product Suite
Pramari has three software products in its Rifidi Product Suite. The flagship
product, Rifidi Emulator, is intended to be an Integrated Development Environment
(IDE) for RFID. A user first creates a virtual reader by selecting a type of reader to
emulate and enters some extra information such as an IP address to use and the number of
antennas to use. Once the reader is created, the user can generate tags and add them to
the reader’s antenna. Then the reader can be started and will be able to communicate
with client software, such as TagCentric, LogicAlloy ALE Server, IBM Websphere, or
other tools.
17
Figure 6 Screenshot of Rifidi Emulator
Rifidi Designer builds on the Emulator's functionality by allowing the user to
create and run a 3D simulation of a business process involving RFID. The Designer
enables the user to drag and drop components (such as RFID readers, conveyor belts, and
push arms) onto a canvass, generate batches of tags, and to associate certain business
rules with tagged items and components. For example, a rule could be made that tags in
batch 1 should be pushed onto another conveyor belt. Once the scenario is built, the
simulation can actually be run, enabling the user to develop a deep understanding of the
processes. In addition to the benefit of being able to see the interaction of components in
the scenario, because the virtual RFID readers emulate their real counterparts, the user
can become familiar with the patterns of data that the physical process will create.
18
Figure 7 Screenshot of Rifidi Designer
Rifidi Tag Streamer is a load testing tool that can simulate a large number of tags
and readers at once. To use it, a user defines the readers that will be used in the scenario.
Then batches of tags are defined that will induce load on those readers. Finally, the
actions are defined via segments. Each segment contains one particular action, such as a
batch of tags being added to a reader, or a GPI line being set high. The segments are
strung together to construct a scenario. This scenario can then be run to put a large load
on a system, such as an edge server or other middleware.
19
Figure 8 Screenshot of Rifidi Tag Streamer
2.2. Related Work
2.2.1. Other Simulation Tools
One project related to virtual readers (and other simulated smart devices) is the
RFID scenario simulation tool using Second Life at the University of Arkansas. Second
Life is an online 3D virtual world, in which users can communicate, collaborate, and
build virtual spaces and processes [8]. The University of Arkansas has purchased an
online space (called an island) and is working to build a simulation environment that
models various smart devices, including RFID readers. Its initial focus is on the
healthcare logistics area. Although this project is similar to Rifidi, there are a few key
20
differences. First of all, the Second Life tool is built on-line, while Rifidi is a traditional
desktop application. One advantage of being online is that it allows users to collaborate
on processes and structures more easily. In addition, using the Second Life platform
allows the tool to build on top of an existing 3D engine. However, because Rifidi is a
desktop application, it offers users a software experience that they are more accustomed
to (i.e. they don’t have to sign up for an account or figure out how to use the Second Life
client).
Perhaps the biggest difference between the Second Life RFID project and Rifidi
Emulator is that the Second Life project is focused more on the flow of RFID-enabled
processes; in this way, it is more like Rifidi Designer. Rifidi Emulator – which includes
the virtual LLRP reader – is a reader emulator: its purpose is to mimic how a particular
reader behaves, and not the whole processes. Interestingly, the Second Life program
could use Rifidi Emulator to emulate the underlying RFID readers in its simulation.
Another project somewhat similar to Rifidi is The Learning Pit’s Programmable
Logic Controller (PLC) simulator called PSIM [18]. A PLC is a computer designed
specifically to automate industrial processes, especially those in factories or on assembly
lines. One of the main characteristics of a PLC device is that it has extensive Input and
Output arrangements that will typically connect to sensors and actuators [19]. PSIM
allows users to write and edit PLC programs, run the program and watch I/O being
updated, and to see animated scenarios react to their simulations, such as conveyor belts
moving and traffic light controls.
PSIM is like Rifidi in that it contains both a low-level emulation mechanism and a
high level simulation tool, the main difference being that PSIM is focused on general
21
PLC devices and how to control multiple automated devices in an environment, while
Rifidi Emulator is concerned only with the control of RFID readers and the data that
readers produce. Additionally, PSIM is intended to be a training tool only, while the
Rifidi products offer enough functionality to be useful to a business for processes
planning. However, because PLC devices are often used in conjunction with RFID
readers in real-world situations, it would be beneficial for the Rifidi products to extend its
virtual device library beyond RFID readers and incorporate other smart PLC devices such
as photo eyes and light stacks.
A third software product that is similar to Rifidi is Applied Material’s AutoMod
program. This program uses CAD-like features to define a simulation environment. It
then provides 3D animations of factory environments including conveyor belts, path
based movements of vehicles such as forklifts, and bridge cranes. Although this software
is helpful for laying out general processes, it is not RFID specific. Also, the software is
commercial and expensive; it is targeted at large companies who can afford expensive
software [20].
2.2.2. LLRP Toolkit
One of the important projects related to the Rifidi virtual LLRP reader is the
LLRP Toolkit, an open source project led by several organizations including the
University of Arkansas, Impinj, Intermec, and Pramari [21]. Its aim is to provide a set of
libraries for the development of LLRP-based applications and readers [7]. The main
service that the libraries provide is the marshalling of LLRP binary frames to and from
native language object. An additional goal is to provide the developers with a standard,
22
human-readable description of the LLRP messages in XML. The libraries exist for
several different languages including Java, .Net, C++, and Perl.
The libraries play a central role in the Rifidi virtual LLRP reader because they
handle the encoding and decoding of LLRP messages to and from Java. The original
Java library was contributed by Joe Hoag at the University of Arkansas [22], and was
later maintained and further developed by the Auto-ID Lab at the Swiss Federal Institute
of Technology in Zurich (ETH). Pramari participated in the testing and development of
the LLRP Java libraries.
23
3. ARCHITECTURE
This chapter describes the architecture of the Rifidi LLRP Emulator3. Section 3.1
describes the state of the Rifidi Emulator before the LLRP work was completed and
details the extensions made by the author. Section 3.2 explains how the underlying Rifidi
Emulator engine is structured to support multiple kinds of front ends, as well as how it
can be run across multiple machines over a network. Section 3.3 describes how the
engine is structured and was used in this thesis to enable rapid LLRP RFID reader
development. Section 3.4 describes specific design challenges with the LLRP virtual
reader.
3.1. Development of Rifidi
The information in this section is presented in a top-down fashion for the sake of
clarity. However, not all of the architecture pre-dated the virtual LLRP reader; some of it
was developed concurrently with or even after the bulk of the work on the LLRP reader
was completed. In addition to helping the reader of this thesis to understand the Rifidi
system, this section differentiates which components were developed by the author and
which were developed by others.
3.1.1. Preexisting Components
The following Rifidi components were designed by others before or during the
extensions developed by the author:
3 I developed the architecture and implementation described in this chapter while working as a coop student
working for Pramari from June 2007 to present. This description is used by Pramari permission. The
software is available as open source on SourceForge (http://sourceforge.net/projects/rifidi/).
24
IDE – The User Interface (UI) of the Rifidi Emulator
Communication Layer – The way in which messages are read and buffered
from an input, such as TCP/IP sockets
Message Processing Layer – The mechanism for handling incoming and
processing of messages
Radio Layer – The radio layer, including the Antennas, Radio, Tag Memory
and Tag Classes
Readers – The Alien, Awid, and EPC v 1.1 virtual readers
LLRP Toolkit – Although not part of the Rifidi Emulator architecture proper,
the toolkit for translating LLRP Messages to and from Java objects played an
important role in the development of the virtual LLRP reader. It was written
by Joe Hoag at the University of Arkansas during the summer of 2007.
3.1.2. Extensions by the Author
The author developed or extended the following modules:
Engine-UI RMI Interface – Initially, XML Remote Procedure Call (XML-
RPC) was used as an interface between the engine and the UI, but this had the
drawback of being a one-way communication. When the LLRP reader was
being developed, we realized that certain state changes in the engine, such as a
tag write operation, would need to trigger a change in the UI. As a result, the
author developed a new interface with help from Pramari’s Andreas Huebner.
Radio Layer – Although this layer previously existed, several large updates
were needed to make the radio more general so that it could be used by more
25
readers. In addition, a new tag class was created with help from Pramari’s
Jochen Mader that more accurately modeled Class 1 Generation 2 tags; these
classes were necessary to add advanced tag functions such as writing, locking,
and killing of tags
GPIO Layer – Prior to the LLRP reader, this component did not exist. Since
its development, it was reused in Pramari’s Alien virtual reader
Readers – Pramari’s Symbol virtual reader was created before the LLRP
reader with help from Matt Dean.
3.2. Overview of Rifidi Architecture
The Rifidi product suite is intended to be a set of user-friendly applications to
enable users to experiment with RFID processes before investing in new hardware
infrastructure. The products need to be portable across several architectures and, because
the code base is open source, the code needs to be structured in a way that makes it
accessible to developers.
Java was chosen as the platform for Rifidi because it is portable (write once, run
anywhere) and widely-used. The Rifidi user interface (UI) framework is the Eclipse Rich
Client Platform (RCP). Although Java's Swing does provide UI functionality that is
portable, it does not render widgets in a system's native windowing objects. The result is
a UI that does not look native to the platform. Because RCP applications rely on the
Standard Widget Toolkit (SWT) which is a wrapper around native windowing code
objects, the resulting applications appear native to their platform [23]. In addition, the
RCP framework provides a workbench (views, perspectives, and wizards), a bundling
service, and a deployment plugin [24, 25].
26
The project is cleanly divisible into UI code and engine code. The UI portion is
mostly different for each of the products; there is, however, a package containing
reusable components such as commonly used wizards and views. The engine provides
the core reader emulation functionality. It contains the code that facilitates reader
communication (e.g. TCP/IP-based socket communication), message parsing, message
handling, and Radio and GPIO emulation.
The Rifidi products use a client-server model as an interface between the UI and
the engine. In this way, a single UI can control multiple engines on different machines
throughout a network. More specifically, the UI and the engine use Remote Method
Invocation (RMI) to communicate.
Figure 9. A diagram depicting the how RMI is used in Rifidi.
Figure 9 depicts the role that RMI plays in the Rifidi architecture. The client
(such as the IDE, Tag Streamer, or Designer) runs on a local machine. Its purpose is to
allow the user to manipulate readers (i.e. start, stop, add tags, etc). The reader server
27
manages one or more readers on a particular machine by creating and destroying readers.
There is one instance of a reader manager per machine. A reader is the program that
emulates a particular reader, such as an LLRP Reader. There can be multiple instances of
a reader on a single machine. One important aspect of this architecture is that the client is
agnostic about where the reader server is located (i.e. local or remote). Additionally, this
architecture allows a client to control multiple reader servers on multiple hosts. This
ability enables Rifidi to scale, which is especially important for the Tag Streamer
application whose primary purpose is to be a load testing tool.
3.2.1. Server Manager
The server manager is the object that manages readers on a specific machine.
There is exactly one server manager per machine. It is in charge of keeping track of the
readers (i.e. creating and destroying). The server manager can be started locally via a
programmatic method in the client that is provided for convenience, or remotely via the
manager's main method. If the server manager is started remotely, the client will need to
know the server manager's IP and port in order to connect to it.
Figure 10. UML Class diagram of Server Manager
28
3.2.2. Reader Manager
The reader manager is the wrapper around a reader on a machine. There is one
reader manager per instantiated reader. It exposes underlying functionality of the reader,
such as 'turn on', 'add a tag' and 'toggle GPI port'.
Figure 11. UML Class diagram of Reader Manager
3.2.3. Client Callback Manager
The callback manager is the object that handles callbacks from the readers.
Callbacks happen when something on the reader changes that the IDE needs to know
about to update a GUI component, such as a Tag ID changing or a GPO line toggle.
There is one callback manager per reader in the IDE.
Figure 12. UML Class diagram of Callback Manager
3.3. Engine Architecture
At the core of the products in the Rifidi Suite is the engine. The purpose of the
engine is to emulate a particular RFID reader (e.g. an Alien 9800 or a Symbol XR 400).
29
Figure 13. A high level diagram of the virtual reader as a command processor
At a high level, the engine is a command processor. Commands are sent from the
client to the virtual reader, the reader parses and executes the commands and sends
responses back if they are needed. Command processing is a useful paradigm not only
because most readers are command-centered in that the functionality of the reader is used
via a distinct set of messages sent to the reader, but also because it can be easily extended
to other kinds of virtual devices by creating a new parser and executer for that device.
This section describes how readers are structured in a way to reuse as much code as
possible between the readers, while still having a flexible architecture.
30
Figure 14. A high level diagram of a Rifidi virtual reader
3.3.1. Communication Layer
The communication layer is responsible for managing the connection and
receiving and sending information between the virtual reader and the client program. Its
main function is to read bits from the stream, to group the bits into a message for the
command processor to parse and execute, and to place the message on the incoming
buffer for the message processing layer to process. In addition, the communication layer
takes outbound messages from the outgoing buffer and sends them to the client. The
communication layer is designed to be generic for all virtual readers and devices. While
most readers use TCP, the connection layer can use UDP, serial, or some other
31
communication protocol; the communication layer must only read bits, and put individual
messages on the incoming buffer.
Most of the code in the communication layer can be reused by all the readers;
however there are two cases where the logic of reading messages from a stream depends
on the type of reader being emulated. In these cases, the logic is abstracted into a Java
interface which each reader must then implement and pass into the communication at
construction time. For example, one process that may vary from reader to reader is how
information is best read from the TCP socket (if TCP is being used). For the Alien
reader, in which all the commands are sent in plain text, it is easiest to use Java’s
readLine() method which reads until it finds a \n. However the LLRP specification
defines a bit-encoded protocol in which messages are sent. In LLRP’s case it is better to
use a readByte() method. To keep the communication generic, an interface called
StreamReader was defined with a single method called read that returns an array of
bytes. All readers that use TCP must implement this class and pass it in to the
TCPCommunication object when it is constructed. The TCPCommunication class
then just calls its StreamReader’s read() method to read from TCP in the correct
way. This pattern of defining an interface that all readers must implement in order to
keep most code generic is used in many places in the Rifidi architecture.
32
Figure 15. A UML Class Diagram of the StreamReader
The second case where reader-specific code needs to be used in the
communication layer is the protocol parser. The protocol parser defines how to chop up a
stream of bits into individual reader-specific messages. For example, each command for
the Alien reader ends in a null character (i.e. \0). If a client sends two commands
quickly, the communication object will receive the second command before it finishes
reading the first command; the commands will run together and the communication
object will place both commands into a single slot in the incoming buffer. However,
because the syntax of the messages is different for each reader, the algorithm used to
separate bits into distinct messages is unique to the reader. So each reader also sends in a
protocol parser object to the communication constructor that handles parsing incoming
bits into reader-specific messages.
In addition some readers may require outgoing messages to be encoded with a
protocol as well. For example, if a protocol such as HTTP were being used between a
reader and a client, outgoing messages would be need to be encoded before being sent
out. Therefore, the protocol interface that each reader must implement has both an
addProtocol() and a removeProtocol() method.
33
Figure 16. A UML Diagram showing the Protocol interface
3.3.2. Message Processing Layer
Once an incoming message has been put on the incoming buffer, it moves into the
command processing layer which handles the parsing and execution of the command
inside of the message. The parsing is handled similarly to how the protocol is removed in
the communication layer. A message parser interface4 is defined with a decode()
method for parsing the incoming message and an encode() method that formats the
outgoing response. Each reader implements its parser in its own way and passes the
parser object to the command controller when it is constructed.
One important step in parsing the command is to assign the command an ID that
identifies what kind of command it is. These IDs are different for each reader. Some
readers such as the Alien use variable names such as persistTime as their IDs
because the commands are centered around getting and setting variables. Other readers,
such as the LLRP have a message ID for each kind of message, so this can be used as its
command ID.
4 The parser is named CommandFormatter in the Rifidi code.
34
Figure 17. A UML Diagram showing the CommandFormatter interface
The execution of the command is handled somewhat differently. The command
ID that was assigned to the command object by the parser is used to look up a canonical
Java method name in a hash table. This method – the command’s “handler method” – is
a unique method designed to perform some functionality specific to the incoming
command. For example, if the command ‘set persistTime=3’ is sent to an Alien
virtual reader, the handler method will change the value of the persistTime variable
to 3. The handler method is invoked by the command controller via reflection, and the
command is passed in as an argument.
The handler method returns an instance of a CommandObject class that stores a
return value, if there is one. This commandObject is passed back through the
formatter, and placed on the outgoing buffer. From there, the communication layer takes
the message, encodes any necessary protocol and sends it back to the client.
3.3.3. Radio Layer
The radio is the component that handles tag operations. A virtual reader has one
or more antenna objects which serve as a container to which the front end can add or
remove tags. The radio object is the interface between the antennas and the tag memory.
35
It observes the antennas in the reader. When the state of an antenna changes (i.e. a tag is
added or removed), it triggers the radio to scan all the antennas to get a complete
inventory of the tags in the field of view. It then passes this information to the tag
memory object via the tag memory’s update method. The rest of the reader accesses tag
information from the tag memory.
Figure 18. A UML Class diagram depicting the radio layer
3.3.3.1. Antenna
The antenna object is a hash table that stores RFID tags in it. The reader
manager’s addTag() and removeTag() methods – accessible through RMI – add
and remove tags to the antenna. It extends the observable class so that the radio object
can observe it.
36
Figure 19. A UML Class diagram of the antenna
3.3.3.2. Radio
The radio object is the interface between the antenna and the tag memory. Its
most important method is the scan method, which takes an inventory of the tags currently
in the reader’s field of view and updates the tag memory. It can be triggered either
“automatically” whenever an antenna changes, or “manually” through the invocation of
the method in a handler method.
Figure 20. A UML Class diagram showing the Radio
3.3.3.3. Tag Memory
Each kind of reader has a unique way of keeping track of tags. For example, the
Alien reader has a variable called the “persist time” which is the amount of time that a tag
should stay in memory after it has last been seen. The Symbol reader differentiates
between “visible tags” – those tags that are currently in the reader’s field of view, and
“invisible tags” – those tags that have been seen by the reader, but not purged. To
accommodate for the various memory models that readers use, the engine requires that
each kind of reader has a class which implements the tag memory interface. The most
37
important method in this interface is the updateTagMemory() method which gets
called whenever the scan method is invoked in the radio. It figures out in a reader-
specific way what needs to be done with the list of most recently seen tags. The tag
memory interface also specifies a getTagList() method which returns the tags
currently in memory.
Figure 21. A UML Class diagram of the tag memory interface
3.3.4. GPIO Layer
General Purpose Input/Output (GPIO) is a sort of serial interface that many
readers support. Usually, a reader will have a bank of GPI ports and a bank of GPO ports
located on it. GPIO is commonly used for communication with other devices (such as
photo eyes or light stacks) to make the reader smarter. Although the communication
between the reader and the device conceivably could be defined by a complex, vendor-
defined protocol, it is typically almost trivial. The reader only notices when a GPI line
goes high or low (and thus can be represented by a Boolean value), and follows some
business logic accordingly. For example, a reader could be configured to start a read
when GPI port 1 goes high, or it might turn on GPO port 2 when a timer goes off.
It is important to note the differences between GPI and GPO, and how these
differences matter to the reader engine. GPI lines are “lines in” from a smart device.
GPI events can trigger things to happen inside the reader, such as tag reads. GPO lines
38
are “lines out” to other smart devices to turn them on, or trigger them in some way.
Therefore, the Emulator UI allows you to toggle GPI lines but only observe GPO lines
since the logic about whether a GPO is high or low is contained inside the reader.
There is one GPIOController per instantiated reader that handles all GPIO
operations. Its setGPIStateHigh() and setGPIStateLow() methods are
accessible to the front end via RMI through the equivalent methods in the reader manager
object. When the setGPOStateHigh() and setGPOStateLow() methods are
called, they call methods in the callback manager to inform the front end that the GPO
has changed.
Figure 22. A UML diagram depicting the GPIO Layer
The GPIOController extends the observable object so that other classes can
be notified when the state of a GPI or GPO line changes. This way the
39
GPIOController can remain generic to all reader types while virtual readers can
implement vendor specific logic when a particular GPIO event occurs. For example, in
the Alien virtual reader, GPI events can trigger the reader to move into and out of a wait
state when operating in autonomous mode, while in the LLRP virtual reader, GPI events
can trigger the reader to send a notification to the client program.
Figure 23. An example of a GPI event.
In the above example, a GPI event is triggered in the UI by a user. The UI then
calls a method in the GPIO controller via the RMI interface. When the GPIO controller
sets the state of the GPI port, it notifies any interested observers. The observer (in this
case it is some class that implements reader-specific logic) will send a notification to the
client program that the GPI line was set to high. This architecture allows the GPIO
controller to remain generic to all reader types and lets the individual virtual readers
implement their own logic to handle GPIO events.
40
3.4. LLRP Architecture
Certain aspects of the LLRP specification fit nicely into the virtual reader model
that had been previously developed for the other readers. For example, the LLRP
specification defines unique messages for each kind of command, which lent itself with
the overall, command-centered architecture well. Other aspects of the specification did
not fit so well. None of the previously developed readers had such a complex command
syntax or had as much emphasis on autonomous processes. For example, it is easy to get
tag reads from an Alien reader. One could simply use a telnet client to connect to the
reader, and send a short ‘get taglist’ command. With the LLRP reader, a software
client needs to be written, several commands must be encoded and sent to set up and start
a tag read operation, and the client needs to be able to receive and decode tag read
messages.
An additional challenge in building the LLRP virtual reader is that the intention
was for the reader to become a de facto reference implementation. This meant that
certain challenging features of the LLRP specification could not be simply omitted as
they had been in previously built virtual readers5. In fact, the ultimate goal was to have
EPCglobal certify the reader as compliant with the LLRP specification.
This section presents specific architectural challenges that presented themselves
during the design of the LLRP virtual reader. Some of these challenges were specific to
the LLRP reader. Others, however, required that the previously developed virtual reader
model be modified to become more generic.
5 The goal for previous readers was include just the functionality that most users would find useful when
experimenting with the reader. This normally only included basic reader functions such as getting tag reads
back from the reader; thus advanced functionality such as tag write operations was often omitted.
41
3.4.1. LLRP Messages
One of the first challenges that needed to be met was how to deal with the LLRP
message structure. LLRP messages are more complex than previous readers’ messages.
First of all, the messages are binary encoded, meaning that the structure of each message
is defined on a bit-by-bit level. For example, the LLRP specification defines that the first
three bits of each message are reserved, the next three bits are for a version, the next ten
bits are for a message type, and so on. Although previous readers, such as the Awid,
used bit-encoded messages, fewer messages were defined, and the messages that were
defined had far fewer properties inside them. In addition, because the LLRP
specification is a vendor-neutral, open specification, it allows for vendor-defined, custom
messages as well as custom extensions to messages. This means that the encoding of
messages needs to be easily extendible in case it is useful for a future user to extend the
Rifidi LLRP reader to support some custom message.
The LLRP specification defines a total of 41 messages (not including the custom
message format) and 110 parameters (not including custom parameter). Building a
library to encode and decode binary representations for all of the LLRP messages to and
from Java objects is a daunting task; fortunately, the LLRP toolkit6 provided this
functionality. In order to use the toolkit, the virtual LLRP reader incorporated the toolkit
into the CommandFormatter7. In the CommandFormatter’s decode() method,
the toolkit’s receive() method is called. After the bytes are decoded into a Message
6 The LLRP Toolkit was developed at the University of Arkansas by graduate student Joseph Hoag in the
summer 2007. 7 As stated above, the CommandFormatter is the class that handles any kind of reader-specific message
parsing after a message is received in the communication layer. It has a decode() method for turning the
message into a Java object and an encode() method for turning the outgoing message into a byte array to be sent out.
42
object, the message can be sent to a handler method to deal with it. When a response
message is ready to be sent back to the client, the toolkit’s serialize() method is
invoked in the CommandFormatter’s encode() method.
import Java.io.ByteArrayInputStream;
import Java.io.IOException;
import Java.util.ArrayList;
import org.rifidi.emulator.reader.formatter.CommandFormatter;
import edu.uark.csce.llrp.Message;
public class LLRPFormatter implements CommandFormatter {
/**
This method decodes bytes recieved from the Communication Layer
into an LLRP Message to be delt with by a handler method
*/
public Object decode(byte[] arg) {
ByteArrayInputStream message = new ByteArrayInputStream(arg);
Message m = null;
try {
m = Message.receive(message);
} catch (IOException e) {
System.out.println("Cannot decode bytes to LLRP Message")
}
return m;
}
/**
This method encodes an LLRP Message into a byte array to be sent out
to the client
*/
public byte[] encode(Object message) {
byte[] outgoingMessage = null;
try {
outgoingMessage = ((Message) message).serialize();
} catch (IOException e) {
System.out.println("Cannot serialize LLRP Mesage");
}
return outgoingMessage;
}
}
Once the commands are decoded into Java objects defined by the toolkit, these
Java objects can be sent and used in command handlers and throughout the rest of the
program. Similarly, once a command handler has finished processing a message and is
ready to send a response, the command handler passes in a Java object defined in the
43
toolkit to the CommandFormatter. There it is encoded and put on the outgoing
message buffer to be sent back to the client program.
Figure 24. How the LLRP Toolkit is used in the LLRP Virtual Reader
3.4.2. Connection Mode
Another way in which the LLRP reader differed from previously implemented
readers was in the method in which clients connected to the reader. Previously
implemented readers did not differentiate between a TCP connection and a message-
passing connection; once the client established a TCP-level connection, it could begin to
send reader-level commands to the reader. For example, once a client program
establishes a TCP connection with an Alien reader, it can send a ‘get taglist’
command.
Figure 25. The connection layers of a non-LLRP reader
44
The LLRP standard specifies that before a client can begin to send LLRP
messages, it must first establish an LLRP connection with the reader. An LLRP
connection is a TCP/IP connection over which only LLRP messages are sent.8 As long as
the client and the reader are communicating, this connection must be established. In
addition, the LLRP Specification requires that the reader be able to act as a server (i.e.
accept LLRP connections) or a client (initiate LLRP connections) when establishing the
LLRP connection.
It does not specify, however, the way in which the reader should be initialized to
accept or initiate connections. This implies that the reader should have a management
layer below the LLRP message processing layer to handle the establishment of an LLRP
connection9. The specification does not comment on how the management layer should
work.
8 The LLRP Specification declares 5084 as the default port for LLRP connections. In addition, the TCP
connection may use the TLS protocol for security, although this feature is not implemented in the Rifidi
virtual LLRP reader. 9 An LLRP Reader operates in a way similar to a web server; there is a management interface for
configuring how the web server accepts connections as well as an HTTP interface that actually
communicates with a client.
45
Figure 26. The connection layers of an LLRP reader
In order to accommodate the management layer in the Rifidi LLRP reader, a small
management console was developed that allows a user to set up the reader to accept
LLRP connections at a specified port, or to command the reader to establish an LLRP
connection with a client. The management console is accessible to the user via telnet.
Two commands are possible:
1. mode server [port]. This command sets up the reader to accept LLRP
connections on the specified port. If no port is given, 5084 is used
2. mode client [IP Address] [port]. This command causes the
reader to connect to a client at the given IP Address and port. If no arguments
are supplied, 127.0.0.1:5084 is used.
3.4.3. Reader Operation
The way in which tag reads are obtained from the LLRP reader is different from
previously implemented readers. With readers such as the Alien and the Symbol, tag
reads are usually obtained by sending a request for a tag read, which causes the reader to
46
scan its antennas, and a list of tags is sent back. In short, these readers use a command-
response communication model to get lists of tags back from the reader.
With the LLRP reader, this process of getting tags reads back from the reader is
more complex. First, a Reader Operation Spec (i.e. ROSpec) that defines, in this case,
how tag reads are to be obtained and reported is added to the reader via an ADD_ROSPEC
message. Then the ROSpec must be moved to the inactive state with an
ENABLE_ROSPEC message. Finally the ROSpec must be triggered to move into the
active state. While the ROSpec in the active state, it executes its list of Antenna
Inventory Specs (i.e. AISpec) that define in detail how the reader should scan the radio.
For example, the AISpec provides information as to which antennas to scan and which
tag generation to collect. The Reader Operation Report Spec in the ROSpec defines
what information (e.g. last seen time, antenna number, scan count) about the collected
tag information to send back to the client, as well as when to send the information to the
client (e.g. after 4 tags are seen, or every 30 seconds). The ROSpec is stopped via a
stop trigger and can be moved back into the inactive state with a DISABLE_ROSPEC
message. It can be deleted with a DELETE_ROSPEC message10.
In order to process ROSpec operations in the autonomous fashion described by
the LLRP specification, three components were needed. First, there would be a need for
a controller to move the ROSpecs from state to state. Next an executor would need to
wrap a ROSpec in a thread so that the operation could be carried out autonomously.
10 For more information on how ROSpecs work, see the LLRP section in the background chapter of this
paper.
47
Finally, a triggering system would need to be implemented to allow various events (such
as timers expiring or GPI events) to affect the processing of the ROSpecs.
3.4.3.1. ROSpec Controller
The ROSpec controller is a straightforward data structure that allows ROSpecs to
be moved to the various states of execution. It accomplishes this by maintaining three
lists: one for ROSpecs in the disabled state, one for ROSpecs in the inactive state, and
one for those in the active state. It also exposes methods to move the rospecs from state
to state. The addROSpec() and the disableROSpec() methods add the ROSpec to
the diabled list. The enableROSpec() and stopROSpec() methods add the
ROSpec to the inactive list. The startROSpec() moves the ROSpec to the active
list, wraps it in a ROSpecExecutor class and starts it.
The ROSpecController implements the Observer interface which requires
it to have an update() method. The ROSpecController observes
TriggerObservable objects which inform the ROSpecController of events that
would cause a ROSpec to change state.
48
Figure 27. A UML class diagram depicting the ROSpecController class.
3.4.3.2. ROSpec Executor
The ROSpecExecuter class provides a threaded wrapper for the ROSpec.
The ROSpec adds its list of AISpecs to the ROSpecExecutor. Then, when the
ROSpecController starts the ROSpec, it wraps the ROSpecExecutor in a thread
and invokes its run method. This causes the ROSpecExecutor to sequentially execute
each AISpec in its list. It is inside the AISpec object that the actual work of scanning
the antennas and processing tag lists is done. When a stop trigger fires for the ROSpec,
the ROSpecController stops the ROSpecExecutor via the stop() method and
moves it out of the active list.
49
Figure 28. A UML class diagram depicting the ROSpecExecutor Class
3.4.3.3. Triggers
The LLRP Specification defines several kinds of events that affect the execution
of ROSpecs. These events, called triggers, can cause a ROSpec to begin or end
execution, cause an AISpec to end execution, or cause a report message to be sent back to
the client. This table, adapted from the operations trigger and the reporting trigger in the
LLRP specification, enumerates the various triggers and their uses [16].
Trigger
ROSpec Start ROSpec Stop
AISpec Stop AccessSpec Stop ROReportSpec
GPI Trigger x x x
Tag
Observations x x
Immediate x
Null x x x x x
Periodic x
Duration x x
Figure 29. A table enumerating the triggers and their uses
Each of the various data structures (i.e. ROSpec, AISpec, AccessSpec and
ROReportSpec) has a parameter for their trigger type. For example, a user can define
a ROSpec with a GPITrigger as its start trigger and a DurationTrigger as its
50
stop trigger. This means that the ROSpec, once it is enabled, will begin execution once
the GPI trigger has fired. It will then stop execution once the duration trigger fires.
To implement this, various controller objects (such as the
ROSpecController) register themselves as observers of a TriggerObservable
object. Trigger objects, such as a DurationTrigger are created. The
TriggerObservable object is then given to the newly instantiated trigger via the
setTriggerObservable method. The trigger objects are responsible for listening
for one particular kind of event to happen. For example, the
GPIWithTimeoutTrigger listens for a certain GPI line to change. The
DurationTrigger contains a timer object that can be started via its startTimer()
method; it listens for the timer to expire. Then when one of these events happen, the
trigger object fires trigger by calling the fireStartTrigger() or
fireStopTrigger() method in its TriggerObsesrvable. This method call, in
turn, notifies the controller that a trigger has fired and it should act accordingly.
The advantage of this trigger architecture is that Trigger objects can be reused;
they are not tied to a particular controller. For example, both the ROSpecController
and the AISpec can use the DurationTrigger to stop the execution of ROSPecs
and AISpecs respectively. In addition, the controller objects do not need to care as to
what kind of trigger was fired. This means that a ROSpecController only has to
know that a start trigger was fired for a particular ROSpec, but does not have to know
what kind of trigger it was. Finally, other systems can use the triggering mechanism. For
example, the Notifier – the class that sends out tag reports to the client – can use the
TagObsesrvationTrigger to send out notifications after having seen N tags.
51
Figure 30. A UML Class diagram depicting the triggering mechanism used in the virtual LLRP Reader
DurationTrigger – This trigger is used as a stop trigger for ROSpecs
and AISpecs. It contains a timer object and will fire its
TriggerObservable object when the timer has expired
GPIWithTimeoutTrigger – This trigger is used as a start trigger for
ROSpecs and as a stop trigger for ROSpecs and AISpecs. It fires its
TriggerObservable object either when a particular GPI line has fired or
when a timeout has expired.
PeriodicTrigger – This trigger is used as a start trigger for ROSpecs. It
is a repeating timer trigger that will fire every k milliseconds.
ImmediateTrigger – This trigger is used as a start trigger for the
ROSpec. It will fire as soon as a ROSpec is enabled.
TagObservationTrigger – This trigger is used as an AISpec stop
trigger and as a reporting trigger. It fires after N tags have been seen, or T
milliseconds have passed since the last tag observation.
52
NullTrigger – This trigger is used to indicate that some other mechanism
will start or stop the event. For example, if the stop trigger for a ROSpec is
null, it must be stopped via a STOP_ROSPEC message from the client.
3.4.4. Access Operations
The LLRP specification defines four mandatory access operations for Class1 Gen
2 tags. The Read operation is used to read data (usually non-epc tag information, such
as user memory) from the tag. The Write operation is used to write data to the tag. The
Lock operation is used to change the access privileges of the tag. For example, if the tag
is in the locked state, no information can be written to it. Finally, the Kill operation is
used to disable the tag from future use [16, 26].
The biggest challenge in implementing the advanced functionality required by
access specs was designing tag classes that properly modeled Class1 Gen 2 (C1G2) EPC
tags while still provided enough flexibility to use elsewhere in the program. Previously
implemented Rifidi readers used a simple tag class that contained only such information
as the tag type and the tag ID . Because this rudimentary tag class was not modeled on
the C1G2 specification, it was not possible to properly simulate operations such as lock
and write.
First, a tag class had to be designed that followed the C1G2 specification. In
order to allow for future tag classes, such as Class 1 Gen 1 (C1G1), or Class 0 Gen 2
(C0G2), several interfaces were created. First a simple Gen1 interface provided basic
functionality to get a tag ID. A Gen2 interface extends the Gen1 interface to provide
Gen2 specific functionality. A Class that implements the Gen2 interface, called
53
C1G2Tag serves as the tag class needed for the LLRP Reader. Finally, a container class
was created for the EPC Tag classes called RifidiTag. This container stores extra
information that is often useful when processing tags, such as antenna last seen, and last
seen time, but is not part of any EPC spec.
Figure 31. A UML Class diagram showing the RFID tag classes in Rifidi
3.5. Lessons Learned: Modeling Future Virtual Devices
One of the design goals of Rifidi Emulator was to create an architecture and core
components that could be extended to and used by not only other types of virtual RFID
readers, but also a broad collection of virtual smart devices. Perhaps the types of virtual
devices that would benefit most from the Rifidi architecture would be those that are
closely related to and interact with RFID readers: conveyor belts, light stacks, motion
sensors, and tag printers. These devices could reuse components such as the GPIO
controller, the communication layer, and the power controllers. In addition, these type of
54
devices could be built to interact virtually with the Rifidi readers, which would make the
whole simulated scenario more realistic.
The general paradigm of device emulation vis-à-vis a message-processor, which
is at the heart of Rifidi, could be extended to almost any kind of virtual device that
interacts by processing commands and sending messages as output, however. For
example, a smart home emulator might consist of virtual thermostats, light switches, and
motions sensors, among other things. If a command language and communication
channel were defined for each of the devices, an architecture that looked similar to Rifidi
could be designed. More specifically, a Communication object that extends the
Communication class in Rifidi could be created. If the smart device used TCP/IP, the
device could simply reuse this object. Next each of the commands able to be processed
by the virtual device would be defined in an XML. Finally for each of the defined
commands, a handler method could be written to process the command. If the command
language of each device were designed properly, the virtual devices could interact, so that
the motion sensor might tell the lights to turn on and the thermostat to start the air
conditioner.
55
4. IMPLEMENTATION AND REDESIGN ITERATIONS
Building the LLRP reader presented some unique challenges in large part because
the specification was so new that there was no reference implementation to experiment
with in order to clear up any ambiguities within it. In fact, the intention was to build a
software LLRP reader that would become the de facto standard. This section describes
the various implementation and redesign stages that the LLRP virtual reader went
through as it was developed by the author.
4.1. Open Source Licensing
Rifidi is licensed under the Free Software Foundation’s Lesser General Public
License (LGPL). The LGPL requires the software which uses it to be open source, but
unlike the General Public License (GPL), does not require software that uses it as a
library to be open source. In other words, others can integrate Rifidi object code into
their applications without being required to release their program as open source.
However, Rifidi – and any derivative work of Rifidi – must be open source [26].
4.2. Iteration 1: Basic Command Support
The first task was to add enough functionality so that a Reader Operation could be
configured on the reader and tags reports could be received from the reader. For these
basic features to work, the reader needed to be able to support the ADD_ROSPEC,
ENABLE_ROSPEC, START_ROSPEC, STOP_ROSPEC, DISABLE_ROSPEC,
DELETE_ROSPEC, and GET_ROSPECS messages. This first iteration involved
writing the skeleton of the reader; the various core Rifidi emulator reader components
56
such as the tag memory and communication modules were developed. In addition the
LLRP Toolkit was incorporated into the reader so that messages could be translated from
bit-encoded messages into Java objects. Finally, a primitive ROSpec processor was
developed that allowed a ROSpec to be moved between states (see Figure 4).
At this point, the LLRP reader could processes basic ROSpec messages and send
ROAccessReports back to the reader. However, it lacked more complex triggering
support. For example, periodic start triggers and duration stop triggers were not
supported. In addition, the ROSpec processor operated in a continuous loop; it did not
stop processing a ROSpec until a STOP_ROSPEC message was sent. The reader also
did not send out reader event notifications.11
4.3. Iteration 2: Improved Triggering and Notification
After the first iteration, the basic support for setting up the reader to read and send
back tags worked, however the reader was far from being compliant with the
specification. The second iteration aimed to implement all required features but the
access commands. In this iteration, the triggering system as described in 3.4.3.3 was
implemented. This new triggering system allowed for all of the start and stop triggers
(except for GPI triggers) to be used. Event Notifications were also added in this iteration.
The reader would now properly send out event notifications when the reader accepted
and closed a connection. In addition, the reader was now able to be configured to send
out notifications when ROSpecs and AISpecs started and stopped. Another important
11 The LLRP specification defines notifications to be sent out at certain points to let the client know the
state of the reader, such as when a GPI state changes or when a ROSpec has started or stopped execution.
The only required notifications are the ConnectionAttemptEvent and ConnectionCloseEvent
which let the reader know that the connection has been accepted and closed respectively.
57
feature that took place in this iteration was that a basic management interface was added,
so that the reader could both accept and initiate LLRP connections 12.
4.4. Iteration 3: Access Command Support
The next step in developing the virtual LLRP reader was to add support for more
advanced C1G2 commands. Because the current virtual RFID tag objects relied on a
simple mechanism to store a tag ID, a new tag package needed to be written to allow for
more complicated tag operations. The new tag classes that were developed (see Section
3.4.4) were based off of the C1G2 specification [27]. For example, the new tag classes
contain four arrays that model the four memory banks required of compliant tags in the
C1G2 specification. In this way, the complex tag operations such as write, lock, and
kill could be performed on the tags.
After the tag classes were implemented, AccessSpec handler methods were
added to the virtual reader. These added support for the ADD_ACCESSSPEC,
ENABLE_ROSPEC, DISABLE_ACCESSSPEC, DELETE_ ACCESSSPEC, and
GET_ACCESSSPECS messages. The final part that was implemented was an engine to
process access operation on tags. The engine had to be able to filter tags based on a mask
in the AccessSpec, execute the operation to the tag if the tag matched the pattern, and
form results into an AccessReportData parameter. The engine was integrated into
the AISpec engine, so that each time a new tag was seen on the radio, it would be run
through the AccesSpsec engine to see if matched the specified pattern.
12 Andreas Huebner at Pramari designed and implemented most of the administration interface for the
virtual LLRP reader.
58
4.5. Iteration 4: General Purpose I/O
After the AccessSpec iteration, all of the features required by the LLRP
specification had been implemented. However, user feedback suggested that supporting
the GPIO features of the LLRP specification would be useful. The first step was
implementing a GPIO layer (see Section 3.3.4) that operated much like the Radio layer.
A user would need the ability to toggle GPI lines high and low on the user interface;
these actions would need to be then processed by reader-specific logic. In order to
implement this, the GPIOController was added to Rifidi Emulator in a way that
made it usable by other readers as well. Then a User Interface module was created that
allowed users to toggle GPI lines high and low and to view the state of GPO lines.
Finally a wrapper was written around the GPIOController that processed the actions
in an LLRP-specific way. For example, an LLRP client can configure the reader to send
out a ReaderEventNotification message when the state of the GPI line changes.
So the LLRP GPIO wrapper watches the GPIOController for a change in the GPI
lines. If a line changes it will send out a notification message. In a similar way, the
wrapper can start or stop ROSpecs and AISpecs based on GPI actions.
4.6. Iteration 5: Suspend/Resume Functionality
The Emulator serves as the core component for the Designer tool. One of the
requirements of Rifidi Designer is to be able to pause and resume scenarios as they are
running in real time. This implies that the virtual readers must be able to be suspended
and resumed as well. When readers are running in interactive mode, suspending and
resuming the reader is simply a matter of buffering command to the reader, since the
59
reader is just acting as a command processor. However, suspending a reader in
autonomous mode is more difficult, because the reader is actively processing information
even when a command is not given. For example, the LLRP reader can be set up to send
tag reports back to the client every five seconds, through the use of the periodic start
trigger and the duration stop trigger.
Suspending the reader when it is in autonomous mode is more difficult that just
buffering input to the reader because care must be taken that autonomous processes
suspend as well, or the reader will still send out data even when it is suspended.
Autonomous mode processes in RFID readers are often time based. As a result, a timer
object was developed that had a suspend() and resume() method and that will not
expire until it has waited for the complete wait time that it was initialized with; that is the
time elapsed between when the suspend() and resume() is called does not count
against the time left to wait on the timer. For example, if a five second timer is created
and started at t=0, then paused at t=2, resumed at t=10, the suspendable timer will expire
at t=13.
To add suspend and resume capabilities to the LLRP reader, time based triggers,
such as the PeriodicTimerTrigger and the DurationTimerTrigger were
reimplementation with the suspendable timer. Then when the suspend() method is
called on the LLRP reader, the reader can check to see if it has any autonomous processes
running. If it does, it can suspend its triggers, which effectively put the reader in a
suspended mode.
60
4.7. Iteration 6: Unit Tests
The final iteration of the virtual LLRP reader development was writing unit tests
with Junit. Unit tests are programs that automatically test a program by feeding in input
data and testing whether the output data meets certain criteria. If it does not, the test will
fail. Well written unit tests increase the reliability of software across its lifespan by
helping developers catch bugs that creep into the software when new features are
introduced that might affect the program in an unintended way.
Several test cases were identified to develop unit tests around the virtual LLRP
reader. Some of these test cases were based off of the conformance test document
provided by EPCglobal:
1. Connection – Test to make sure the reader can both accept and initialize
LLRP Connections
2. Reader Capabilities – Test to make sure that the reader can properly respond
to a GET_READER_CAPABILITIES message.
3. Error – Test to make sure that invalid messages generate proper error
messages from the reader
4. Basic Reader Operation – Test to make sure that a ROSpec can be configured
on a reader and that tag reports are properly sent back
5. Access Operation – Test to make sure that AccessSpecs can be added to and
processed by a reader. Test both write, read, lock, and kill access operations.
6. Tag Observation Triggers – Test the Tag Observation Trigger
7. Immediate Trigger – Test the Immediate Trigger
61
8. AISpec Stop Triggers – Test to make sure that the various triggers that
should stop an AISpec work.
9. Get Report – Make sure that the reader can be polled using the GET_REPORT
message.
10. Keepalives – Test to make sure Keepalive messages can be configured and
sent from the reader.
11. Suspend and Resume – Test to make sure the reader is being properly
suspended and resumed
12. GPIO – Test various features associated with the LLRP GPIO functionality.
4.8. Deployment and Feedback
The virtual LLRP reader was iteratively deployed, with user feedback driving the
development of the next iteration. The first release of the LLRP reader was made after
Iteration 1, when only a simple LLRP ROSpec processor was available. Feedback from
users from Impinj among others indicated that the reader was not usable until proper
event notification was built in. For example, the LLRP specification requires that an
event notification be sent to the client whenever the client successfully makes an LLRP
connection with the reader. Notification messaging, along with a better ROSpec
triggering system was built in to the second iteration. The next iteration which concerned
Access Command support (i.e. C1G2 Write, Read, Lock, and Kill), were built in
primarily to comply with the LLRP specification rather than to meet user demand. In
general, it does not seem that users are as interested as writing to tags as reading them.
The fourth iteration which involved adding GPIO support was built to satisfy users,
62
namely IBM and Penn St. LLRP suspend and resume functionality is not an LLRP
requirement, but rather is necessitated by Rifidi Designer in order to allow Designer to
pause and resume simulations in real time.
The Rifidi virtual LLRP reader has been met with some success. IBM solicited
help from Pramari to build a load testing tool (Rifidi Tag Streamer) around the virtual
LLRP reader that they could use with their Premesis application server. Although the
load testing has not been done yet with Tag Streamer at the time of this writing, IBM has
used the virtual LLRP reader inside Rifidi Emulator with Premesis to do functional
testing, and they have deemed the LLRP reader sufficient from a protocol and
functionality point of view. In addition, the RFID Center of Excellence at Penn St. is
planning on using the LLRP reader in the RFID classes that they offer. The virtual LLRP
reader will help students get hands-on experience with RFID readers without the
University having to invest money in hardware. Finally, a UK branch of an aerospace
and defense firm has been using the virtual reader to test an internal LLRP tool, judging
by questions and comments on the developer mailing list.
63
5. CONCLUSIONS
5.1. Summary
As RFID technology plays an increasingly important role in businesses’ processes
and infrastructures, simulation and modeling tools will be needed to support these
organizations as they plan their deployments. Especially important for businesses is the
ability to quickly digest and stay on top of important emerging standards such as
EPCglobal’s Low Level Reader Protocol (LLRP) that are going to shape the future of
RFID. The Rifidi virtual LLRP reader was developed to aid IT professionals, business
analysts, and software developers who work with RFID technology to gain experience
with the protocol and to begin to understand how to integrate middleware applications
with LLRP hardware.
The LLRP virtual reader is built on top of the Rifidi Emulator architecture which
aims to provide a framework which emulates all major parts of an actual hardware reader
from the communication framework, to the antennas, to the general purpose inputs and
outputs. This architecture is extensible to provide reusable components for the rapid
development of new reader emulators. The LLRP virtual reader is currently stable and
able to process and properly respond to all of the required messages in the LLRP
specification.
5.2. Contributions
The Rifidi LLRP virtual reader is already making contributions to the LLRP
community. As one of the first projects to use the LLRP Toolkit, it has not only been
able to provide an important test case for the project, but also has led to bug fixes and
64
feature development. More importantly, however, user feedback has indicated that the
LLRP virtual reader is being used to help developers understand and experiment with the
LLRP specification. IT professionals and students around the world have asked
questions and provided information about bugs via the Rifidi developer mailing list.
Finally, several universities and companies have already made plans to begin using the
software in a production environment. Penn State is planning on using the tool in their
RFID training programs, and IBM is planning on using the virtual LLRP reader in
combination with Tag Streamer to test their WebSphere RFID Premises Middleware.
5.3. Future Work
The work done for this thesis provides an architecture and working code base which can
be improved and extended. The following are features that will be needed in the near
future and ideas for future research surrounding the LLRP virtual reader:
As vendors begin to develop and sell LLRP readers, there will inevitably be
important proprietary extensions made to the LLRP specification that
customers find useful. One architectural puzzle is how to design vendor
extension packages in such a way that a Rifidi user could simply choose
which vendor extensions to add when the virtual reader is instantiated, while
keeping the core of the LLRP reader code reusable.
It would be interesting to explore non-RFID reader smart devices, such as
push arms and conveyor belts, within the context of the Rifidi Emulator.
These smart devices could probably reuse many of the same components
provided by the Rifidi Engine, such as the communication module, the general
purpose input and output, and the user interface.
65
Another possible extension of the virtual LLRP reader would be to build new
kinds of interfaces to the reader using RMI interfaces as a base. New kinds of
interfaces could allow the reader to be used in new ways. For example, one
useful interface would be a simple XML wrapper around the reader’s RMI
interface that would allow other kinds of clients to use the basic functionality
of the reader.
It is possible to view a reader with LLRP capabilities as a reader that is
running an “LLRP server.” Because the virtual LLRP reader created in this
project is nothing more than a program which properly processes LLRP
messages, it may be possible to extract the important LLRP processing parts
of the virtual reader into a package that could be put on an embedded device.
In effect, it might be possible to use the Rifidi virtual RFID reader as a basis
for the LLRP server on a real reader. Further exploration would reveal what
basic assumptions made about execution environments change from typical
PCs to embedded devices and what effect these changed assumptions would
have on the current code.
Because the backend emulation engine of Rifidi Emulator is accessible via
RMI, it is possible for other applications to use it programmatically as a
virtual reader server. One interesting idea would be to integrate Rifidi
Emulator into the Second Life project so that simulations in Second Life
would use Rifidi Emulator as their virtual readers. The Second Life
simulation would need to be able to communicate with Rifidi Emulator via
RMI or some XML wrapper. Then whenever a tag passes through the virtual
66
reader’s field of view, the Second Life simulation could send a message
telling the Rifidi virtual reader that a certain tag appeared. Not only would
this save the Second Life project from having to duplicate the work of
creating virtual readers, but it would also prove to be a good test for Rifidi
Emulator.
Due to the nature of the LLRP specification, the virtual LLRP reader is not
useful without a client that can connect to it and configure it to read tags and
send back reports. Work was begun on extending Tag-Centric – and open
source RFID edgeware client developed at the University of Arkansas – to
integrate LLRP support into it by former student Sidhartha Samanta during
the summer of 2007, however the final changes were never deployed and
released. Demand is present for an open source RFID client with LLRP
capabilities judging by requests for such software on the LLRP Toolkit
mailing list, so Tag-Centric has an opportunity to meet this demand if the
LLRP reader agent were better integrated into it.
67
6. REFERENCES
[1] M. Brewer, “RFID Adoption Hurdles Start to Tumble,” Wireless Design and
Development, Vol 15, October 2007, pS3-S4.
[2] J. Walker, “Commentary: The Year of Living RFID”, Forrester Research, CNET
News.com, January 2004,
[3] A. Zaheeruddin, M. Mandviwalla, “Integrating the Supply Chain with RFID: a
Technical and Business Analysis,” Communications of the AIS, Vol. 2005, Issue 15,
March, 2005, p 393-426.
[4] M. Hines, “Companies’ RFID Plans Fuzzy So Far,” ZDNet News, April 2004.
[5] B. Moore, “2007: Good Riddance,” Material Handling Management, Vol. 62,
Issue 12, December 2007, p. 64.
[6] EPCglobal Homepage, http://www.EPCglobalinc.org, accessed January 2008
[7] LLRP Homepage, http://www.llrp.org, accessed January 2008
[8] A. Hendaoui., M. Limayem, C. Thompson, “3D Social Virtual Worlds:
Research Issues and Challenges,” Architectural Perspectives column, IEEE Internet
Computing, January-February 2008.
[9] Radio-Frequency Identification, Wikipedia, http://en.wikipedia.org/wiki/RFID,
accessed January 2008
[10] What is RFID?, http://www.aimglobal.org/technologies/RFID/what_is_rfid.asp,
accessed January 2008
[11] H. Stockman, “Communications by Means of Reflected Power,” Proceedings of
the IRE, Vol. 36, Issue 10, October 1948.
[12] J . Landt, "Shrouds of time: The history of RFID," The Association for
Automatic Identification and Data Capture Technologies, Tech. Rep., 2001.
http://www.rfid4u.nl/downloads/shroudsoftime.pdf
[13] V. Chawla, D.S. Ha, “An Overview of passive RFID,” IEEE Communications
Magazine, Vol. 45, Issue 9, September 2007.
[14] C. McCarter, “Your Animals are now safe with RFID”, RFID Times, Auguse 31,
2006, accessed January 2008. http://rfidtimes.org/2006/08/your-animals-are-now-safe-
with-rfid.html
[15] S. Polniak, “The RFID Case Study Book: RFID Application Stories from Around
the Globe,” Abhisam Software, 2007, http://www.abhisam.com/
68
[16] EPCglobal, Low Level Reader Protocol Specification, Version 1.0.1. Ratified
August 13, 2007. http://www.EPCglobalinc.org/standards/llrp/
[17] Impinj Inc., “LLRP-Reader Control Simplified,”
http://www.impinj.com/uploadedfiles/RFID/Case_Studies_White_Papers/Impinj-
LLRP_data_sheet.pdf
[18] Hands-On Programmable Logic Controlling Training without the PLC,
http://thelearningpit.com/plc/psim/psim.html, accessed February 2008
[19] Wikipedia: Programmable Logic Controller,
http://en.wikipedia.org/wiki/Programmable_logic_controller, accessed February 2008
[20] Automod Simulation Software Overview,
http://www.brookssoftware.com/pages/245_automod_overview.cfm, accessed February
2008
[21] LLRP Toolkit Users, http://llrp.org/toolkitusers.html, accessed February 2008
[22] LLRP Toolkit News, http://llrp.org/whatsnew.html, accessed February 2008
[23] Wikipedia: Standard Widget Toolkit,
http://en.wikipedia.org/wiki/Standard_Widget_Toolkit, accessed December 2007
[24] Wikipedia: Rich Client Platform,
http://en.wikipedia.org/wiki/Rich_Client_Platform, accessed December 2007
[25] RCP FAQ, http://wiki.eclipse.org/RCP_FAQ, accessed December 2007
[26] Free Software Foundation, “GNU Lesser General Public License,” 1991,
http://www.opensource.org/licenses/lgpl-2.1.php
[27] EPCglobal, Class-1 Generation-2 UHF RFID Protocol for Communications at 860
MHz – 960 MHz, Version 1.1.0. 2004. http://www.EPCglobalinc.org/standards/uhfc1g2
Related Documents
