U.S. patent application number 11/408652 was filed with the patent office on 2007-03-01 for system and method for rfid reader to reader communication.
Invention is credited to Sayan Chakraborty, Brian McKinney.
Application Number | 20070046467 11/408652 |
Document ID | / |
Family ID | 37809505 |
Filed Date | 2007-03-01 |
United States Patent
Application |
20070046467 |
Kind Code |
A1 |
Chakraborty; Sayan ; et
al. |
March 1, 2007 |
System and method for RFID reader to reader communication
Abstract
A system and method for coordinating a plurality of radio
frequency identification (RFID) readers to minimize reader noise
and increase reader sensitivity. A first set of one or more of the
plurality of readers is coordinated to operate in a transmit only
mode. A second set of one or more of the plurality of readers is
coordinated to operate in receive only mode. The first and second
set are synchronized such that a receive period of the second set
coincides with a transmit period of the first set.
Inventors: |
Chakraborty; Sayan; (Niwot,
CO) ; McKinney; Brian; (Lakewood, CO) |
Correspondence
Address: |
LATHROP & GAGE LC
4845 PEARL EAST CIRCLE
SUITE 300
BOULDER
CO
80301
US
|
Family ID: |
37809505 |
Appl. No.: |
11/408652 |
Filed: |
April 21, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60712957 |
Aug 31, 2005 |
|
|
|
Current U.S.
Class: |
340/572.1 |
Current CPC
Class: |
H04B 1/22 20130101; H04B
1/58 20130101; G06K 7/0008 20130101; H04B 1/24 20130101; G06K
7/10356 20130101 |
Class at
Publication: |
340/572.1 |
International
Class: |
G08B 13/14 20060101
G08B013/14 |
Claims
1. A method for coordinating a plurality of radio frequency
identification (RFID) readers to minimize reader noise and increase
reader sensitivity, comprising: coordinating a first set of one or
more of the plurality of readers to operate in a transmit only
mode; and coordinating a second set of one or more of the plurality
of readers to operate in receive only mode; wherein the first and
second set are synchronized such that a receive period of the
second set coincides with a transmit period of the first set.
2. The method of claim 1, wherein the readers are connected to form
a reader network.
3. The method of claim 1, wherein operational fields of each reader
of the first set overlap at least one operational field of readers
of the second set.
4. The method of claim 1, wherein readers within the first set do
not interfere with one another during transmission.
5. The method of claim 1, wherein operational fields of readers
within the first set do not overlap.
6. The method of claim 1, further comprising coordinating a third
set of one or more of the plurality of readers to be
non-operational.
7. A method for distributing activity across a network of radio
frequency identification (RFID) readers, comprising: configuring a
first set of one or more readers at a first location to identify a
plurality of RFID tags; and configuring a second set of one or more
readers at a second location to interact with one or more of the
tags using identification information received from at least one of
the readers of the first set without searching to identify the tags
at the second location.
8. The method of claim 7, wherein an undesirable tag identified by
the first set is flagged such that the undesirable tag is ignored
by the second set.
9. The method of claim 7, wherein the tags pass through the first
location prior to passing through the second location.
10. The method of claim 7, further comprising: writing data to one
or more of the tags using one or more of the readers of the first
set; and verifying the data written to the one or more tags using
one or more readers of the second set using the identification
information and data received from at least one reader of the first
set.
11. A method for updating firmware of a first radio frequency
identification (RFID) reader connected to an RFID reader network
having one or more other readers, comprising: determining that a
version of firmware within the first reader is older than a version
of firmware within one or more other readers; and transferring a
copy of the firmware within the one or more other readers to the
first reader.
12. The method of claim 11, wherein the step of determining occurs
within the first reader.
13. The method of claim 1 1, wherein the step of determining occurs
within one or more of the other readers.
14. The method of claim 11, including initiating operation of the
transferred firmware within the first reader, wherein the step of
initiating reboots the first reader.
15. The method of claim 11, including initiating operation of the
transferred firmware within the first reader, wherein the step of
initiating does not reboot the first reader.
16. A method for providing connectivity between a server and at
least one of a plurality of radio frequency identification (RFID)
readers, comprising: communicatively coupling the plurality of
readers to create an RFID reader network wherein not all of the
readers are directly connected to the server; and connecting at
least one of the readers to the server to create a proxy server,
wherein the proxy server exchanges information between the server
and at least one of the readers not directly connected to the
server.
17. The method of claim 16, each of the readers utilizing an ad-hoc
on-demand distance vector routing algorithm to route messages to
other readers not directly connected to the reader.
18. A method for determining a scope of operation of one or more
radio frequency identification (RFID) readers within an RFID reader
network, comprising: determining one or more RFID tag types of a
plurality of tags; and determining the scope of operation of each
reader based upon its ability to handle the identified tag types;
wherein any reader unable to handle a specific tag type is
configured to not interact with any tags of the specific tag
type.
19. The method of claim 18, wherein any reader unable to handle all
of the tag types is disabled.
20. The method of claim 18, wherein readers unable to handle the
specific tag type do not receive information related to the
specific tag type from other readers.
21. The method of claim 18, wherein any reader unable to handle
data of a specific tag is configured to not interact with the
specific tag.
22. A method for coordinating a plurality of radio frequency
identification (RFID) readers to minimize reader noise and increase
reader sensitivity, comprising: determining one or more groups of
readers where operational fields of readers in the group overlap;
selecting a first set consisting of one reader from each group;
selecting a second set consisting of readers of each group not in
the first set; coordinating the first set to operate in a transmit
only mode; coordinating the second set to operate in a receive only
mode; synchronizing the first and second set of readers such that a
receive period of the second set coincides with a transmit period
of the first set.
23. The method of claim 22, wherein the steps of determining,
selecting, coordinating and synchronizing are performed
automatically by the readers.
24. The method of claim 22, wherein the readers are configured as a
reader network.
25. The method of claim 22, wherein operational fields of each
reader of the first set overlap at least one operational field of
readers of the second set.
26. The method of claim 22, wherein readers within the first set do
not interfere with one another during transmission.
27. The method of claim 22, wherein operational fields of readers
within the first set do not overlap.
28. A method for searching for information stored within a radio
frequency identification (RFID) reader network of RFID readers,
each including a tag cache capable of storing the information,
comprising: generating a search message containing search criteria;
sending the search message to a set of readers within the reader
network, each reader within the set searching its tag cache to
identify information matching the search criteria; receiving a
response containing the identified information from any reader
within the set having the identified information in its tag
cache.
29. The method of claim 28, wherein the step of generating is
performed within one reader of the reader network.
30. The method of claim 28, wherein the step of generating is
performed within a server connected to the reader network.
31. A method for creating a network of radio frequency
identification (RFID) readers comprising: initially including a
first RFID reader in the network; connecting additional RFID
readers to the network, wherein each of the additional readers is
connected to at least another one of the additional readers by a
peer to peer communication link, and wherein at least one of the
additional readers is also connected to the first reader by a peer
to peer communication link.
32. The method of claim 31, further comprising updating firmware of
one or more of the readers within the reader network by
transferring updated firmware from one or more other readers within
the network.
33. The method of claim 31, wherein the firmware of the one or more
additional readers is updated by transferring updated firmware from
a server connected to the reader network.
34. A system for interacting with one or more radio frequency
identification (RFID) tags, comprising: a first set of one or more
RFID readers at a first location, the first set operating to
identify at least one of the tags; and a second set of one or more
readers at a second location, the second set operating to interact
with one or more tags identified by the first set; wherein the
second set uses identification information received from at least
one of the readers of the first set and without searching to
identify the tags at the second location.
35. The system of claim 34, wherein the readers of the first and
second sets form a reader network.
36. The system of claim 34, wherein an undesirable tag identified
by the first set is flagged such that the undesirable tag is
ignored by the second set.
37. The system of claim 34, wherein the tags pass through the first
location prior to passing through the second location.
38. A system for reading radio frequency identification (RFID)
tags, comprising:. a server; at least one RFID reader not directly
coupled to the server; and at least one RFID reader directly
coupled to the server and operating as a proxy server; wherein the
readers are couple to create an RFID reader network such that the
proxy server exchanges information between the server and the at
least one reader not directly connected to the server.
39. A system for interacting with one or more radio frequency
identification (RFID) tags, comprising: a first set of one or more
RFID readers at a first location, the first set operating to
identify at least one of the tags; a second set of one or more
readers at a second location, the second set operating to interact
with one or more tags identified by the first set; and a server
connected to at least one but not all of the readers; wherein the
second set uses identification information received from at least
one of the readers of the first set and without searching to
identify the tags at the second location; and wherein the readers
couple to create an RFID reader network-wherein the proxy server
exchanges information between the server and the at least one
reader not directly connected to the server.
Description
RELATED APPLICATIONS
[0001] This application claims priority to provisional patent
application Ser. No. 60/673,692, filed Apr. 21, 2005 and
60/712,957, filed Aug. 31, 2005. The disclosures of which are
incorporated herein by reference.
[0002] This application is also related to U. S. patent application
Ser. No. 11/387,442, filed Mar. 23, 2006, entitled "RFID Reader
Operating System and Associated Architecture"; which is a
continuation-in-part of U.S. patent application Ser. No.
11/323,214, filed Dec. 30, 2005, entitled "System and Method for
Implementing Virtual RFID Tags." This application is also related
and co-filed with U.S. patent application entitled "Combined RFID
Reader and RF Transceiver." All of the aforementioned applications
are incorporated herein by reference.
BACKGROUND
[0003] Radio-frequency Identification (RFID) systems employing RFID
tags and RFID tag readers (RFID readers) are commonplace. With the
increasingly varied applications for the RFID tags, greater numbers
of readers are required across an ever-widening range of
regulatory, technological, and operating environments. Costs
associated with developing specialized, monolithic readers that
require custom manufacturing may, however, be prohibitive.
[0004] Since current RFID readers depend upon `upstream` systems
(typically involving RFID middleware running on servers) to
coordinate and manage multiple readers in a hierarchical fashion,
particularly where network topology is unknown or is dynamic, RFID
reader management is very difficult. For example, where portable
RFID readers enter and leave a network, management of such devices
is difficult. This is especially true when RFID readers within the
network have differing capabilities.
[0005] RFID middleware operates to filter and aggregate captured
RFID tag data, thereby decoupling RFID readers from applications
that utilize the captured RFID tag data. This filtering and
aggregation is typically performed in an RFIDStack within the RFID
middleware. The RFIDStack may perform entry & exit aggregation,
which estimates when each RFID tag first appeared within read range
and when that *RFID tag subsequently disappeared from read range.
The RFIDStack may also produce an aggregate count of the number of
RFID tags of a specific category that have been read. It may
further indicate a direction of movement of an RFID tag based upon
interaction among different RFID readers.
[0006] The RFIDStack may operate to aggregate data from multiple
RFID readers where applications do not require distinction between
these readers. Conversely, where an application is interested in
receiving RFID tag data from a particular RFID reader, the
RFIDStack may filter (e.g., remove) RFID tag data received by other
RFID readers for that application. Thus, RFIDStack may remove
unchanging data and events.
[0007] Use of multiple RFID readers requires that each reader
communicate with an application running on a host computer via RFID
middleware. The RFID reader typically includes a serial interface,
to facilitate wired connection to the host computer or RFID
middleware system; or it may include a wireless interface (e.g.,
WiFi). Where the RFID reader connects wirelessly to the network, it
typically includes a separate radio circuit and controller to
facilitate communications.
[0008] Configuring multiple RFID readers requires manual download
of selected RFID protocols to each RFID reader. Accordingly, where
an RFID reader encounters an unknown RFID tag type, the RFID tag
may simply remain unread.
[0009] FIG. 1 shows a prior art system 8 that reads data from RFID
tags. System 8 has two RFID readers 10(1) and 10(2) and a server
22. Server 22 includes two reader interfaces 24(1), 24(2), RFID
middleware 26 with RFIDStack 28, and two applications 30(1), 30(2).
Each RFID reader 10 includes a controller 12, an RFID radio circuit
14 and a host interface 16. Each RFID radio circuit 14 connects to
an antenna 18 used to communicate with one or more RFID tags 20.
RFID middleware 26 communicates with each application 30 and each
RFID reader 10; for example, RFID middleware 26 utilizes reader
interface 24(1) to communicate with RFID reader 10(1) and utilizes
reader interface 24(2) to communicate with RFID reader 10(2). Each
RFID reader 10 includes a host interface 16 used in communications
with server 22. RFIDStack 28 is used to aggregate and filter tag
data received from RFID tags 20 before passing the aggregated and
filtered information to applications 30, thereby decoupling
applications 30 from RFID readers 10.
[0010] RFIDStack 28 also manages configuration of RFID readers 10,
typically requiring human interaction prior to updating firmware of
controller 12. RFIDStack 28 also downloads tag protocols to each
RFID reader 10 when they are required to read a new RFID tag type.
In certain situations, RFIDStack 28 specifies operation of each
RFID reader 10 based upon RFID reader location. RFID readers 10
contain limited or no intelligence as to managing their own
configuration or operating characteristics.
SUMMARY OF THE INVENTION
[0011] In one embodiment, a method coordinates a plurality of radio
frequency identification (RFID) readers to minimize reader noise
and increase reader sensitivity. A first set of one or more of the
plurality of readers is coordinated to operate in a transmit only
mode and a second set of one or more of the plurality of readers is
coordinated to operate in receive only mode. The first and second
set are synchronized such that a receive period of the second set
coincides with a transmit period of the first set.
[0012] In another embodiment, a method distributes activity across
a network of radio frequency identification (RFID) readers. A first
set of one or more readers at a first location is configured to
identify a plurality of RFID tags and a second set of one or more
readers at a second location is configured to interact with one or
more of the tags using identification information received from at
least one of the readers of the first set without searching to
identify the tags at the second location.
[0013] In another embodiment, a method updates firmware of a first
radio frequency identification (RFID) reader connected to an RFID
reader network having one or more other readers. If it is
determined that a version of firmware within the first reader is
older than a version of firmware within one or more other readers,
a copy of the firmware within the one or more other readers is
transferred to the first reader.
[0014] In another embodiment, a method provides connectivity
between a server and at least one of a plurality of radio frequency
identification (RFID) readers. The plurality of readers are
communicatively coupled to create an RFID reader network wherein
not all of the readers are directly connected to the server. At
least one of the readers connects to the server to create a proxy
server, wherein the proxy server exchanges information between the
server and at least one of the readers not directly connected to
the server.
[0015] In another embodiment, a method determines a scope of
operation of one or more radio frequency identification (RFID)
readers within an RFID reader network. One or more RFID tag types
of a plurality of tags are determined and the scope of operation of
each reader is determined based upon its ability to handle the
identified tag types. Any reader unable to handle a specific tag
type is configured to not interact with any tags of the specific
tag type.
[0016] In another embodiment, a method coordinates a plurality of
radio frequency identification (RFID) readers to minimize reader
noise and increase reader sensitivity. One or more groups of
readers are determined where operational fields of readers in the
group overlap. A first set consisting of one reader from each group
is selected and a second set consisting of readers of each group
not in the first set is selected. The first set is coordinated to
operate in a transmit only mode and the second set is coordinated
to operate in a receive only mode. The first and second set of
readers are synchronized such that a receive period of the second
set coincides with a transmit period of the first set.
[0017] In another embodiment, a method searches for information
stored within a radio frequency identification (RFID) reader
network of RFID readers, each including a tag cache capable of
storing the information. A search message containing search
criteria is generated and sent to a set of readers within the
reader network, each reader within the set searching its tag cache
to identify information matching the search criteria. A response
containing the identified information is received from any reader
within the set having the identified information in its tag
cache.
[0018] In another embodiment, a method creates a network of radio
frequency identification (RFID) readers. A first RFID reader is
initially included in the network and additional RFID readers are
connected to the network, such that each of the additional readers
is connected to at least another one of the additional readers by a
peer to peer communication link, and such that at least one of the
additional readers is also connected to the first reader by a peer
to peer communication link.
[0019] In another embodiment, a system interacts with one or more
radio frequency identification (RFID) tags, and includes a first
set of one or more RFID readers at a first location, the first set
operating to identify at least one of the tags, and a second set of
one or more readers at a second location, the second set operating
to interact with one or more tags identified by the first set. The
second set uses identification information received from at least
one of the readers of the first set and without searching to
identify the tags at the second location.
[0020] In another embodiment, a system reads radio frequency
identification (RFID) tags and includes a server, at least one RFID
reader not directly coupled to the server, and at least one RFID
reader directly coupled to the server and operating as a proxy
server. The readers are couple to create an RFID reader network
such that the proxy server exchanges information between the server
and the at least one reader not directly connected to the
server.
[0021] In another embodiment, a system interacts with one or more
radio frequency identification (RFID) tags and includes a first set
of one or more RFID readers at a first location, the first set
operating to identify at least one of the tags, a second set of one
or more readers at a second location, the second set operating to
interact with one or more tags identified by the first set, and a
server connected to at least one but not all of the readers. The
second set uses identification information received from at least
one of the readers of the first set and without searching to
identify the tags at the second location and the readers couple to
create an RFID reader network such that the proxy server exchanges
information between the server and the at least one reader not
directly connected to the server.
BRIEF DESCRIPTION OF THE FIGURES
[0022] FIG. 1 shows a prior art system for reading data from RFID
tags.
[0023] FIG. 2 shows one exemplary system for RFID reader to reader
communication, in accord with an embodiment.
[0024] FIG. 3 shows exemplary system architecture utilized within
each RFID reader of FIG. 2.
[0025] FIG. 4 shows exemplary firmware architecture illustrating an
application layer, an application software interface, a hardware
abstraction layer and an operational platform.
[0026] FIG. 5 shows exemplary functionality of the network manager
of FIG. 4, including discovery, authentication, protocol security,
timing coordination, version/capability, offline detection and a
version/capability functionality.
[0027] FIG. 6 shows the coordinator of FIG. 4 in further
detail.
[0028] FIG. 7 is a flowchart illustrating one method for
coordinating a plurality of RFID readers to minimize RFID reader
noise and increase RFID reader sensitivity.
[0029] FIG. 8 shows the reader manager of FIG. 4 in further
detail.
[0030] FIG. 9 shows the data manager of FIG. 4 in further
detail.
[0031] FIG. 10 is a block diagram illustrating one exemplary swarm
of three RFID readers within an RFID reader network.
[0032] FIG. 11 is a flowchart illustrating one exemplary method
1300 for coordinating a plurality RFID readers to minimize RFID
reader noise and increase RFID reader sensitivity.
[0033] FIG. 12 is a flowchart illustrating a method 1400 for
distributing activity across a network of RFID readers.
[0034] FIG. 13 is a flowchart illustrating a method for providing
connectivity between a server and at least one of a plurality of
radio frequency identification (RFID) readers.
DETAILED DESCRIPTION OF THE FIGURES
[0035] A radio frequency identification (RFID) reader is used to
identify RFID tags within its operational field. The operational
field of a reader is the area within which the reader may
successfully communicate with tags. This identification process
typically involves `searching` for the tags using an anti-collision
protocol (known in the art) since only one tag may transmit
information to the reader at a time. The reader may, for example,
read identification information from each tag within its reading
range. This identification information includes a unique
identification number (UID) that is unique to the tag. When several
tags are within the operational field of the reader, this
identification process, using the anti-collision protocol, may take
a significant amount of time.
[0036] Once the tags are identified, individual tags may be
addressed using their UIDs. For example, an reader may perform
additional operations (e.g., read, write and lock) on a tag within
its operational field by first transmitting a `select` command,
including the UID of the tag, setting the identified tag into a
communicative state. The reader may then utilize additional
commands (e.g., write block, read block, lock block, etc) to
control or access data of the selected tag. For example, the reader
may read data from one or more memory blocks of the selected tag
using a read block command. In another example, the reader may
write data to one or more memory blocks of the selected tag using a
write command. In another example, the reader may prevent further
changes to one or more memory blocks of the selected tag using a
lock command. Thus, operations performed upon tags by the reader
typically involve first selecting the tag using its UID and then
reading or writing data from and to the selected tag.
[0037] In another example, if interaction with certain tag is not
desired, the reader may transmit a `Stay Quiet` command, including
the UID of the certain tag, setting the tag into an uncommunicative
(i.e., no-transmit) mode.
[0038] FIG. 2 shows one exemplary system 100 for RFID reader to
reader communication. In particular, FIG. 2 shows a server 106 and
three readers 102(1), 102(2) and 102(3), each with an antenna
104(1), 104(2) and 104(3), respectively. In operation, reader
102(3) communicates directly with server 106, reader 102(3)
communicates with reader 102(2), which in turn communicates with
reader 102(1). Readers 102(1), 102(2) and 102(3) collectively form
an RFID network 105, in this example. Accordingly, server 106
communicates with reader 102(2) via reader 102(3), and communicates
with reader 102(1) via readers 102(3) and 102(2). Readers 102 are
shown interacting with five exemplary RFID tags 108.
[0039] Each communication path 110, 112 and/or 114 may be a wired
or wireless connection. In one embodiment, communication paths 110
and 112 are implemented through combined RFID and RF antenna
technology that allows antenna 104 to interact with tags 108 and
other readers, as disclosed in U.S. patent application Ser. No.
______, titled "Combined RFID Reader and RF Transceiver."
[0040] FIG. 3 shows exemplary system architecture 200 that may be
utilized within each reader 102 of FIG. 2. Architecture 200 is
illustratively shown with an operational platform 208, a hardware
abstraction layer 210, an application software interface 212 and an
application layer 214. Operational platform 208 is formed by
hardware 202, a radio 204 and an optional operating system 206,
upon which application software of reader 102 runs.
[0041] Operating system 206, if included, may be realized by a
variety of operating systems including operating systems sold under
the trade names of Linux, WinCE, Symbian, and VxWorks.
[0042] Hardware abstraction layer 210 includes platform-dependent
drivers that effectuate low-level functions that interact with
hardware 202, radio 204 and, optionally, operating system 206. For
example, hardware abstraction layer 210 may implement alterations
of the reader in accordance with specific protocols (e.g., a
message authentication code (MAC), physical layer and/or command
syntax) and/or other operational characteristics defined by data
within configuration and data files. These drivers may be optimized
for hardware 202, radio 204 and operating system 206.
[0043] Application software interface 212 includes
platform-independent libraries that provide, via a common API,
certain functions associated with effectuating the specific
protocols and/or operational characteristics of reader 102. In
addition, application software interface 212 may provide many
functions associated with reading RFID tags. Advantageously, these
library functions are portable across multiple reader platforms
because they are independent of specific hardware (e.g., hardware
202), operating systems (e.g., operating system 206) and radio
hardware (e.g., radio 204) that reside within platform 208 of the
exemplary architecture.
[0044] Application layer 214 defines the functionality for
implementing reader to reader communication. In one example of
operation, application code within application layer 214 makes one
or more calls to lower level library and driver functions within
application software interface 212 and hardware abstraction layer
210.
[0045] FIG. 4 shows exemplary firmware architecture 300
illustrating an application layer 352, an application software
interface 336, a hardware abstraction layer 318 and an operational
platform 302. Application layer 352 may represent application layer
214 of FIG. 3; application software interface 336 may represent
application software interface 212; hardware abstraction layer 318
may represent hardware abstraction layer 210; and platform 302 may
represent platform 208. Application layer 352 shows exemplary
application code including a coordinator 354, a reader manager 356
and a data manager 358 that cooperate with a network manager 360 to
facilitate reader to reader communication.
[0046] Application software interface 336 is illustratively shown
with a reader protocol 338, a reader configuration 340,
cryptography 342, code loader 344, a baseband 346 and a tag
protocol 348. Hardware abstraction layer 318 is illustratively
shown with a stream 320, sockets 322, sensors & I/O 324, a user
interface 326, a block I/O 328, system 330 and a RFID radio
332.
[0047] Platform 302 includes a host interface 304, peripherals 306,
a user interface 308, memory 310, a processor 312, a power supply
314 and an RFID radio 316. It should be recognized that this is
only exemplary of the type of hardware that may be part of a
platform. In an alternative embodiment for example, platform 302
may include an operating system. In another embodiment, platform
302 may not include user interface 308.
[0048] Drivers 318 provide interface handling for hardware of
platform 302 through a driver Application Programming Interface
(API) 334, illustratively shown as bi-directional arrow 334,
between application interface 336 and hardware abstraction layer
318. Specifically, API 334 is portable and platform independent
whereas driver functions within hardware abstraction layer 318 may
be dependent upon platform 302. As a consequence, a developer need
only learn API 334 to be able to create application code applicable
to a variety of platforms.
[0049] Stream 320 includes drivers that provide hardware interface
handling for communication with a host (e.g., server 106, FIG. 2)
or other peripheral devices. For example, stream 320 may include
drivers for TTL, I.sup.2C, SPI, USB and RS-232 interfaces.
[0050] Sockets 322 includes drivers that enable task management,
port sharing among multiple applications and networking management
functionality. Some examples of socket drivers include Ethernet,
Wi-Fi, Zigbee, Bluetooth, etc.
[0051] Sensors and I/O 324 includes drivers that provide hardware
interface handling for communication with sensors and other I/O
devices that connect to hardware of platform 302. For example,
sensor and I/O 324 may include drivers for temperature sensors,
current sensors, voltage sensors and general purpose I/O
(GPIO).
[0052] User interface 326 includes drivers that provide hardware
interface handling for communication with user interface 308 of
platform 302. For example, the user interface 326 may include
drivers for touch screen hardware, pointing devices, biometric
security devices and keyboards, etc.
[0053] Block I/O 328 includes drivers that enable communications
with memory 310 and other platform resources (e.g., hard drives,
busses, ROM, RAM, EEPROM, etc.).
[0054] System 330 includes drivers that provide an interface to
various system components of platform 302. For example, system 330
may include drivers for timers, power management and interrupt
handling and control of platform 302.
[0055] RFID radio 332 includes drivers that provide an interface to
a variety of radio types (e.g., analog front ends (AFEs)) enabling
communication with a variety of different radio hardware (e.g.,
RFID radio 316). In addition, RFID radio 332 drivers may enable
data-defined aspects of operation at the physical layer to be
effectuated. For example, RFID radio 332 drivers may carry out
transmission and reception of signals in accordance with a physical
layer protocol defined by data in a data file. Thus, if a user
desires to upgrade the RFID radio 316, only RFID radio 332 drivers
may require changing.
[0056] Application layer 352 accesses application software
interface 336 via a portable and platform-independent API
(illustratively represented by a two way arrow 350 in FIG. 4).
[0057] Reader protocol 338 may include functions that implement
low-level operations required by host communication protocols. For
example, reader protocol 338 may include one or more of: a cyclical
redundancy code (CRC) library, a parity calculation library,
forward error correction algorithms, message data parsers, ASCII to
hexadecimal encoders and decoders, host-protocol command
interpreters, host-protocol command executors and host-protocol
error handlers.
[0058] It should be recognized that a reader-side implementation of
a host-to-reader communication protocol may reside in reader
protocol 338, application layer 352, or both. For example, an
application may reside within application layer 352 to facilitate
calls to functions of reader protocol 338, as well as other
libraries of application software interface 336 and hardware
abstraction layer 318.
[0059] Reader configuration 340 includes functions that enable
applications within application layer 352 to control the inner
workings of RFID reader 102. For example, reader configuration 340
may include functionality to control one or more of: schedule,
event, interrupt and priority handlers.
[0060] Cryptography 342 includes functionality for handling
security and cryptographic data processing that may be required
relative to many aspects of RFID reader 102. For example,
cryptography 342 may include one or more of: tag-reader
cryptography, reader-host cryptography, user data security, network
data security and hardware security management.
[0061] A variety of cryptographic techniques may be utilized
including private key algorithms and propriety security algorithms
(e.g., security algorithms marketed under the trade names of
Philips, Mifare, Inside Contactless, Pico Pass, Infineon, My-d,
Atmel, CryptoRF, etc.). In addition, public key algorithms may be
utilized including PGP and commonly known algorithms such as DES,
3-DES and RSA, for example.
[0062] Tag protocol 348 includes functions for defining one or more
of: the air interface (i.e., the protocols between RFID radio 316
and RFID tags), initialization and anti-collision protocols and
procedures, and a data transmission method utilized for forward and
return links. The air interface describes characteristics of
baseband radio functionality and RF symbol definitions, which
define how data bits are sent and received through the air via the
RFID radio 316.
[0063] The initialization and anti-collision procedures describe
how reader 102 and tags 108, FIG. 2, interact to communicate unique
or repeated tag identification numbers from one or more of tags 108
to reader 102. The data transmission method defined by tag protocol
348 describes how the forward and return link messages are
constructed, encoded and recoded to perform basic RFID transactions
including, for example, identifying, reading and writing tags.
[0064] In some variations, tag protocol 348 is segregated into
three general classes of functions: agnostic functions, which
provide the highest level of abstraction so that applications
within application layer 352 may operate independently of the tag
types that reader 102 interacts with; protocol functions, which
allow applications to utilize a particular tag type without concern
for implementations specific to RFID tag manufacturers; and
manufacturer functions, which enable applications to access
manufacturer-specific features of a standards-based tag and utilize
independent tag manufacturers proprietary tag protocols.
[0065] In the context of high frequency (HF) air interfaces (e.g.,
13.56 MHz), tag protocol 348 may support a variety of protocols
including ISO15693-2, ISO18000, ISO14443-2 Type A, ISO14443-2 Type
B, Phillips ICode SL1, Texas Instruments Tag-it HF and TagSys C210,
C220 and future protocols. With respect to ultra high frequency
(UHF) air interfaces (e.g., 860-960 MHz), tag protocol 348 may
support protocols including ISO18000-6A, ISO18000-6B, ISO 18092,
EPC Class 0/0+, EPC Class 1, EPC Class 1 Gen 2, and other protocols
yet to be developed.
[0066] Baseband 346 includes baseband functions that are portable
across disparate hardware chips, processors and operating systems
(if present). These baseband functions handle low-level interaction
between tag protocol 348 and drivers of RFID radio 332. In
addition, baseband 346 includes functionality for digitally
defining RF characteristics of individual bit symbols and
presenting the defined symbol definitions to the low-level,
protocol specific, drives of RFID radio 332, thereby enabling tag
protocol 348 functions to receive only binary code (i.e., ones and
zeros).
[0067] Code loader 344 includes functions that facilitate loading
of new code and/or data into reader 102. For example, code loader
344 may facilitate loading of programs into application layer 352,
loading of new drivers into hardware abstraction layer 318, loading
new configuration data or default values for reader 102 into memory
310 and adding new functions to application software interface
336.
[0068] It should be recognized that the specific hardware, drivers,
libraries and applications described with reference to FIG. 4 are
exemplary only and that certain functions may be omitted, combined
or enhanced without departing from the scope of the present
invention.
[0069] Networking RFID Readers
[0070] As shown in FIG. 2, readers 102(1), 102(2) and 102(3) may be
communicatively connected to form RFID reader network 105. FIG. 5
shows exemplary functionality of network manager 360, FIG. 4,
including discovery 402, authentication 404, protocol security 406,
timing coordination 408, version/capability 410, offline detection
412 and a version/capability structure 414. Network manager 360 is,
for example, a distributed application implemented across networked
readers 102(1-3) and operates to create and maintain reader network
105.
[0071] Continuing with the example of FIG. 2, assume readers 102(2)
and 102(3) are connected to form reader network 105 and that RFID
reader 102(1) is not yet part of reader network 105. Within reader
102(1), discovery 402 includes algorithms for discovering other
readers (e.g., readers 102(2) and 102(3)) and also algorithms that
allow discovery of reader 102(1) by other readers (e.g., reader
102(2) and reader 102(3)). Discovery may occur at any time (e.g.,
when a reader is first connected to a network, when a reader loses
and regains power, etc.).
[0072] In one embodiment, network manager 360 within reader 102(1)
utilizes algorithms of discovery 402 to periodically send a
`beacon` message to facilitate detection of reader 102(1) by other
readers (e.g., readers 102(2) and 102(3)). For example, each
established reader within reader network 105 may periodically send
out a `beacon` message containing their network location/address.
An reader joining reader network 105 would thus, over time, learn
the location/address of each of its peers (i.e., each reader within
reader network 105).
[0073] In another embodiment, reader 102(1) generates a
`peerRequest` message and broadcasts it on reader network 105.
Reader 102(1) then awaits replies from readers already connected to
reader network 105. These replies may contain information about the
replying readers and/or information about readers known to the
replying readers. An exemplary discovery sequence using XML
messages is shown below:
[0074] Reader broadcast: TABLE-US-00001 <peerRequest/>
[0075] Each peers to Reader: TABLE-US-00002 <peer name="Front
Door"/> <myPeers> <peer name="Jim's Office"
address="192.168.1.93"/> <peer name="Boyd's Office"
address="192.168.1.12"/> </myPeers>
[0076] In another example of discovery, a central authoritative
source (e.g., a Universal Description, Discovery and Integration
(UDDI) server, a Lightweight Directory Access Protocol (LDAP)
server or a proprietary server) operates as a directory of readers.
In this example, each reader knows the location/address (e.g.,
Ethernet address or web URL) of the central authoritative source
and may know authentication/authorization information associated
with the central authoritative source required for access. To join
a reader network, a reader may query (using authentication if
necessary) the central authoritative source for the
location/address of its peers. An exemplary reader message exchange
with a XML message based proprietary server is shown below:
[0077] Reader to server: TABLE-US-00003 <peerReguest/>
[0078] Server to reader: TABLE-US-00004 <peers> <peer
name="Back Door" address="192.168.1.34"/> <peer
name="Conveyer One" address="192.168.1.35"/> <peer
name="Shipping" address="192.168.1.36"/> </peers>
[0079] Continuing with the example of FIG. 2, once discovery of
reader 102(1) occurs (or once reader 102(1) discovers one or more
of readers 102(2) and 102(3)), network management 360 may utilize
algorithms of authentication 404 to identify and authenticate
reader 102(1) to its peers within reader network 105 (and
optionally server 106). For example, network manager 360 within
reader 102(2) may interact with network management 360 within
reader 102(1) to effect authentication, ignoring readers that fail
to authenticate, thereby preventing unauthorized access to reader
network 105. Further, upon successful authentication, network
management 360 within each reader 102 may utilize algorithms of
protocol security 406 to ensure reader to reader communication is
secure.
[0080] Reader authentication by another reader may be implemented
using an authentication scheme similar to current tag
authentication schemes. For example, assume reader 102(1) and
reader 102(2) are to authenticate each other; both reader 102(1)
and reader 102(2) possess a known `key` (e.g. an X.509
certificate). Reader 102(1) generates a random number and sends it
to reader 102(2). Reader 102(2) utilizes its key to `hash` (using a
common algorithm) the random number and generate a `hash value`,
which it sends back to reader 102(1). Reader 102(1) also generates
a hash value of the random number using its key, and compares this
hash value to the hash value returned by reader 102(2); is the two
hash values are identical, reader 102(1) assumes reader 102(2) has
the same key. Reader 102(2) may then generate a random number and
send it to reader 102(1). Reader 102(1) generates a hash value,
using the common algorithm and its key, and returns this hash value
to reader 102(2). Reader 102(2) also generates a hash value of the
random number using its key, and compares this hash value to the
returned hash value from reader 102(1). If these hash values are
identical, reader 102(2) knows that reader 102(1) has the same key,
and authentication is complete. Additional iterations of generating
random numbers and hash values may occur to increase confidence of
authenticity.
[0081] A session key may be generated, utilizing a common algorithm
to hash one or more of the random numbers exchanged between two
readers during authentication and their shared key. This session
key may be used for message encryption and may be used to generate
a cryptographic MAC, used to authenticate a message.
[0082] Using the shared key method of the above authentication
method, only readers that possess the `key` may be successfully
authenticated; readers that are not configured with this key cannot
join the reader network. If the key is to be changed periodically
for security reasons, each reader of the reader network must be
updated with a new key. An alternative to the above authentication
method that does not utilize a shared key, may therefore be
employed.
[0083] Security Assertion Markup Language (SAML) is an XML standard
for exchanging authentication and authorization information between
an identity provider and a service provider. Each reader (e.g.,
reader 102, FIG. 2) wishing to join a reader network (e.g., reader
network 105) is required to provide a SAML assertion. The readers
obtain this SAML assertion from a mutually agreed upon
authentication source (e.g. a LDAP server, ideally the same central
authoritative source used for discovery). One exemplary SAML
assertion is shown below: TABLE-US-00005 <saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1"
MinorVersion="1" AssertionID="..."
Issuer="https://ldapserver/saml/"
IssueInstant="2006-03-16T17:05:37.795Z"> <saml:Conditions
NotBefore="2006-03-16T17:00:37.795Z"
NotOnOrAfter="2006-03-17T17:10:37.795Z"/>
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2006-03-16T17:05:17.706Z">
<saml:Subject> <saml:NameIdentifier
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:string">
Boyd's Reader </saml:NameIdentifier>
<saml:SubjectConfirmation> <saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:artifact
</saml:ConfirmationMethod> </saml:SubjectConfirmation>
</saml:Subject> </saml:AuthenticationStatement>
</saml:Assertion>
[0084] In one exemplary use of an SAML assertion, a joining reader
(e.g., reader 102(1)) supplies a token (e.g. a password) to a
central authentication source (e.g., a central authoritative source
107 within server 106) to prove its identity. If the token is
matched by the central authentication source, the central
authentication source generates and sends a SAML assertion to the
joining reader. The joining reader may then supply this SAML
assertion to other readers within the reader network to prove
authentication. Readers receiving this SAML assertion may verify
authenticity of the joining reader by sending the received SAML
assertion to the central authentication source which replied to the
verifying reader indicating its validity. As shown in the example
above the SAML assertion may include an expiry time (e.g., see the
entry NotOnOrAfter). Thus readers may be required to
re-authenticate after expiration of their SAML assertions.
[0085] The SAML assertion only provide proof of authentication it
does not secure messages during actual transport. A transport
security mechanism, such as Secure Sockets Layer (SSL) and
Transport Layer Security (TLS), may be used for secure
communication between readers.
[0086] Each reader within the reader network knows the
location/address of each of its peers. If two readers that wish to
communicate are directly connected, messages may be exchanged
directly by the readers. If two readers that wish to communicate
are not directly connected, routing of messages may be based upon
an Ad-Hoc On-demand Distance Vector routing algorithm (known in the
art).
[0087] Once a reader network is established, capability and version
information (hardware and software) for each networked reader is
exchanged. For example, network manager 360 within reader 102(1)
may utilize algorithms of version/capability 410 to interrogate
hardware and software of reader 102(1) to construct host version
and capability structure 414. Information from host version and
capability structure 414 may then be shared with other readers
within the reader network such that overall capability of the
reader network is known to coordinator 354, reader manager 356 and
data manager 358 within each reader.
[0088] One exemplary capability exchange mechanism is based upon
the firmware version of the readers. Each reader knows a priori
which capabilities are available for each firmware version, and may
assume that later firmware versions support everything that earlier
firmware versions support. In one exemplary capability exchange
using a XML based message system, a reader may send a capability
message to a second reader, as shown below:
[0089] Reader to Reader: TABLE-US-00006 <capabilities>
<firmware version="1.0"/> </capabilities>
[0090] This capability message may be extended by adding
information about specific functions/items supported by the reader.
For example:
[0091] Reader to Reader: TABLE-US-00007 <capabilities>
<firmware version="1.0"/> <Regions> <USA/>
<EU/> </Regions> <Bands> <HF/>
</Bands> <AirInterfaces> <ISO15693/>
</AirInterfaces> </capabilities>
[0092] In the above exemplary capability message, the sending
reader indicates to its peers that it cannot handle UHF tags and
therefore should not receive information relating to UHF tags
(i.e., for tag caching).
[0093] In another example, a reader in a reader network reads one
or more tags located upon a palette and determines that products
associated these tags are "cold chain" products and require
handling by readers with time stamping and security capabilities.
Readers that do not have these capabilities are therefore
instructed, for example through use of a control message, to stay
quiet, allowing readers with time stamping and security
capabilities to operate upon these tags without interference.
[0094] If a reader is determined to have an older firmware version
(e.g., through analysis of its capability message by a receiving
reader), then its peers may either a) send it a newer firmware
version, b) continue using it with knowledge of its limitations, or
c) not use the reader at all if the firmware/hardware version is
such that it is unable to perform the required functionality.
[0095] The reader to reader protocol and functionality disclosed
herein operates as a peer to peer network and does not utilize a
`master` or `arbiter`. However, as described above, a central
authoritative source may be utilized to store the location/address
of each reader within a directory.
[0096] Within a reader, network manager 360 may utilize algorithms
of offline detection 412 to determine when one or more readers
within the reader network disconnect. For example, a portable or
handheld reader may periodically move out of range of a wireless
network link, thereby disconnecting from the reader network.
[0097] If one or more readers disconnect (go offline) from the
reader network, no detriment occurs to the network unless these
readers were actively performing work. For example, a portable
reader may frequently join and leave a reader network without
affecting operation of other readers within the reader network.
However, where a first reader operates to identify tags as they
enter a warehouse, a second reader reads a manifest from the tags
and a third reader writes information to the tags, operation of any
of the first, second and third readers within the reader network
may be critical because of the cooperation of these readers;
incorrect operation may require immediate attention and an alarm
may be raised.
[0098] Determination that a reader is offline may be made by its
peers through lack of response to direct and indirect transactions
with the reader. In a beaconing system where each RFID reader
broadcasts a "heart beat" message every few seconds, a more
deterministic assessment of RFID reader status may be known. For
example, one or more readers within the reader network may
determine, though use of timers, that a particular reader has
stopped transmitting the `heart beat` and is therefore disconnected
from the reader network.
[0099] Upon determining that the reader as disconnected from the
reader network, remaining readers may initiate a discovery process
to attempt to `repair` the reader network. If the disconnected
reader results in orphaned readers (i.e., one or more readers
unable to connect to the reader network without operation of the
disconnected reader), an alarm may be raised requesting corrective
action.
[0100] When a disconnected reader rejoins the reader network, a
synchronization process may occur to ensure integrity of data
within the reader network. For example, if readers within the
reader network share tag cache information then the cache of the
rejoining reader may be updated with any data captured after it
disconnected and, if the rejoining reader continued to operated
(e.g., reading tags) while disconnected, the new information within
its cache may be distributed throughout the reader network.
[0101] In one exemplary embodiment, the tag cache within each
reader is implemented using a Berkeley DB database and a Berkeley
DB synchronization method is utilized to synchronize the cache;
other proprietary methods (e.g. XML messages) may be used for cache
synchronization without departing from the scope hereof.
[0102] In a desired embodiment, if a reader's persistence in the
reader network is transient, the reader should not connect as an
active routing `node` within the network, but simply connect as a
leaf node.
[0103] Coordination
[0104] In FIG. 6, coordinator 354 is illustratively shown with time
service 502, operational service 504 and coordinated sampler 506.
Coordinator 354 facilitates synchronization of timing and
capability between a plurality of networked readers (e.g., readers
102, FIG. 2). In one example of operation, time service 502 of
reader 102(3) interacts with time services 502 of readers 102(1)
and 102(2) to ensure that clocks within each reader 102 are
synchronized. For example, time service 502 may utilize network
manager 360, FIG. 4, to effect communication with other networked
readers 102. By synchronizing clocks, readers 102 that have
overlapping operational fields can coordinate read and write
operations as described below.
[0105] In one example of clock synchronization, each reader queries
a Network Time Protocol (NTP) server, thereby obtaining an accurate
time. In another example, where an NTP server is not available (or
is not accessible by all readers), as readers join the reader
network they are synchronized with the reader network time. If a
first reader has access to an NTP server, it may synchronize its
clock to that of the NTP server and, as other readers join the
reader network, they synchronize with the reader network time
obtained from other readers established within the reader network.
Where an NTP server is not available at all, the reader network
time may be based upon a clock of the first reader forming the
reader network. Time synchronization within the reader network may
be based upon methods used by NTP servers to ensure low skew
between clocks of various readers in the reader network. Further,
each reader within the reader network may periodically
resynchronize to maintain clock accuracy.
[0106] Operational service 504, within coordinator 354, operates to
coordinate operation within reader network 105. For example,
readers 102 may be identified as a first group of readers with
overlapping operational fields. A first set may include reader
102(2) which is selected for transmit only functionality, while a
second set may include readers 102(1) and 102(3) for operation with
receive only functionality. Such coordination may minimize reader
noise and increase system 100 sensitivity for reading tags 108.
[0107] The operation (e.g. identifying, selecting, reading,
writing, killing, etc.) to be performed by a reader may be
determined a priori by a user of the reader or their agent (e.g. a
systems integrator) during installation of the reader. Reader
location often determines the operation selected for the reader.
For example, where a first reader is located at an entrance to a
warehouse, its operation may be defined as identifying tags
attached to products that enter the warehouse; the first reader
thus searches for tag UIDs as products enter the warehouse. A
second reader may be located at the start of a conveyor belt
transporting products within the warehouse and its operation may be
defined as reading manifests (e.g., containing information relating
to the product such as manufacturer, date made, distribution chain
to date, etc.) from the tags previously identified by the first
reader. The second reader may also perform writes to the RFID tags.
A third reader may be located at the end of the conveyor belt and
its operation defined as writing additional and/or updated
information (e.g., the operation performed to the product within
the warehouse and/or additional distribution information) to the
manifest stored within the tags read by the second reader. The
third reader may also operate to read and verify-data written to
the RFID tags by the second reader. See also the example of FIG. 9
and associated description.
[0108] FIG. 7 is a flowchart illustrating one method 530 for
coordinating a plurality of readers to minimize reader noise and
increase reader sensitivity. In step 532, groups of readers where
reader to reader transmission interference occurs within readers of
the group are determined. In one example of step 532, an installer
of the reader system, identifies one or more groups of readers that
are proximate, having overlapping operational fields, and may
therefore interfere with one another during simultaneous
transmissions. Using the example of FIG. 2, if readers 102(1),
102(2) and 102(3) have overlapping operational fields, a group
including readers 102(1), 102(2) and 102(3) is identified in step
532.
[0109] In step 534, a first set consisting of one reader from each
group determined in step 532 is selected. In one example of step
534, reader 102(2) is selected for the first set. In step 536, a
second set including remaining readers of each group not in the
first set is selected. In one example of step 536, readers 102(1)
and 102(3) are selected for the second set. In step 538, the first
set of readers is coordinated to operate in transmit only mode. In
one example of step 538, reader 102(2) is coordinated to operate in
transmit only mode. In step 540, the second set of readers is
coordinated to operate in a receive only mode. In one example of
step 540, readers 102(1) and 102(3) are coordinated to operate in
the receive only mode. In step 542, the first ands second set of
readers are synchronized such that a receive period of the second
set coincides with the transmit period of the first set. In one
example of step 542, the read period of readers 102(1) and 102(3)
is synchronized with the transmit period of reader 102(2).
[0110] In one example, where a number of readers are in close
proximity to one another such that simultaneous transmissions
causes interference and reduces sensitivity of one or more of the
readers, coordination of the readers to operate in a synchronized
manner (i.e., coordinating when each turns its radio transmitter on
and off) may eliminate cross reader interference. In yet another
example, each reader may select a different frequency slot for
operation thereby also eliminating cross reader interference.
[0111] In one embodiment, each reader may automatically determine
its proximity to one or more other readers. For example, the reader
may sense signal strengths from other readers within the reader
network. Theses readers may then cooperate to select a desired
operational mode to reduce reader interference.
[0112] Each reader may contain the following information relating
to its physical location, illustratively shown as a data structure:
TABLE-US-00008 struct _reader { char* name; char* location; ...
};
The name and location strings may, for example, have meaning to a
user selecting operation of each reader. Coordinated Sampler 506
utilizes synchronized clocks of readers within the reader network
to distribute read and write activity across the reader network,
thereby optimizing coverage within a specified sample period and
minimizing power consumption. Coordinated sampler 506 may also
synchronize sampling of one or more peripherals connected to one or
more readers within the reader network; the one or more readers
may, for example, include hardware for sensing temperature, battery
voltage, humidity, etc.
[0113] In one example, a plurality of readers may operate as an
assembly line. A first reader reads the ID, a second reader reads
information from the tags, and a third reader writes information to
the tags. In another example, a plurality of readers operate as a
pipeline to select, read and write to tags. Each of the readers is
coordinated to perform each of select, read and write tasks on
separate tags. These operations on the tags may also be performed
out of order once UIDs of the tags are known and distributed to the
other readers within the reader network. In another example,
invalid tags may be flagged within each reader to be ignored for
select, read and write operations, thereby protecting against rogue
tags introduced into the tag population. In another example, a
plurality of readers may be used to determine (e.g., by
triangulation) the location of one or more tags.
[0114] Management
[0115] FIG. 8 shows reader manager 356 of FIG. 4 illustrating
functionality of code update 602, script update 604 and proxy
server 606. Reader manager 356 may utilize functionality of code
update 602 to request a more recent code or configuration file
update from another reader and/or from a server (e.g., server 106,
FIG. 2). In one example of operation, reader 102(1) interacts with
reader 102(2) and host version and capability structure 414 of each
reader is exchanged. Upon analysis of host version and capability
structure 414 received from reader 102(2), reader manager 356
within reader 102(1) determines that reader 102(2) is operating
with a later version of software than its host. Reader manager 356
thus utilizes functionality of code update 602 to load updated
software from reader 102(2). In one example, the updated software
is transferred within the CDATA section of a XML message. In
another example, the updated software is transferred as a FTP-like
binary transfer.
[0116] In one example of operation, reader 102(1) may load the
updated software while continuing tag operations. For example,
reader 102(1) may perform a read using the earlier version of
software and then use the updated software on a subsequent read.
Alternatively, reader 102(1) may cease all tag operations while the
updated software is being transferred and re-boot prior to resuming
tag operations.
[0117] An optimal time for identifying a need for, and loading,
updated software is when a reader joins the reader network.
Alternatively, a predetermined "quiet" time (e.g., after business
hours) may be selected for identifying readers with older software
and for loading updated software to these readers if necessary.
[0118] Ideally, each reader keeps a "golden" copy of its firmware
within a local non-volatile storage, such that, if anything should
go wrong during an update, the reader simply reverts to its golden
copy. For example, a watchdog timer/supervisor may be utilized to
resets the reader if the updated software does not operate
correctly and the `boot-loader` would revert to operation with the
golden copy of the software, rather than the updated software,
thereby restoring original functionality of the reader.
[0119] In particular, after loading a firmware update, the reader
may reboot to begin using the new firmware. Initially it would
perform a BIST/POST to ensure everything is in working order. The
reader network learns if the updated software is operational when
the reader rejoins the reader network and sends its capabilities
message containing the firmware version of the updated software.
Optionally, if the updated software failed to run, the reader,
operating from its golden copy, would issue an alert to the user
requesting further investigation.
[0120] Scripts are utilized within readers to perform certain
business logic activities. Each reader may, for example, utilize
Python Scripts. Reader manager 356 may utilize functionality of
script update 604 to transfer scripts to or from itself from or to
other readers within the reader network. For example, a user may
create Python scripts to implement various business logic
processes. The need for an-update would be initiated by the user
through management messages.
[0121] Referring again to the example of FIG. 2, tag information
received by reader 102(2) first passes to reader 102(3) and then to
server 106. In particular, reader manager 356 utilizes
functionality of proxy server 606 within reader 102(3) to relay
information between reader 102(2) and server 106.
[0122] Since each reader has a unique identifier, messages may be
addressed to specific readers using their name or another unique
identifier generated by the protocol (e.g. a hash of the reader
name and its `P address and/or the order in which it joined the
network).
[0123] Server 106 detects available readers by issuing a management
message:
[0124] Server to network: TABLE-US-00009 <queryPeers/>
This causes each reader connected to the reader network to respond
to the server with its list of known peers:
[0125] Each individual reader to server: TABLE-US-00010 <peer
name="Boyd's reader"> <peers> <peer name="Ben's
Reader"/> <peer name="Intern Reader"/> </peers>
</peer>
[0126] Reader manager 356 may also implement a power management
policy within the reader. This power management policy may be
defined by a user or installer of the reader. In one example, when
a reader joins a reader network, reader manager 356 within the
reader may adopt power management policies employed by the reader
network.
[0127] Data Manager
[0128] FIG. 9 shows data manager 358 of FIG. 4 and illustrates
functionality of tag data 702 and search and locate 704. In one
example of operation, data manager 358 utilizes functionality of
tag data 702 to share tag cache entries with one or more other
networked readers. In another example of operation, data manager
358 utilizes functionality of tag data 702 to share tag cache data
with one or more other networked readers. Tag data 702 operates to
maintain synchronicity of the tag cache within the reader with tag
caches of other readers within the reader network.
[0129] Further details of tag cache operation may be found in U.S.
patent application Ser. No. ______, titled "System and Method for
Implementing Virtual RFID Tags". In general, a tag cache is stored
locally on each reader. A typical tag cache entry is illustratively
shown in the following data structure: TABLE-US-00011 struct
_tagData_t { tagData_t* next; uint16_t start; uint8_t data[32];
uint32_t dirty; uint32_t inuse; }; struct _tag_t { air_interface_t
airInterface; char* uid; uint8_t uidLength; time_t firstSeen;
time_t lastSeen; uint32_t firstSeenBy; uint32_t lastSeenBy;
tagData_t* data; };
[0130] If a reader loses contact with the reader network, it may
continue operation on any tags that enter its operational field,
storing the tag information within the tag cache. Once the reader
rejoins the reader network, any accumulated information may be
disseminated to other readers and the server.
[0131] If tags enter and exit the reader's operational field
rapidly (e.g., they are located upon a fast moving conveyer), there
may be insufficient time to query an upstream source (e.g., a
server) for desired operations upon the tag. The tag cache allows
the reader to queue operations for later consumption by the
server.
[0132] In one example of operation, data manager 358 utilizes
functionality of search and locate 704 to search for a specific
value (e.g., an tag UID or data value) within a tag cache and, if
located, returns its reader ID and other related information of the
located value to a requesting device (e.g., another reader, a
server or a user). In particular, server 106, for example, issues a
message, indicating that it requires information relating to a
specific tag ID, to a reader network. In another example, server
106 issues a search message to reader 102(3). Data manager 358,
within reader 102(3), utilizes functionality of search and locate
704 to search local tag cache information for the specific tag ID
and may also relay the search messages to reader 102(2) thereby
furthering the search through the reader network. Thus,
functionality of search and locate 704 enables a reader, or a
server, to find a specific value across all networked readers and
identify which reader last interacted with a specific tag.
[0133] Search requests may be broadcast to every reader connected
to the reader network. If a user has prior knowledge of the
readers, the search may be targeted for a specific reader or group
of readers. In general, the tag cache (see the exemplary _tag_t and
_tagData_t structures above) within the targeted readers would be
searched. The following examples illustrate some of the types of
data that can be the subject of a search.
[0134] Searching for specific tags or tag types:
[0135] Search for all ISO15693 type RFID tags: TABLE-US-00012
<search> <byByAirInterface type="ISO15693"/>
</search>
[0136] Search for all tags whose EPC begins with 1234:
TABLE-US-00013 <search> <byEPCUID regex="{circumflex over
( )}1234"/> </search>
[0137] Searching for specific locations or time periods:
[0138] Search for all tags seen today: TABLE-US-00014
<search> <byTime start="0:00T03/13/2006"
end="23:59T03/13/2006"/> </search>
[0139] Search for all tags that have entered the shipping area:
TABLE-US-00015 <search> <byReaderGroup
name="shipping"/> </search>
[0140] Search for specific data contained on a tag:
[0141] Search for tags that contain the phrase "Skyetek":
TABLE-US-00016 <search> <byData regex="Skyetek"/>
</search>
[0142] Tags whose fifth byte is 0xAF TABLE-US-00017 <search>
<byData start="5" end="5" regex="OxAF"/> </search>
[0143] The following message may represent an exemplary search
return: TABLE-US-00018 <searchResult reader="Boyd's Reader">
<tag type="ISO15693" uid="e07000002312"
lastSeen="12:31:41T03/13/2006"/> <tag type="ISO15693"
uid="e04000002848" lastSeen="1:02:45T03/13/2006"/>
</searchResult>
[0144] Where a search targets multiple readers, each targeted
reader may return results for the search. Where multiple results
are received in response to a search, it is the responsibility of
an upstream entity (e.g. a user or a server) to decide which result
is more relevant (e.g., based upon `lastSeen` or `reader` or some
other metric).
[0145] If a search locates no pertinent tags then the reader may
return an empty result set within a response message, as follow:
TABLE-US-00019 <searchResult/>
[0146] It is the burden of the search requester to determine when
to timeout a search. For example, a requester may assume that 5
seconds after the last `searchResult` is received, no further
result may be expected.
[0147] A user may also issue search requests, using a server, for
example. In one example, reader 102(3) receives a message from a
user of server 106 requesting data from the tag with a unique
identifier (UID) of e0070001020304:
[0148] User to reader TABLE-US-00020 <getTagData
uid="e0070001020304"/>
[0149] RFID reader 102(3) then sends the requested data back to
server 106:
[0150] Reader to User TABLE-US-00021 <tagData
uid="e0070001020304"> <![CDATA[ 00010203040507AB ]]>
</tagData>
[0151] FIG. 10 is a block diagram illustrating one exemplary
`swarm` 800 of three readers, 802, 804 and 806 within a reader
network 822. In particular, reader 802 is positioned at a location
`A`; reader 804 is positioned at a location `B` and reader 806 is
positioned at a location `C`. For example, location A may represent
an entrance to a warehouse, location B may represent at a start of
a conveyor belt 811 within the warehouse and location C may
represent an end of conveyor belt 811, where conveyed packages are
transferred to storage within the warehouse.
[0152] FIG. 10 also shows a palette 810 upon which is a package 808
containing a plurality of tags 812, 814, 816, 818 and 820, where
each tag may identify a product within package 808, for example. In
particular, package 808 is shown moving through locations A, B and
C.
[0153] Reader 802 reads identification information (e.g., UIDs) of
tags 812, 814, 816, 818 and 820, storing them as data 828 within
its tag cache, for example. Reader 802 sends data 828 (i.e., UIDs
of tags 812, 814, 816, 818 and 820) to readers 804 and 806 through
reader network 822. Data 828 is illustratively shown in dashed
outline within readers 804 and 806. Thus, readers 804 and 806 have
identification information of tags 812, 814, 816, 818 and 820
before palette 810 arrives in locations B and C.
[0154] In one example, where tag 812 contains additional
information regarding prior transportation of palette 810, reader
804 may read this information when palette 810 is in location B,
store it as data 830 within its tag cache and send data 830 to
reader 806 (data 830 is illustratively shown in dashed outline
within reader 806). Reader 806 may then update data 830 with
information of handling within the warehouse and conveyor 811 and
write data 830 back to tag 812 when palette 810 is within location
C. In particular, reader 802 may `select` tag 812 prior to palette
810 leaving location A such that upon arriving in location B,
reader 804 may read data from tag 812 without delay. Such
coordinated operation is particularly important when palette 810
transits rapidly through each location A, B and C.
[0155] In another example, reader 802 (or another authority such as
the user or a server) may determine that tag 820 is bogus (e.g., of
no interest). Reader 802 may therefore notify readers 804 and 806
that tag 820 should be ignored, thereby preventing further
undesired interaction with tag 820.
[0156] Since reader 802 updates readers 804 and 806 with data 828
(i.e., UIDs of tags 812, 814, 816, 818 and 820), reader 804 and 806
do not search to identify, a time consuming process, other tags
within palette 810. Again, this is significant where palette 810
transitions rapidly through locations A, B and C. The use of
networked readers effectively extends the area of interaction with
tags of palette 810 through multiple locations.
[0157] Services Provided by the Reader to Reader Protocol
[0158] The reader to reader protocol may be an XML based protocol
over HTTP/HTTPS based and may be functionally equivalent to a
binary protocol over TCP/UDP. However, other protocols and
communication medium may be used without departing from the scope
hereof.
[0159] The reader to reader protocol functionality may be
summarized as follows:
[0160] Reader management allows a reader to be interrogated as to
its status (e.g., what the reader is doing, firmware/hardware
version, script versions etc.). Firmware and/or scripts may be
updated. Readers within the reader network may coordinate and
synchronize their tag caches and also synchronize their operation
to achieve an eventing/swarming mode (e.g., where a first reader
selects a tag and then a second reader writes to the tag) of
operation. Transmitted radio power levels and operational periods
may be coordinated and/or synchronized between one or more readers
to reduce or eliminate radio interference when density of readers
in one area is high (i.e., when readers interfere with one another
during reading and writing of tags).
[0161] Tag caches of readers within the reader network may be
searched to locate tags based upon meta data (e.g. time, reader
location), tags whose values have changed within a defined period
of time, data stored within tags (e.g. `Hello World` at 0x0f) and
other tag attributes (e.g. tag types such as ISO15693).
[0162] The reader network may be queried to determine status of the
network, RFID readers and their relationship to one another.
Messages may be routed through the reader network directly and
indirectly. Readers may join the reader network through a discovery
process, during which the joining reader will become
synchronization (in both time and with tag cache data).
Communication within the reader network is secure, messages may be
encrypted, for example, and readers may require authentication
and/or authorization before being allowed to join the reader
network.
[0163] FIG. 11 is a flowchart illustrating one exemplary method
1300 for coordinating a plurality readers to minimize reader noise
and increase reader sensitivity. In step 1302, a first set of one
or more of the plurality of readers is coordinated to operate in a
transmit only mode. In one example of step 1302, reader 102(2),
FIG. 2, is coordinated to operate in a transmit only more. In step
1304, a second set of one or more of the plurality of readers is
coordinated to operate in receive only mode. In one example of step
1304, readers 102(1) and 102(3) are coordinated to operate in-a
receive only mode. In step 1306, the first and second set of
readers are synchronized such that a receive period of the second
set of readers coincides with a transmit period of the first set of
readers. In one example of step 1306, readers 102(1), 102(2) and
102(3) are synchronized such that a receive period of readers
102(1) and 102(3) coincides with a transmit period of reader
102(2).
[0164] FIG. 12 is a flowchart illustrating a method 1400 for
distributing activity across a network of readers. In step 1402, a
first set of one or more reader at a first location is configured
to identify a plurality of tags to determine identification
information. In one example of step 1402, reader 802, FIG. 10, at
location A, identifies tags 812, 814, 816, 818 and 820. In step
1404, a second set of one or more readers at a second location is
configured to perform at least one additional operation upon at
least one of the plurality of tags, the additional operation
comprising interaction by the second set with one or more of the
plurality of-tags. In one example of step 1404, reader 804
interacts with tag 812. In step 1406, the second set utilizes the
identification information, received from at least one of the
readers of the first set, to interact with one or more of the tags
without searching to identify the tags at the second location. In
one example of step 1406, reader 804 utilizes the UID of tag 812
received from reader 802 to select and read tag 812.
[0165] FIG. 13 is a flowchart illustrating a method 1500 for
providing connectivity between a server and at least one of a
plurality of readers. In step 1502, the plurality of readers is
communicatively coupled to create a reader network wherein not all
of the readers are directly connected to the server. In one example
of step 1502, reader network 105, FIG. 2, is created by
communicatively coupling readers 102(1), 102(2) and 102(3), wherein
readers 102(1) and 102(2) are not connected to the server. In step
1504, at least one of the readers is connected to the server to
create a proxy server, such that the proxy server exchanges
information between the server and at least one of the readers not
connected to the server. In one example of step 1504, reader 102(3)
connects to serve 106 and forms a proxy server for exchanging
information between server 106 and reader 102(2).
[0166] Changes may be made in the above methods and systems without
departing from the scope hereof. It should thus be noted that the
matter contained in the above description or shown in the
accompanying drawings should be interpreted as illustrative and not
in a limiting sense. The following claims are intended to cover all
generic and specific features described herein, as well as all
statements of the scope of the present method and system, which, as
a matter of language, might be said to fall there between.
* * * * *
References