Patent Application
20070046467
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.”
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.
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.
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.
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.
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.
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.
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.
Stream 320 includes drivers that provide hardware interface handling for communication with a host (e.g., server 106,
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.
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).
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.
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.).
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.
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.
Application layer 352 accesses application software interface 336 via a portable and platform-independent API (illustratively represented by a two way arrow 350 in
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.
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.
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.
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.
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.
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.
The initialization and anti-collision procedures describe how reader 102 and tags 108,
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.
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.
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).
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.
It should be recognized that the specific hardware, drivers, libraries and applications described with reference to
Networking RFID Readers
As shown in
Continuing with the example of
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).
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:
Reader broadcast:
Each peers to Reader:
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:
Reader to server:
Server to reader:
Continuing with the example of
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.
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.
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.
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,
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.
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.
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).
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.
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:
Reader to Reader:
This capability message may be extended by adding information about specific functions/items supported by the reader. For example:
Reader to Reader:
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Coordination
In
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.
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.
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
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).
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.
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.
Each reader may contain the following information relating to its physical location, illustratively shown as a data structure:
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.
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.
Management
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.
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.
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.
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.
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.
Referring again to the example of
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).
Server 106 detects available readers by issuing a management message:
Server to network:
This causes each reader connected to the reader network to respond to the server with its list of known peers:
Each individual reader to server:
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.
Data Manager
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:
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.
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.
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.
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.
Searching for specific tags or tag types:
Search for all ISO15693 type RFID tags:
Search for all tags whose EPC begins with 1234:
Searching for specific locations or time periods:
Search for all tags seen today:
Search for all tags that have entered the shipping area:
Search for specific data contained on a tag:
Search for tags that contain the phrase “Skyetek”:
Tags whose fifth byte is 0xAF
The following message may represent an exemplary search return:
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).
If a search locates no pertinent tags then the reader may return an empty result set within a response message, as follow:
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.
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:
User to reader
RFID reader 102(3) then sends the requested data back to server 106:
Reader to User
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.
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.
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.
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.
Services Provided by the Reader to Reader Protocol
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.
The reader to reader protocol functionality may be summarized as follows:
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).
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).
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.
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.
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. 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.
| Number | Date | Country | |
|---|---|---|---|
| 60712957 | Aug 2005 | US |
