Implications of Building a System from Finders - Research Proposal Example

Please just send a message if you need anything. Thanks! DRAFT PROPOSAL Building a System from FINDERS Table of Contents Contents Contents 2 1. Implications of Building a System From Finders 1.2 Queue lengths of collecting stations The amount of data that can be handled by the system depends on the stability of the queue thus queue lengths of collecting stations must be consistent with the amount of data each tag can handle. For instance, the arrival rate of data must be lower to ensure stability of each tag in the collecting stations (Yang & Wu, 2011:.964). The safeguard introduced in FINDERS for this type of problem is packet dropping when the queue is full or near overload. Those packets with highest FTD or fault tolerance degree are dropped whenever the queue is full while other packets with FTDs large than a threshold are also dropped even the queue is not full to prevent transmission overhead. However, the length of queue was not specifically defined in FINDERS but test conducted in the University of Louisiana suggest the maximum queue size for 5 readers equipped with two side-by-side 6-dBi circular polarized antennas, readers 1 – 4 as IRs while reader is serving as GR, is 500 packets (Yang & Wu, 2011:969). Note that this setup was based on estimated traffic load that can change unexpectedly. By analysis, the idea of packet dropping and queue size based on estimated traffic load are not entirely realistic since this can cause unexpected problems. For instance, packets with higher fault tolerance can be delayed and transmitted again thus packet dropping is somewhat acceptable in terms of preventive overloading measures. However, being in a network with pre-defined queue size based on estimated traffic load is different as unexpected increase in traffic can lead to sizeable number of packet dropping that will likely overcome queue management. Dynamically managing the length of queue is probably a more realistic approach as the length of queue will based on the amount of collected data (independent of traffic) rather than fixed or pre-defined traffic load. This queue resizing technique (automatic adjustment of queue length) according to Park et al, (2010: Abstract) enable data processing in real-time, prevent data loss caused by sudden increase in input data, and prevent data overflow due to underestimated queue size. Another alternative is to manipulate reader through low-level operations to provide queue length estimation based on the proximity of tags passing by (Stephanidis, 2011:67). However, there is no detailed information provided how this approach can actually provide the right queue length. By analysis, the possibility of determining queue length is there as this approach is somewhat similar to estimated traffic load approach. The big difference is the fact that proximity does not necessarily mean real traffic for the reader tags within proximity may pass or stay stationary for some time. Further research on this approach is necessary as in terms of queue management, any possible alternative or combination of approaches other than fixed queue size is favourable. 1.3 Memory of Each Tag FINDERS’ prototype tag memory is CIG2 compliant with four memory banks configured to use EPC128 memory map thus can hold 128 bits of data or two data packets at a time (Yang & Wu, 2011:968). By analysis, FINDERS extend this capacity by introducing “blocks” that can also accommodate one or more storage tags as shown in Figure 1. Figure 1-Memory Mapping Modes The same memory configuration and adaptive expansion technique can be used in the proposed system to avoid communication bottleneck. Similarly, inclusion of “blocks” can significantly increase network capacity but should be limited as large blocks can result to longer delay particularly in read and write operations. Table 1- Available Memory Capacity of RFID chips (Uckelman, 2012) Manufacturer Product Transponder ID Unique Item Identifier User Memory Impinj Monza 64 bit 96 bit 0 bit Monza/ID 96 bit 0 bit Monza/64 96 bit 64 bit NXP G2XL 64 bit 240 bit 0 bit G2XM 64 bit 240 bit 512 bit STMicroelectronics XRAG2 64 bit 176 bit 128 bit 64 bit 304 bit 0 bit The format of data packet in FINDERS as shown below is another important tag capacity consideration as it is created the moment the reader detects a tag. The information and the arrangement of this information are vital to the overall performance of the network. For instance, the timestamp and span provides the time and the duration of interaction between the reader and a particular tag thus generation of separate packets is avoided. Similarly, the FTD controls duplication and manage queue and therefore unnecessary delays. Figure 1 - Data Packet Format However, in order to take advantage of this performance enhancing technique, it should be implemented with the right implementation scheme. The proposed system may benefit from using the latest industrial standard such as EPCGlobal Class 1 Gen2 that FINDERS adapted with small modification such as codes for calculation and decision making (Yang & Wu, 2011:968). However, it is important to note that discussions on how this implementation scheme works was based on a single tag attached to the object and therefore untested to multiple tags. FINDERS recommended masking the reader’s Select command with “1111” rather than using the usual “all” parameter to call all neighbouring tags to reply. These techniques according to Yang & Wu (2011:969) will only allow the head tags to reply as shown below rather than all tags. Query will only start after the head tag is identified thus avoiding collision of multiple tags. Figure 2- Head Tag The transition to multiple tags seems simple but by analysis of EPCGlobal C1G2 there is no Select command (Meersman et al, 2006:368). This is probably part of the modification made by Yang & Wu (2011) to enable decision making support of their own protocol. Modification of EPCGlobal C1G2 therefore is actually possible and may benefit the system in terms of tags performance by manipulating memory access and making readers decide more accurately. 1.4 Communication Channel Capacity and Management As mentioned above having large memory avoids communication problems. Similar to the recommended dynamic queue length, the capacity of communication channel must be adaptive to the communication needs. In an experiment conducted by Yang & Wu (2011:962), the communication range should be within 6 ft because beyond this point both read and write effectiveness deteriorates. Moreover, during the actual transfer of data, determining the most important packet to transmit must high priority as sporadic connection and limited storage of the tag will make communication opportunity very small. The above is the reason why FINDERS formulated different read and writing strategies such as Aggressive-Write or AW and AR or Aggressive-Read that allows reader to write and read data in any neighbouring tags. In other words, data delivery in FINDERS is only possible when communication is directly available between a reader and certain tags. The protocol implemented by Yang & Wu (2011:968) suggest uses a set of commands to communicate with nearby tags that will reply with an RN16 handle (a random number generated by the tag before it goes to Reply State) when it becomes available to communicate. In other words, the reader will repeatedly send query to nearby tags until each of them respond and acknowledge the command. In reality, although there is a small probability two or more tags can respond at the same time resulting to collision particularly when they chose the same random number. Moreover, the movement speed of the tags can significant affects communication as well as transfer of data into the tags. Experiment shows that the faster the tag moves the lower success rate particularly when that particular tag is beyond the recommended 6 ft range and continues to move away from the reader. The queue length shown on Figure 1 not only increases with time but delays in queuing due to the length of interactions with the readers as shown in Figure 2. This in essence is a condition where communications between tags are delayed resulting to further delay in data transmission and increasing queue. Note that the packet dropping technique and fixed queue size mentioned earlier were used in this experiment but it similarly yields lower success rate. Note that IR4 has the longest queue mainly because it seldom meet or communicate with tags. The proposed communication channel capacity must be greater than FINDERS while communication management ensure that tags are within communication range and moving at a rate where forward and reverse communication channel is possible. The proposed system must provide a more effective coordination protocol than mere commands and random numbers (as in FINDERS) in order to avoid mixed transmissions and enable isolation of the most available tag. A recommended technique is LBT or Listen Before Talk where the reader checks on the communication channel and switch to another channel when it finds a signal. The process is repeated until it finds a free channel to communicate with. Another is DRM or Dense Reader Mode where time synchronization and frequency separation are employed to ensure that tags only respond to the strongest reader signals. In combination, DRM and LBT can organize communication and avoiding collision by making use of specific channels (Roussos, 2008:62). 1.5 Number of Collecting Stations – Mobile and Stationary FINDERS was tested in a very conservative manner using 5 readers installed in different locations as shown in Figure 3 and 4. Clearly, placing these readers in such a way will not serve the purpose of monitoring of people’s movement as these readers can only detect those entering the particular room. The proposed system will not benefit from this arrangement as it requires greater number of collecting stations. The number of these data collection stations depends on the length of the monitored area. For instance, if the monitored area is 24 feet x 4 ft (a corridor for example) it will need at least six collecting stations. As shown in Figure 5. Figure 5 – Collecting Stations in 24 ft corridor Note how these readers were arranged so that its 6 ft communication range from the tag is maintained. Here the collecting station is 2 and they are located 12 ft apart so their range overlaps at a certain point along the corridor. The number of collecting stations therefore is dependent on application and dimension of the area to be monitored. Similarly, depending on the need, these collecting stations can be mobile or stationary. If the application demands mobility, the collecting stations must not be in the same location at the same time otherwise mixed transmission and acquisition of unnecessary or duplicated data will occur. The use of combined LBT and DRM as discussed can reduce this problem may arranging communication through specific channels. 1.6 Required Network Capacity The required network capacity is again dependent on the application and the queuing stability. Moreover, the network capacity is actually determined by the capacity and number of readers and tags. In FINDERS, higher performance of the system was noticed when there are more tags for the reader to communicate. In contrast, too much tags reduced performance as the reader has to process unnecessarily duplicated data. Increased tag capacity generally yield better performance as more packets are read and written to the tag. Similarly, more packets are delivered by the tags when they are within the communication range (Yang & Wu, 2011: 973). Recommend length of queue for stable performance and tag capacity are already discussed in Sections 1.2 and 1.3. As shown in Section 1.5, network capacity can be increased by increasing the number of readers within limited communication range. More packets will be read and written to the tag if these readers are within reach and able to communicate with almost all tags in its range. 1.7 Specific Tag Search and History Tracking The proposed enable both specific tag search and tag history tracking. Similar to FINDERS queue management where data packet are prioritised or dropped using their FTD values (Yang & Wu, 2011: 966), specific tag can be search using the same approach. Since the reader can manipulate can manipulate a set commands such as Select, Query, Req_RN, Read, Write, and ACK and tags can be in different states and ready to reply, acknowledged, and react to a number of command, the reader can search of a specific tag by sending Query_Rep. Through a customised protocol the reader can also search for specific Tag ID. In terms of tag history tracking, the proposed systems similar to FINDER’s object tracking approach, can take advantage of data streams and store it in an RFID data store as semantic data. These include location, relationship among objects or containment relationship, and temporal observations or the history of the movement and behaviours of the object (Ioannidis, 2006:589). 1.8 Tracking Trajectory of Multiple Tags In an RFID system, tracking tag locations require trajectories to be modelled and index. The trajectory of a tag is represented as a line connecting two spatiotemporal locations – location where the tag enters the reader range and the location where it went out of range. However if the tag remains within range for sometime its trajectory will be the point the one captured while the tag enters the reader range as shown below (Ahn et al, 2006:175). The green box represents the tag entering and the leaving the reader range while the black line represents the trajectory. Tracking multiple tags is the same and the recommended method for tracking multiple tags in this type of configuration is distance measurement or Length Dispersion Ratio as shown in the formula below. This is done by comparing the two trajectories. LDRuv = Tu – Tv / max (Tu, Tv); 2. Research Questions a. Is dynamic queue length feasible to the proposed system? b. What is the most suitable memory capacity for each tag in the system that will process multiple tags at the same time? c. Is increasing readers range from 6 to 10 ft improve data transmission, readability and write operations in tags, and minimise collision? d. Is coordination protocol enough to avoid unnecessary data duplication and mixed communications? e. It is necessary to design a specific coordination protocol for the proposed system? f. Is increasing the number of collecting stations an advantage or merely increase data duplication. g. Is network capacity of an RFID system entirely dependent of the quality and capacity of tags and readers? How about location of readers, number of tags, range of readers, and communication protocols? h. Is there any existing tracking protocol that can applied directly to the proposed system i. Is distance measurement enough or there is a much better alternative? 3. References Anh S, Hong B, Ban C, & Lee K, (2006), Design and Implementation of an Index Structure Using Fixed Intervals for Tracing of RFID Tags, Springer, Germany Ioannidis Y, (2006), Advances in Database Technology- EDBT 2006: 10 International Conference on Extending Database Technology, Springer, Germany Meersman R, Tari Z, & Herrero P, (2006), On the Move to the Meaningful Internet Systems, Volume 1, Springer, Germany Park J, Kim K, Ahn S, & Hong B, (2010), Continuous Query Processing on Combined Data Stream: Sensor, Location, and Identification, pp. 518-522 Roussos G, (2008), Networked RFID: Systems, Software, and Services, Springer, Germany Stephanidis C, (2011), Universal Access in Human-Computer Interaction, Springer, Germany Uckelman D, (2012), Quantifying the Value of RFID and the EPCGlobal Architecture Framework in Logistics, Springer, Germany Yang Z. & Wu H, (2011), FINDERS: A Featherlight Information Network with Delay-Endurable RFID Support, IEEE/ACM Transactions on Networking, Vol. 19, No. 4, pp. 961-973 Read More