Patent Application
20060280181
The present invention relates generally to data processing techniques. More particularly, the present invention provides methods and systems for a distributed data collection, aggregation, conditioning, processing, formatting, forwarding, and partitioning, among other features. In a preferred embodiment, the present methods and systems are provided to gather, retain, forward, format, pre-process, and present data to one or more applications that process that data. As merely an example, such applications include, among others, collecting information from radio frequency identification tags, commonly called RFID tags, which are used as identification tags. But it would be recognized that the invention has a much broader range of applicability. For example, the invention can be applied to almost any types of information collection devices where large quantities of information are desirably processed.
Over the years, we have improved ways of tracking objects such as automobiles, merchandise, and other physical entities. As merely an example, item identification tags have been in commercial use for a long time. Printed optical tags, such as the Universal Product Code (UPC) standard, appear as high contrast stripes or 2 dimensional patch patterns on the tagged object. A UPC tag is present on most retail products and appears as a familiar black and white barcode. Although highly successful, UPC tags have certain limitations. That is, such tags have limited information. Additionally, such tags cannot be broadly used for certain applications. These limitations will be described in more detail throughout the present specification and more particularly below.
Accordingly, Radio Frequency Identification (RFID) tag technologies have been introduced. RFID tags represent a relatively new form of item identification tagging. The proposed Electronic Product Code (EPC) standard is an example of an RFID-based equivalent to the optical UPC standard. Both optical tags and RFID tags allow a reader device to retrieve information from a tagged item; however, there are significant practical differences between the two approaches.
With UPC, the tag reader device must have unobstructed line of sight access to the tag. Furthermore, the UPC tags must often be presented to the reader to be scanned.
An RFID tag reader uses radio frequency energy to read the tags and can therefore access a large number of tags in a given area irrespective of visual access.
Historically, tagging systems have been limited in scope and capacity to applications enabled by optical tags. These applications generated only modest quantities of data because they were naturally limited by the physical presentation rate of tags to optical readers.
With RFID tags, an individual item need not be physically maneuvered in front of a reader to be read. RFID tagged items may be read in any mix of loose, packaged or multiply packaged (cartons within cartons) configurations so long as the RF energy from the reader can penetrate the packaging and the reply signal can sufficiently exit the packaging material and reach the reader. Tagged items or boxes of tagged items may be in motion in shipping and receiving bays or at inventory control points; they may also be sitting still in shelves or storage areas. In all cases, the RFID tags are being constantly read by their corresponding tag reader. Items in motion may require much more aggressive read rates to avoid missing one or more of the tagged items as they pass by the reader; this would be the case in a receiving bay with a conveyor belt for incoming tagged items.
The ability to constantly take inventory is a key component to efficient material management and shrinkage reduction in retail stock management, supply chain management, manufacturing, material storage and other applications. It is therefore advantageous for an RFID reader to be constantly querying all of its tags under management. Unfortunately, RFID systems have certain limitations. That is, present networking systems have not been adapted to effectively process information from the RFID readers when large quantities of information are to be monitored. These and other limitations are described throughout the present specification and more particularly below.
From the above, it is seen that techniques for improving information processing of large quantities data are highly desirable.
According to the present invention, techniques related generally to data processing are provided. More particularly, the present invention provides methods and systems for a distributed data collection, aggregation, conditioning, processing, formatting, forwarding, and partitioning, among other features. In a preferred embodiment, the present methods and systems are provided to gather, retain, forward, format, pre-process, and present data to one or more applications that process that data. As merely an example, such applications include, among others, collecting information from radio frequency identification tags, commonly called RFID tags, which are used as identification tags. But it would be recognized that the invention has a much broader range of applicability. For example, the invention can be applied to almost any types of information collection devices where large quantities of information are desirably processed.
In a specific embodiment, the present invention provides a method for managing a plurality of objects using RFID tags in a real-time environment. The method includes transferring information in a first format from one or more RFID tags using an RFID network. In a specific embodiment, the one or more RFID tags is coupled to respective objects, which is often capable of movement by a human user. The method includes capturing information in the first format using one or more RFID readers provided at one or more predetermined spatial region using the RFID network and parsing the information in the first format into a second format. The method includes processing the information in the second format using one or more processing rules to identify if the one or more RFID tags at a time period of T1 is associated with the one or more RFID tags at a time period of T2. The method transfers a portion of the information from the RFID network to an enterprise network. The method also receives the portion of the information at an enterprise resource planning process using the enterprise network. The method also includes determining if the one or more respective objects is physically present at a determined spatial location or not present at the determined spatial location at the time period T2.
In an alternative specific embodiment, the present invention provides an alternative method for processing RFID traffic between a first network and a second network. The method transfers information associated with a plurality of RFID tags corresponding to respective plurality of objects in a first format through an RFID network. The method also includes processing the information in the first format using one or more rules to identify one or more attributes in a portion of the information in the first format. Depending upon the embodiment, the one or more attributes in the portion of the information is associated with at least one of the plurality of RFID tags. The method includes processing the portion of the information in the first format associated with the change into information in a second format to be transferred from the RFID network. The method transfers the portion of the information in the second format through an enterprise network. In a preferred embodiment, the method includes dropping other information in the first format from being transferred through the enterprise network to reduce a possibility of congestion through the enterprise network.
In yet an alternative specific embodiment, the present invention provides a system for managing RFID devices operably disposed in a pre-selected geographic region. The system has at least 3 RFID readers. Each of the RFID readers is spatially disposed in selected determined regions of a physical space. An RFID network is coupled to each of the RFID 5 readers. An RFID gateway is coupled to the RFID network. The RFID gateway is adapted to process information in at least a link layer and a network layer of the RFID network from the at least 3 RFID readers. The system has an enterprise network coupled to the RFID gateway; and an ERP (Enterprise Resource Planning Software) management process coupled to the enterprise network and coupled to the RFID gateway.
In a specific embodiment, the present RFID gateway avails its state to one or more upstream RFID gateways or data processing applications. Depending upon the embodiment, the present RFID gateway can be combined with network switching elements. Additionally, two or more RFID gateways can be formed into an encapsulation proxy/hierarchy to further reduce network traffic load. Two or more RFID gateways can also be formed into an encapsulation proxy/hierarchy to further reduce gateway computation load. Two or more RFID gateways can be formed into an encapsulation proxy/hierarchy to further improve device management.
Certain advantages and/or benefits may be achieved using the present invention. The present methods and systems can be implemented using conventional computer software, firmware, and combinations of hardware according to a specific embodiment. In a preferred embodiment, the present methods and systems overcome certain limitations of processing large quantities of information that have plagued conventional techniques. Depending upon the embodiment, one or more of these benefits may be achieved. These and other benefits will be described in more throughout the present specification and more particularly below.
Other features and advantages of the invention will become apparent through the following detailed description, the drawings, and the claims.
According to the present invention, techniques related generally to data processing are provided. More particularly, the present invention provides methods and systems for a distributed data collection, aggregation, conditioning, processing, formatting, forwarding, and partitioning, among other features. In a preferred embodiment, the present methods and systems are provided to gather, retain, forward, format, pre-process, and present data to one or more applications that process that data. As merely an example, such applications include, among others, collecting information from radio frequency identification tags, commonly called RFID tags, which are used as identification tags. But it would be recognized that the invention has a much broader range of applicability. For example, the invention can be applied to almost any types of information collection devices where large quantities of information are desirably processed.
It is to be understood that the present invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or combinations thereof.
We have discovered that an amount of generated data can quickly mount to reduce an efficiency of an RFID network. For example, large discount retail chains may have many millions of items on the floor in each retail space; they may receive thousands of cartons a day and sell tens of thousands of items a day. With a comprehensive RFID inventory tracking system in place and the entire inventory scanned completely in a very short time (minutes or seconds), the amount of raw data generated by the scanning process is enormous—potentially tens of gigabytes per minute per site.
Processing tens of gigabytes of transactional data per minute often exceeds the capacity of most compute servers and the network infrastructure of most existing enterprises. These performance limitations limit the usefulness and feasibility of current reader-based solutions. Furthermore, there are potentially two categories of tag data read scenarios: the first is the constant background reading conducted by all readers to periodically yield a comprehensive inventory. You would find this type of scenario in a retail store. The second is very high peak rate data. In settings such as warehouses, manufacturing plants, and large retail sites, inventory arrives in peaks and potentially leaves in peaks. In manufacturing settings, where items are manufactured at an even pace but leave the site in larger groups (in containers, boxes or crates), data rate peaks occur at the outgoing shipping bay.
Within a given generation of network technology, Data Network Interconnects 312 and the switch ports that accommodate them have a certain cost per megabit/second of bandwidth for a given port bit rate. For example, an Ethernet LAN port may be capable of 10, 100, 1000 or 10,000 megabits/second port with a cost structure favoring lower bit rates and copper-based interconnects over fiber-based interconnects. Within a given generation of network technology, there is a fixed and maximum date rate that can be feasibly built. Ethernet, for example has gone through 4 popular generations to date of maximum data rates, starting with 10 megabits/second and going to 100 Mbps, 1 Gbps, and then 10 Gbps.
Similarly, WAN/Server Uplinks 311 have a certain cost per megabit/second of bandwidth in a given generation of WAN technology, which is typically many orders of magnitude more expensive to operate for a given bandwidth. If Compute Servers 330 are not physically co-located with the Data Network 310, then the uplink cost can be prohibitive. But even taking cost out of consideration, the aggregate raw bandwidth from a collection of Data Collection Elements 300 can easily exceed the maximum available speed of a WAN uplink in certain geographies.
In many cases, a router is needed between LAN and WAN facing interfaces;
The Compute Server 330 does not scale very easily and must be co-located with the Data Network 310 if the peak aggregated bandwidth of the Data Network 310 exceeds the WAN/Server Uplink 311 bandwidth. Co-locating servers with the data collection network is the current trend and is the solution proposed by name brand server vendors to date.
Tag readers in a given network can grow arbitrarily large in number and create large volumes of data, heavily loading (or overloading) the network and compute infrastructure. The sheer volume of data creates a situation where conventional data processing architectures break down, creating “data smog”: huge volumes of data, without the ability to process that data in any meaningful way or extract any meaningful actionable information from the data.
Configuring large reader deployments can be problematic; each reader must be configured and associated with its collection region. This information must be conveyed upstream to higher-level applications for various operational purposes, such as locating an errant box of breakfast cereal in the motor oil department or sending a service technician to a malfunctioning reader. This configuration work can be done manually, but like all manual processes, it is both expensive and prone to human error. With potentially hundreds or thousands of readers in a single site, with some being added or removed dynamically, the opportunity for human error is significant.
RFID deployments currently suffer from trying to cope with more data than existing architectures can cost effectively process, leaving the system in a constant data smog. Conventional data processing architectures do not scale well to solve this problem. Current solutions involve throwing large amounts of expensive compute power at the problem in an attempt to provide the appropriate level of processing power. The high deployment cost associated with processing the enormous volumes of data in a practical setting is impeding widespread adoption of RFID tagging, despite significant progress in other areas of the RFID data technology pipeline.
Another similar “data smog” situation exists with large industrial plants. Enormous volumes of real time (i.e., time critical) data are generated in oil platforms, chemical processing plants, and manufacturing lines. One strategy for managing the mix of critical and less-critical data is to segregate the collection process into multiple levels of criticality; but this approach serves to undermine the frequent need to integrate various levels of data criticality in unified feedback control and decision support systems. In practice, data processing in these large industrial plant sensor networks is performed at lower than desirable levels because of practical limits in the network infrastructure and compute server architecture.
Wireless sensor networks are yet another type of system where conventional data processing architectures are inadequate for potentially two reasons. This type of sensor network consists of a potentially large number of independently operating devices that connect via some wireless means (optical laser, direct RF links, ad-hoc network, etc.) to one or more data processing applications. In ad-hoc sensor networks there are potentially a large number of hops between a sensor and an application that receives data from the system's sensors. Latency and peak throughput are the defining characteristics of these types of networks. When a query is sent to one of the member network nodes, the ad-hoc network provides connectivity for the request; the ad-hoc network's latency and peak throughput determine how long the query takes to be serviced. Alternately, if the ad-hoc network has many wired access points there is a potential for the sensor network to inject significant amounts of data into the wired portion of the network overwhelming traditional data processing architectures. This is a similar situation to the RFID and industrial plant data smog situation in that a large number of independent devices are trying to push data through a large number of pipes, through some aggregation network, to a compute server that is ill equipped to deal with the arbitrarily high volume of data.
Thus, there are numerous applications that utilize general-purpose components such as network switches and compute servers to define their system architectures. Conventional architectures built using conventional systems elements do not scale very well because they attempt to handle larger than convenient volumes of application specific data with general-purpose strategies. Applying general-purpose strategies to very specific problems is historically the first and fastest way to a solution, but is infrequently the optimal solution. New, rapidly growing applications in the RFID and sensor networks spaces are already stressing general-purpose solutions well beyond their cost effective limits today.
In a specific embodiment, the present invention introduces a system element and system architecture for high throughput data gathering and data aggregation, device aggregation and device management processing systems. Depending upon the embodiment, certain limitations in the prior art are overcome through novel architectural and algorithmic efficiency. Further details of the present invention can be found throughout the present specification and more particularly below.
The Data Aggregation Gateway 403, 420 topologically replaces and optionally subsumes nodes in a data network that might otherwise be data forwarding nodes such as network switches or routers. With a Data Aggregation Gateway 420 inserted in the flow of data in a network, the Data Aggregation Gateway may perform a number of application aware actions, transforms, and various processing steps; for example, it may act as a proxy and aggregation point for the associated Data Collection Elements 400 to upstream compute servers; it may act as a demarcation point separating upstream systems from downstream systems in general by presenting upstream systems an abstracted, reformatted, pre-processed, encapsulated or otherwise transformed view of the downstream systems to upstream systems and vice versa. In the current art, network nodes such as switches and routers are only permitted to forward, delay and drop data; they are not permitted to modify, consolidate or offer alternate representations of the application data they convey. In contrast, the Data Aggregation Gateway 420 may perform operations on the ingress data from the Data Collection Elements 400 such as packet consolidation, culling (based on application level rules) and various application aware transforms before presentation to application clients. Examples of application clients include Compute Servers 430 or other Data Aggregation Gateways 403, 420.
For multi-layered Data Proxy Networks 450, sub Data Proxy Networks 451 are formed, partitioning both the computational load per Data Aggregation Gateway 402, 420 and the total amount of traffic generated at each stage.
Thus, the Data Aggregation Gateway enables new, distributed and scalable data collection architectures by isolating redundant traffic within the Data Network 410 and presenting only preprocessed and conditioned traffic from any stage in the Data Proxy Network 450 to any upstream stage. By partitioning both the network bandwidth load and the computational load per stage, the so called “data smog” problem can be effectively mitigated.
The staging of data is illustrated in
Thus, the Data Proxy Network 450 consists of one or more Data Aggregation Gateways 403, 420 situated between one or more Data Collection Elements 400 (and their associated Data Networks 410) and one or more Compute Servers 430. The Data Aggregation Gateway 403, 420 combines certain networking, forwarding, and packet transform functions along with application level database and data manipulation capabilities to enable data collection networks that achieve hierarchical workload and bandwidth isolation.
In scenarios where data is changing slowly relative to the sensor's sample rate, much of the data reported by a sensor in a sensor network will be redundant; by extension, much of the data in the attached Data Network 410 will be redundant. For example, an RFID reader will probably report the same set of items on a shelf from second to second and minute to minute as it is instructed to read the tags on merchandise within its coverage area. Similarly, an ocean water temperature sensor on an oil platform will read substantially the same data from second to second. In the event of a change in temperature or a change in the status of an item on the RFID reader's coverage area, the change should be noted promptly to upstream systems. Furthermore, if the item is, for example, a box of heavy explosives that is not authorized for removal from storage, the notification should be extremely prompt and may potentially propagate quickly through a number of systems before action is taken. Until then, the RFID reader that covers that box of explosives may report the presence of the same tag, associated with that box, hundreds or thousands of times a day. This unfiltered flow of reader data contributes heavily to the data smog problem.
In scenarios where data is changing or arriving quickly (such as the receiving bay in a large retail or warehouse facility) there may be a number of readers attempting to read tag data from items entering the receiving bay on conveyor belts. Generally, one or more readers will be able to read the tag on any given item, but in rare instances only one will be able to read a given tag. While the reported data needs to be sent upstream at some point, the average multiplication of data in a high-throughput, multi-reader setting can contribute substantially to the data smog problem as both additional network bandwidth and additional computation load upstream.
To compound the data smog problem, packets of data arriving from the Data Collection Elements 400 are typically very short compared to the minimum L2 frame size of the protocol used by their Data Network 410. For example, if the Data Collection Elements 400 are RFID EPC readers connected to Ethernet and are generating standard Ethernet frames to convey information, only approximately 96 bits (12 bytes) of the 368 bit (46 byte) data payload are actually being used; the rest are overhead to produce a minimum length (64 byte), correctly formed frame. This bandwidth expansion contributes to the data smog problem and the large number incoming Ethernet frames with only partially populated payloads reduces software efficiency at the upstream server receiving the frames of data.
Thus, one key function of the Data Aggregation Gateway 403, 420 will be to condition raw data arriving from the Data Collection Elements 400 according to a specific embodiment. Consolidation is a primary conditioning strategy; consolidation will take three basic forms:
Multiple Shelving Units will be organized into aisles, and aisles into floor spaces. A potentially large number of RFID Reader Units (in general terms, Data Collection Elements) will therefore participate in the complete data collection system. This large number of Data Collection Elements will produce potentially large volumes of data and require significant configuration and management overhead, as discussed previously.
In
By consolidating the payloads of multiple Incoming Data Frames 510, greater network efficiency is achieved. Multiple payloads 522, 523 share the same inter-frame gap and preamble overhead 525, Ethernet header 531, TCP/IP header 532 and checksum 524 fields. By consolidating 120 EPC tag payloads into a near maximum sized standard Ethernet frame, raw network efficiency increases from under 18% to over 96%. By consolidating 740 EPC tag payloads into a maximum sized “jumbo” Ethernet frame, raw network efficiency increases to over 99%.
Note that with long packets, the probability of any one packet experiencing a bit error (typically reported by the checksum mechanism) is increased proportionally; thus, this invention contemplates the application of error correction within the consolidated payload as a means to potentially avoid re-transmission of packets should there be an implementation or efficiency advantage versus the well known and commonly applied re-transmission strategy employed in such reliable transmission protocols as TCP/IP.
There is an additional benefit to reducing the number of packets being presented to an upstream server application: there is computational overhead associated with handling an incoming Ethernet frame. By consolidating multiple payloads into a single frame, the upstream server's computational overhead is reduced while network efficiency is simultaneously increased.
The previously described consolidation of multiple payloads is possible in this instance because the producers of data, the Data Collection Elements 400, are all ultimately communicating with the same upstream application in a very specific way. In general, data packets cannot be combined this way in a data network by switches or routers, which have no awareness of application data formats.
In RFID systems, where environmental factors such as ambient RF noise may cause unsuccessful reads to occur, it is advantageous to “over sample” the tags. For instance, one or more tags may not be successfully read in time period Tk+n but are then successfully read in Tk+n+1; different tags may go similarly missing for a different time period. The second conditioning strategy, Sample Redundancy Consolidation, provides the mechanism for gathering more than one read period (Tk to Tk+1) worth of sampled tag data and presenting the complete set of samples to an upstream application once per N (where N is greater than 1) reader time periods.
Sample Redundancy Consolidation can be utilized in one or more stages to accomplish multiple different goals. The goal of the first stage of Sample Redundancy Consolidation may be, for example, to remove transient read errors due to physical read channel issues (i.e., RF noise). The Consolidated Sampling Period may be seconds to minutes; in other words, the time to physically move an item from one place to another in a site covered by scanners. The second stage may have a time scale of hours, where daily inventory tracking is the goal. A third stage may be have a time scale of hours to days, where inventory tracking, reordering, and trend forecasting is the goal.
Despite the efficiency gains in messaging made possible with Sample Redundancy Consolidation, much of the data in
With Semantic Transformation conditioning, the tag readers must still gather all the raw tag data, illustrated in
Both Sample Redundancy Consolidation and Semantic Transformation require the Data Aggregation Gateway to construct and maintain a database of all known tag IDs. With the database of known tag IDs, the Data Aggregation Gateway can track individual roll call time outs and/or generate “status change” messages indicating a difference of tag status based on recent roll calls. These status change messages minimally consist of “ID added” and “ID removed”. A newly encountered tag will generate an “ID added” message, while a tag that goes missing will result in an “ID removed” message if the time the tag is missing exceeds a programmable threshold. The missing time threshold is necessary to avoid spurious “ID removed” messages in scenarios with low reader reliability, as may be the case in electronically noisy or highly obstructed settings.
Three conditioning strategies have been discussed. The first strategy consolidates multiple data packets into larger data packets to significantly improve network efficiency. The second strategy consolidates application layer data by effectively re-sampling tag data, thus reducing redundancy in that application data. The third strategy transforms the semantics of data reporting from roll calls to change notices, thus eliminating redundancy in the application data.
In many RFID reader deployment scenarios, reader coverage will likely overlap, potentially resulting redundant reports of the same tag ID. This phenomenon is referred to as “reader collision”. The above three conditioning strategies provide a basis for the Data Aggregation Gateway providing anti-collision means. The Data Aggregation Gateway may record which readers are reporting a given tag ID, but the inventory reported by the Data Aggregation Gateway will include exactly one instance of the tag. Optionally, the Data Aggregation Gateway will provide means for conveying a list of all readers reporting the same tag ID as an attribute associated with that tag ID; all read stability rules could apply as appropriate. The Data Aggregation Gateway may be configured to select a primary reader with which to associated redundantly reported tag ID values based on a policy such as signal strength, reader attribute (IP number, MAC address, etc.), tag attribute or read stability from each reader.
In a preferred application of this invention, the data management systems receiving conditioned data from the Data Aggregation Gateway would be compatible with all three conditioning strategies. In such a scenario, the three data conditioning strategies would be used in combination to produce consolidated packets, reporting multiple status changes, while benefiting from the smoothing, re-sampling effect of Sample Redundancy Consolidation.
In an alternate embodiment, the conditioning strategies are used as a means to compress data over an expensive network resource, such as a Wide Area Network (WAN) link. This is illustrated in
There is potentially some flexibility in the timing of transforming consolidated difference information back into individual tag ID messages. For example, the applications running on the Compute Server 804 may require a fully elaborated set of messages for each tag read, but those applications may be configured to expect that list only once an hour or once a day.
An example where this flexibility exists is a retail setting where tags are read on a minute-to-minute basis to track items through the selection, purchase and exit check processes. An item removed from its shelf is reported “removed” by its reader. At this point, the item is considered mobile within the facility and may spuriously reappear in the coverage zones of other readers throughout the store as the item makes its way to checkout; the item must now pass through a purchase process to successfully pass an exit check by the exit tag reader.
Any brief reappearance within the facility should not show up as “item reporting” messages to applications upstream from their respective Data Aggregation Gateway(s). However, if an item is reported by a given reader for some programmable length of time, the respective Data Aggregation Gateway will generate an “item reporting” message upstream. At this point, the item may have been abandoned on a random shelf or replaced on the correct shelf; either way, the item's presence should be reported.
A retail site may implement perpetual tracking on a minute-to-minute basis for the purpose of implementing theft detection procedures, tracking on an hourly basis for re-shelving procedures, and a nightly basis for inventory management. The corporate office central to many retail sites may implement nightly tracking to implement global supply base management and ordering procedures. Minute to minute through daily sampling represents a fairly asymmetric data reporting structure and presents opportunities for greater architectural efficiency.
Supply chain management (inventory and trend tracking, purchase order generation for restocking, etc.) is sited here as one example of many possible data management application relevant to this discussion.
In this scenario of
To illustrate the benefit of the data consolidation strategy employed by this invention, consider an RFID deployment appropriate for a large retail site with 1000 readers, each providing 100 tag ID reads per second. This allows for a total retail stock of 1 million items to be queried once every 10 seconds. While a 10 second inventory tracking interval is appropriate for tracking items through the selection and purchase process, it represents approximately 72 megabits/second of bandwidth (assuming 90 byte packets). 72 megabits/second is nearly two orders of magnitude more bandwidth than a T1 line can provide. In contrast, if this retail site generates approximately 6000 transactions of items leaving the facility (purchases) per minute, and each purchase generates a 90-byte message frame (to convey a 96-bit EPC code), the difference data is less than 100 kilobits/second. The Data Aggregation Gateway 902 absorbs the 72 megabits/second of aggregate tag reader data, consolidating this tag data into change data that can easily pass over a T1 or partial T1 line. On the upstream side, the data can be elaborated back into the original 72 megabits/second of what appears to be raw tag reader data that conforms to the basic compatibility requirements of the management applications.
In a preferred embodiment, data management applications running on the upstream Servers 904 are able to interpret the consolidated data formats directly from the first Data Aggregation Gateway 902, eliminating the need for a second Data Aggregation Gateway 903 and eliminating the additional computational load of absorbing 72 megabits/second (in the example) of tag data.
An additional strategy for reducing bandwidth provides for an M-bit to N-bit reduction per “ID removed” message, while adding an additional burden of N-bits to the “ID added” message. Obviously, there are combinations where such a reduction is not beneficial. However, for certain anticipated standards such as EPC, this reduction may prove beneficial for both network bandwidth and computational loading on data management applications. This referencing model, hereafter referred to as “index referenced”, relies on the observation that an “ID added” message contains unique tag information, whereas an “ID removed” message contains a redundant copy of this tag information. The normal (non-indexed) referencing model in identifying tag IDs will be referred to as “tag referenced”.
The current generation EPC tag ID contains 96 bits of information and future generations of EPC codes will contain 256 bits of tag information. To indicate an EPC tag has newly been added to the group of tags visible to a reader, a Data Aggregation Gateway may generate a message indicating “ID added”, with the 96 or 256-bit tag data. When that tag fails to report in for some programmable length of time, the Data Aggregation Gateway generates an “ID removed” message with the associated 96 or 256-bit tag. Using an index referenced model, the Data Aggregation Gateway assigns an M-bit index when the “ID added” message is sent; and sends the same index with an “ID removed” message. Using EPC codes as an example, and using an index of 32 bits, then an “ID added” message would be 96+32=128 bits (or 256+32=288 bits), whereas an “ID removed” message would always be 32 bits versus 96 (17% payload bandwidth savings) or 256 bits (43% payload bandwidth savings). A 32-bit index provides for 4 billion unique items under the management of one Data Aggregation Gateway.
EPC tag data will likely contain significant redundancy in both vendor and serial number fields (primarily the most significant serial number bits); this invention contemplates the use of loss less compression to convey tag data both in index referenced messaging (for initial “add” messages) as well as tag referenced messaging (roll call and difference messages). A number of suitable compression algorithms are known to those skilled in the art of loss less compression and include classes of algorithms based on run length encoding and recursive and/or non-recursive codebook encoding.
There are numerous well-known techniques for hashing, indexing or otherwise compressing units of data well known to those skilled in the art of data coding and compression. Such methods are contemplated by this invention as a means for reducing bandwidth, computational load or both.
In a preferred embodiment of this invention, the Data Aggregation Gateway can both accept and generate messages in index referenced or tag referenced modes, including a simultaneous mix of the two; furthermore, the Data Aggregation Gateway can translate between the two models for the benefit of upstream systems that may be incompatible with either referencing model.
Data Consolidation functions of the Data Aggregation Gateway have been outlined to this point. Data Elaboration (the inverse of Consolidation) has also been mentioned in the context of providing compatibility with systems requiring data in a raw reader format. These two features of the invention described herein establish a context for discussing the full functionality of the invention.
The Ingress Engine 1210 accepts data packets from a network interface such as Ethernet, SONET or T1. The incoming data packets are stored in the Data Buffer Manager 1220. The Ingress Engine 1210 may optionally structure or pre-parse the incoming data if a specific implementation benefits from structuring or pre-parsing data at this point. The Ingress Engine 1210 may also provide packet reassembly service if implementing packet reassembly at this point has an implementation benefit. Depending on the requirements of a specific implementation, the functionality of the Ingress Engine 1210 may or may not overlap, encompass or augment the functionality of a standard network protocol stack such as IP or TCP/IP. The Ingress Engine 1210 may bypass the operating system's TCP/IP stack for certain types of traffic and forward other traffic to the TCP/IP stack. For example, system management packets will be presented to the operating system's TCP/IP stack (no bypass), whereas tag ID data may optionally bypass the TCP/IP stack. In this way, the Ingress Engine 1210 performs rudimentary classification functions; the match criteria may include the packet's destination L2 MAC address, destination IP address, etc.
The Ingress Engine 1210 may additionally perform packet verification services before handing off a given packet. Such services may include checksum checks and malformed packet checks.
The Classification Engine 1211 parses the incoming data packets, structures their content and identifies what type of action, if any, is to be taken in response to their arrival. The Classification Engine 1211 utilizes programmable pattern matching within programmable search fields contained in a packet to determine what action should be taken. For example, the Classification Engine 1211 may be programmed to look into packet payloads for tag IDs from a specific field such as vendor ID; packets from this vendor may identify high priority handling.
Once a Rule has been matched, the Classification Engine 1211 will then map the rule to a predetermined programmable action 1311, 1312, 1313, 1314. The act of mapping the rule will generally consist of attaching an attribute to the packet and queuing the packet up for action. Optionally, the Classification Engine directs the packet to a specific module to conduct the specified action. Some example Actions include:
The classification functionality is therefore constructed to be very general, whereas the actual Rules are programmed to be specific to the application(s) at hand.
The Classification Engine 1211 may implement one or more of the response actions.
If the Classification Engine 1211 determines the data frame is destined for the Conditioning Engine 1212, then the Conditioning Engine 1212 is notified. The Conditioning Engine 1212 employs the following strategies to reduce bandwidth:
Additionally, the Conditioning Engine 1212 employs data smoothing strategies to reduce or eliminate spurious data. One key data smoothing strategy sets thresholds for missing data; thus, a tag ID must go missing for a programmable length of time (or reader intervals) before its absence is reported. In a preferred embodiment, the smoothing and culling strategies cooperate in their operation.
The Conditioning Engine 1212 can allocate buffer space via the Data Buffer Manager 1220 to assemble new, larger consolidated outbound packets from smaller inbound packets. In a preferred embodiment, the Conditioning Engine 1212 sets a programmable time limit for assembling consolidated packets; in this way, the consolidation process avoids burdening already arrived data packets with unbounded latency. Furthermore, a preferred embodiment of the Conditioning Engine 1212 provides programmability in enabling, disabling and configuring each function independently.
The Conditioning Engine 1212 can be configured through a command set within a Command Line Interface (CLI), a GUI, XML, SNMP, or other appropriate management means.
The Notification Engine 1213 sets programmable timers, pattern matching functions and other means to monitor stored data and respond to it in an appropriate time frame and based on programmable rules. In a preferred embodiment, the Notification Engine 1213 would also receive messages from the Classification Engine 1212 for high priority notifications.
The Notification Engine 1213 should, at a minimum, have the capability to attach specific rules to individually known tag IDs. When a rule is triggered, the Notification Engine 1213 generates an associated programmable response, sending the response to the Messaging Engine to format. An example action of the Notification Engine may be to upload the current tag database in response to a timer trigger.
The Notification Engine 1213 can be configured through a command set within a Command Line Interface (CLI), a GUI, XML, SNMP, or other appropriate management means.
The Messaging Engine 1214 formats outbound payloads to match a specific, programmable schema that represents the notification message in conformance to an upstream server's requirements. In a preferred embodiment, the Messaging Engine 1214 supports be a plurality of simultaneously available schemas, assembled in a modular, extensible architecture. In a preferred embodiment, the Messaging Engine 1214 sends a reference to its formatted message to the Protocol Engine 1215, where the message is encapsulated in a standard network packet format and queued for egress with appropriately built headers. Alternatively, the Messaging Engine 1214 directly formats the packet for egress.
The Messaging Engine 1214 can be configured through a command set within a Command Line Interface (CLI), a GUI, XML, SNMP, or other appropriate management means.
The Egress Queuing Engine 1216 implements the egress queuing policies and priority mechanisms, based on the application requirements. This invention contemplates various queuing schemes well known to those skilled in the art of networking or queuing systems. Example queuing schemes include a basic priority queue and weighted round robin queue. In a priority queue, the Egress Queuing Engine 1216 assigns greater egress priority to high priority messages (for example, an unauthorized removal of explosive material, indicated by high priority message flags) over low priority messages (the box of cereal is still on the shelf, as indicated by low priority message flags). The Egress Engine 1217 implements the interface specific details. In certain instances, it may be advantageous from an implementation standpoint to combine the functions of the Egress Queuing Engine 1216 and the Egress Engine 1217 into a single Engine.
The Data Buffer Manager 1220 is a memory manager subsystem for ingress and egress packets while they are being processed. Thus, the Data Buffer Manager 1220 allocates and de-allocates buffer space to incoming data frames/packets as well as newly generated and in-progress frames/packets.
The System Database 1221 implements a number of complex functions, including tag ID lookup, tag ID management and attribute management. When a tag reader reports a given tag ID, the System Database 1221 conducts the lookup; the lookup function searches for the contents of that tag ID within the known database of tag IDs. If the tag ID is not present, the System Database 1221 reports a lookup miss back to the requesting engine and conditionally enters the tag ID into the database of known ID tags. If the tag ID is present, the System Database 1221 reports a hit, along with an attribute index that can be used examine the attributes associated with that specific tag ID.
Because the tag ID is potentially quite long, (i.e., 256 bits or more) the search algorithm implements a content field lookup over some number of possible entries, with the result being a reference (index, pointer, handle, address, etc.) to the matching entry. This reference is then used to access information records related to the database entry associated with the matching tag ID.
Another optional function of the System Database 1221 is to implement a replacement policy for database entries; for example, so tag IDs that have gone missing for a while may be processed for removal. The System Database may also implement time dependent attributes on database entries and implement alert mechanisms. This requires additional Attribute fields indicating time relevant information, such as the last time stamp where a given Tag ID was received. Entries that are older than a programmable threshold (also a per entry Attribute) are presented to the Notification Engine 1213 and optionally Conditioning Engine 1212 for processing. An example notification for an aged out entry would be the difference message “ID removed”. The Messaging Engine 1214 would be employed at this point to construct a “tag referenced”, “index referenced” or other formatted message; this message can either be a stand alone data frame or consolidated with other data frames.
The Task Queue Engine 1222 provides the mechanism for scheduling and coordinating the flow of data and tasks through the system. This function can be implemented as a centralized system resource, as shown in
The Messaging Engine 1214 implements the interface structures and schemas for conveying data to a client application such as an upstream Data Aggregation Gateway, middleware application, or data processing application. Any such upstream application will probably maintain its own retained database of tag data; in certain implementations, it may be advantageous for the Messaging Engine 1214 to construct update messages that are incremental and faster to process by an upstream application. For example, sending an agreed upon index (index referenced) rather than a full tag ID is one example that saves the upstream application the workload of conducting a lookup search. This invention contemplates this and other incremental database techniques known to those skilled in the art of high performance database design.
The Protocol Engine 1215 constructs the message formed by the Messaging Engine 1214 into data packets suitable for egress on the selected interface protocol. An example interface protocol is TCP/IP over Ethernet or TCP/IP over T1 with Frame Relay.
The inter-process communication subsystem 1223 provides the mechanism for allowing the constituent processing engines to communicate. Examples of inter-process communication include shared memory segments, socket streams, message queues, etc.
This demarcation mechanism can be used in a hierarchy of Data Aggregation Gateways as shown in
The Data Aggregation Gateway that gathers all underlying state and data presents two views of the underlying data in the Data Proxy Network 1711. The first view, the Aggregated Collector View 1701 is a well-known interface (typically a port number and protocol in TCP/IP) that aggregates all of the underlying readers and preferably matches the Well Known Interface 1704 associated with the readers. In this way, the farthest upstream Data Aggregation Gateway presents itself to an upstream application as though it were a reader with a potentially very large coverage footprint with a large number of tag IDs under management. This farthest upstream Data Aggregation Gateway retains the data reported by all underlying systems and turns around all requests without the need to generate additional reader traffic.
The second view, the Individual Collector View 1702 provides individual access to the readers and intermediary elements in the Data Proxy Network 1711. An exemplary method by which upstream servers can identify, configure and access individual readers is Port Address Translation (PAT). PAT is a technique known to those skilled in the art of networking and network protocols.
By providing both an Aggregated Collector View 1701 and an Individual Collector View 1702, the Data Aggregation Gateway provides a single, well known interface as well as the option of management and control of individual readers.
In addition to providing an Aggregated Collector View 1701 that is compatible with the native format of an individual reader, this invention also contemplates an Aggregated Collector View provided by a Data Aggregation Gateway containing additional Attribute Data. This Attribute Data may include, without limitation, reader identification (for example, IP number) associated with a given reported tag ID, signal strength between reader and tag, ambient noise information per reader and other reader system status information.
Thus, in addition to providing ID tag data and device aggregation services, the Data Aggregation Gateway optionally provides individual device management and monitoring, with a consolidated proxy presentation of all underlying data and status associated with all systems under Data Aggregation Gateway management.
Although the above has been generally described in terms of object level tagging of movable objects, there can be many other variations, modifications, and alternatives. For example, the invention can be applied other applications including almost any system of autonomous intercommunicating devices. Examples of such systems include not only EPC and UPC data collections, but also, without limitation, sensor networks, “smart dust” networks, ad hoc networks and other data collection or ID reader systems, any combination of these, and the like. Of course, one of ordinary skill in the art would recognize other variations, modifications, and alternatives.
This present application claims priority to U.S. Provisional Application No. 60/682,193, titled “Systems and Methods for Operating and Management of RFID Network Devices,” filed May 17, 2005, commonly assigned, and hereby incorporated by reference for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 60682193 | May 2005 | US |
