<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">SMART: Simple Monitoring enterprise Activities by RFID Tags</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Fabrizio</forename><surname>Angiulli</surname></persName>
							<email>fangiulli@deis.unical.it</email>
							<affiliation key="aff1">
								<orgName type="institution">DEIS-UNICAL Via</orgName>
								<address>
									<addrLine>P. Bucci</addrLine>
									<postCode>87036</postCode>
									<settlement>Rende</settlement>
									<region>CS</region>
									<country key="IT">Italy</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Elio</forename><surname>Masciari</surname></persName>
							<email>masciari@icar.cnr.it</email>
							<affiliation key="aff0">
								<orgName type="institution">ICAR-CNR -Institute of Italian National Research Council</orgName>
							</affiliation>
						</author>
						<title level="a" type="main">SMART: Simple Monitoring enterprise Activities by RFID Tags</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">333ED57AE86005FD4322B0CE4C94766F</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T21:53+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Datastreams are potentially infinite sources of data that flow continuously while monitoring a physical phenomenon, like temperature levels or other kind of human activities, such as clickstreams, telephone call records, and so on. RFID technology has lead in recent years the generation of huge streams of data. Moreover, RFID based systems allow the effective management of items tagged by RFID tags, especially for supply chain management or objects tracking. In this paper we introduce SMART (Simple Monitoring enterprise Activities by RFID Tags) a system based on outlier template definition for detecting anomalies in RFID streams. We describe SMART features and its application on a real life scenario that shows the effectiveness of the proposed method for effective enterprise management.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>In this paper we will focus on Radio Frequency Identification (RFID) data streams monitoring as RFID based systems are emerging as key components in systems devoted to perform complex activities such as objects tracking and supply chain management. Sometimes RFID tags are referred to as electronic bar codes. Indeed, RFID tags emit a signal that contains basic identification information about a product. Such tags can be used to track a product from manufacturing through distribution and then on to retailers. These features of RFID tags open new perspectives both for hardware and data management. In fact, RFID is going to create a lot of new data management needs. In more details, RFID applications will generate a lot of so called "thin" data, i.e. data pertaining to time and location. In addition to providing insight into shipment and other supply chain process efficiencies, such data provide valuable information for determining product seasonality and other trends resulting in key information for the companies management. Moreover, companies are exploring more advanced uses for RFID. For instance, tire manufacturers plan to embed RFID chips in tires to determine the tire deterioration. Many pharmaceutical companies are embedding RFID chips in drug containers to better track and avert the theft of highly controlled drugs. Airlines are considering RFID-enabling key onboard parts and supplies to optimize aircraft maintenance and airport gate preparation turnaround time.</p><p>Such a wide variety of systems for monitoring data streams could benefit of the definition of a suitable technique for detecting anomalies in the data flows being analyzed. As a motivating example you may think about a company that would like to monitor the mean time its goods stay on the aisles. Items are tagged by RFID tags so the reader continuously produces a readings that report the electronic product code of the item being scanned, its location and timestamp, this information can be used, as an example, for signaling that the item lays too much on the shelf since it is repeatedly scanned in the same position. It could be the case that the package is damaged and consequently customers tend to avoid the purchase. If an item exhibits such a feature it deserves further investigation. Such a problem is relevant to a so huge number of application scenario that it is impossible to define an absolute notion of anomalies (in the follow we refer to anomalies as outliers). In this paper we propose a framework for dealing with the outlier detection problem in massive datastreams generated in a network environment for objects tracking and management. The main idea is to provide users a simple but rather powerful framework for defining the notion of outlier for almost all the application scenarios at an higher level of abstraction, separating the specification of data being investigated from the specific outlier characterization.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Preliminaries</head><p>An RFID system consists of three components: the tag, the reader and the application which uses RFID data. Tags consist of an antenna and a silicon chip encapsulated in glass or plastic. RFID readers or receivers are composed of a radio frequency module, a control unit and an antenna to query electronic tags via radio frequency (RF) communication. They also include an interface that communicates with an application (e.g., the check-out counter in a store). Readers can be hand-held or mounted in specific locations in order to ensure they are able to read the tags as they pass through a query zone that is the area within which a reader can read the tag. The query zone are the locations that must be monitored for application purposes. In order to explain the typical features of an RFID application we consider the typical supply chain scenario.</p><p>The chain from the farm to the customer has many stages. At each stage goods are typically delivered to the next stage, but in some case a stage can be missing. The following three cases may occur: 1) the goods lifecycle begin at a given point (i.e. production stages, goods are tagged there and then move through the chain) and thus the reader in the zone register only departures of goods, we refer to this reader as source reader ; 2) goods are scanned by the reader both when they arrive and they leave the aisle, in this case we refer to these reader as intermediate reader ; 3) goods are scanned and the tag is killed, we refer to these readers as destination reader.</p><p>A RFID stream is (basically) composed of an ordered set of n sources (i.e., tag readers) located at different positions, denoted by {r 1 , . . . , r n } producing n independent streams of data, representing tag readings. Each RFID stream can be basically viewed as a sequence of triplets id r , epc, τ s , where: 1) id r ∈ {1, .., n} is the tag reader identifier (observe that it implicitly carries information about the spatial location of the reader) ; 2) epc is the product code read by the source identified by id r and 3)τ s is a timestamp, i.e., a value that indicates the time when the reading epc was produced by the source id r .</p><p>An outlier is an observation that markedly differs from other observations as to lead to the suspect that it was generated by a different mechanism <ref type="bibr" target="#b3">[4]</ref>. There exist several approaches to the identification of outliers, namely, statistical-based <ref type="bibr" target="#b1">[2]</ref>, distance-based <ref type="bibr" target="#b2">[3]</ref>, density-based <ref type="bibr" target="#b4">[5]</ref> and MDEF-based <ref type="bibr" target="#b5">[6]</ref>. The problem has been tackled from different viewpoint and in different scenarios such as static dataset, dynamic dataset and very large dataset <ref type="bibr" target="#b0">[1]</ref>. In our application scenario we deal with massive datastreams that can be viewed as kind of a very large dynamic dataset. Based on the notion of RFID stream introduce so far, it is easy to see that each RFID reading generated by an RFID tag could be an outlier either because 1) the (product) features (obtained by the epc such as price, weight, height and so on) greatly differs from the others readings or 2) the latency time that the tagged item spent in a given location deviates significantly from an expected value.</p><p>In our system we will assume either distance based outlier function or statistical based outlier function to catch both source of anomaly and since we are interested in the problem formalization, we disregard here the actual outlier function implementation. More formally, given a set of objects S, a positive integer k, and a positive real number R. An object o ∈ S is a DB(k, R)-outlier, or a distance-based outlier with respect to parameters k and R, if less than k objects in S lie within distance R from o. This kind of function will be exploited when searching for outliers based on their product features. To deal with deviation on time features we resort to statistical based outlier function. We point out that a formal analysis of the possible outlier detection methods is out of the scope of this paper, we mentioned here the main approaches used in literature since in our system implementation we allow any stream oriented implementation of outlier function to be used. The latter observation guarantees a high flexibility in our system for dealing with every possible application scenarios.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">Statement of the Problem</head><p>In our model, epc is the identifier associated with a single unit being scanned (this may be a pallet or a single item, depending on the level of granularity chosen for tagging the goods being monitored).</p><p>This basic schema is simple enough to be used as a basic schema for a data stream environment, anyway since more information are needed about the outlier being detected we can access additional information by using some auxiliary tables maintained at a M aster site as shown in figure <ref type="figure">2</ref>. More in detail, the M aster maintains an intermediate local warehouse of RFID data that stores information about items, items' movements, product categories and locations and is exploited to provide details about RFID data upon user requests. The information about items' movements are stored in the relation ItemM ovement and the information about product categories and locations are stored in the relations P roduct and Locations, respectively. These relations represents, respectively, the Product and the Location hierarchy. Relation EPCProducts maintains the association between epcs and product category, that is, every epc is associated to a tuple at the most specific level of the Product hierarchy. Finally, RFID readers constitute the most specific level of the Location hierarchy.</p><p>ItemM ovements contains tuples of the form epc, DL , where epc has the usual meaning, and DL is string built as follows: each time an epc is read for the first time at a node N i a trigger fires and DL is updated appending the node identifier.</p><p>In the following we define a framework for integrating DSMS technologies and outlier detection framework in order to effectively manage outliers in RFID datastreams. In particular we will exploit the following features: a) The definition of a template for specifying outlier queries on datastreams that could be implemented on top of a DSMS by mapping the template in a suitable set of continuous queries expressed in a continuous query language language ESLlike <ref type="bibr" target="#b6">[7]</ref>; b) The template need to be powerful enough to model all the interesting surveillance scenarios. In this respect, it should allow the definition of four components, namely: 1) the kind of objects (O) to be monitored (e.g. RFID data concerning dairy products),2) the reference population P (due to the infinite nature of datastream) depending on the application context (e.g. a subset of the items belonging to dairy products category), 3) the attributes (A) of the population used for signing out anomalies (e.g. time spent at a given location), 4) the outlier definition by means of a suitable function F(P, A, O) → {0, 1} (e.g. deviation from the average time spent at a given location by an item); c) A mapping function that for a given template and DSMS schema, resolve the template in a set of outlier continuous queries to be issued on the datastream being monitored.</p><p>The basic intuition behind the template definition is that we want to run an aggregate function that is raises by the Master (that is a central node collecting the queries and the aggregate statistics along with the sample populations) and then instantiated on a subset of nodes in the network. An incoming stream is processed at each node where the template is activated by the M aster that issue the request for monitoring the stream. Once a possible outlier is detected, it is signaled to the M aster. The master maintains management information about the network and some additional information about the items using two auxiliary tables OutlierM ovement and N ewT rend. In the OutlierM ovement table it stores information about the outlying objects, in particular it stores their identifiers and the paths traveled so far as explained above for ItemM ovements. The N ewT rend table stores information about objects that are not outliers but instead they represent a new phenomenon in the data. It contains tuples of the form epc, N, τ a , τ l , , where N is a node, τ a and τ l are, respectively, the arrival time and the time interval spent at node N by the epc. The latter table is really important since it is intended to deal with the concept drift that could affect the data. Indeed, when items are marked as unusual but they are not an anomalies as in the case of varied selling rates they are recorded for later use in outlier definition. In particular, once the new trend has been consolidated, new statistics for the node where the objects appeared will be computed at M aster level and then forwarded to the pertaining node in order to update the parameters of its population.</p><p>As mentioned above candidate outliers are signaled at node level but they are managed by the master. More in detail, as a possible outlier is signaled by a given node the master stores it in the OutlierM ovement table along with its path if it is recognized as an anomaly or in the N ewT rend table if a signaled item could represent the symptom of a new trend in data. To summarize, given a signaled object o two cases may occur: 1) o is an outlier and then it is stored in the Outlier table <ref type="table">;</ref> 2) o represent a new trend in data distribution and then it should not be considered an outlier and we store it in the N ewT rend table.</p><p>To better understand such a problem we define three possible scenarios on a toy example.</p><p>Example 1. Consider a container (whose epc is p 1 ) containing dangerous material that has to be delivered through check points c 1 , c 2 , c 3 in the given order and consider the following sequence of readings:</p><formula xml:id="formula_0">Seq A = {(p 1 , c 1 , 1), (p 1 , c 1 , 2), (p 1 , c 2 , 3), (p 1 , c 2 , 4), (p 1 , c 2 , 5), (p 1 , c 2 , 6), (p 1 , c 2 , 7), (p 1 , c 2 , 8), (p 1 , c 2 , 9), (p 1 , c 2 , 10), (p 1 , c 2 , 11), (p 1 , c 2 , 12)}.</formula><p>Sequence A correspond to the case in which the pallet tag is read repeatedly at the check point c 2 . This sequence may occur because: i) the pallet (or the content) is damaged so it can no more be shipped until some recovery operation has been performed, ii) the shipment has been delayed. Depending on which one is the correct interpretation different recovery action need to be performed. To take into account this problem in our prototype implementation we maintain appropriate statistics on latency time at each node for signaling the possible outlier. Once the object has been forwarded to the master a second check is performed in order to store it either in OutlierM ovement or in N ewT rend table. In particular, it could happen that due to new shipping policy additional checks have to be performed on dangerous material, obviously this will cause a delay in shipping operations, thus the tuple has to be stored in the N ewT rend table.</p><p>Consider now a different sequence of readings:</p><formula xml:id="formula_1">Seq B = {(p 1 , c 1 , 1), (p 1 , c 1 , 2), (p 1 , c 1 , 3), (p 1 , c 1 , 4), (p 1 , c 3 , 5), (p 1 , c 3 , 6), (p 1 , c 3 , 7), (p 1 , c 3 , 8), (p 1 , c 3 , 9), (p 1 , c 3 , 10), (p 1 , c 3 , 11), (p 1 , c 3 , 12)}.</formula><p>Sequence B correspond to a more interesting scenario, in particular it is the case that the pallet tag is read at check point c 1 , is not read at check point c 2 but is read at checkpoint c 3 . Again two main explanation could be considered: i) the original routing has been changed for shipment improvement, ii) someone changed the route for fraudulent reason (e.g. in order to steal the content or to modify it). In this case suppose that the shipping plan has not been changed, this means that we are dealing with an outlier then we store it in the OutlierM ovement table along with its path.</p><p>Finally, consider the following sequence of readings regarding products p 1 , p 2 , p 3 that are frozen foods, and product p 4 that is perishables, all readings generated at a freezer warehouse c: Seq C = {(p 1 , c, 1), (p 2 , c, 2), (p 3 , c, 3), (p 4 , c, 4), (p 1 , c, 5), (p 2 , c, 6), (p 3 , c, 7), (p 4 , c, 8), (p 1 , c, 9), (p 2 , c, 10), (p 3 , c, 11), (p 4 , c, 12)}. Obviously, p 4 is an outlier for that node of the supply chain and this can be easily recognized using a distance based outlier function since its expiry date greatly deviates from the expiry dates of other goods.</p><p>The Template in a short In this section we will describe the functionalities and syntax of the T emplate introduced so far. A T emplate is an aggregate function that takes as input a stream. Since the physical stream could contain several attributes as explained in previous sections we allow selection and projection operation on the physical stream. As will be clear in next section we will use a syntax similar to ESL with some specific additional features pertaining to our application scenario. This filtering step is intended for feeding the reference population P . In particular, as an object is selected at a given node it is included in the reference population for that node using an Initialize operation, it persists in the reference population as a Remove operation is invoked (it can be seen as an Initialize operation on the tuples exiting the node being monitored).</p><p>We recall that a RFID tagged object is scanned multiple times at a given node N so when the reader no more detects the RFID tag no reading is generated. First time an object is read a V alidate trigger fires and send the information to the M aster that eventually updates the ItemM ovement table. In response to a V alidate trigger the M aster performs a check on the item path, in particular it checks if shipping constraints are so far met. In particular, it checks the incoming reading for testing if the actual path so far traveled by current item is correct. This check can be performed by the following operations: 1) selection of the path for that kind of item stored in ItemM ovement, 2) add the current node to the path, 3) check the actual path stored in an auxiliary table DeliveryP lans storing all the delivery plans (we refer to this check as DELIVERY CHECK ). This step is crucial for signaling path anomalies since as explained in our toy examples that source of anomaly arise at this stage. If the item is not validated the M aster stores the item information in order to solve the conflict, in particular it could be the case that delivery plans are changing (we refer to this check as NEW PATH CHECK ) so information is stored in N ewT rend table for future analysis , otherwise it is stored in the OutlierM ovement table. To better understand this behavior consider the Seq B in example 1. When the item is first time detected at node c 3 the V alidate trigger fires, the path so far traveled for that object is retrieved obtaining path = c 1 , the current node is added thus updating path = c 1 .c 3 but when checked against the actual path stored in DeliveryP lans an anomaly is signaled since it was supposed to be c 1 .c 2 .c 3 . In this case the item is stored in the OutlierM ovement table and the M aster signal for a recovery action. It works analogously for Seq A as explained in example 1.</p><p>When an epc has been validated it is added to the reference population for that node (P N ) then it stays at the node and is continuously scanned. It may happen that during its stay at a given node an epc could not be read due to temporary field problem, we should distinguish this malfunction from the "normal" behavior that arise when an item is moved for shipping or (in case of destination nodes) because it has been sold. To deal with this feature we provide a trigger F orget that fires when an object is not read for a (context depending) number of reading cycles (we refer in the following as TIMESTAMP CHECK. We point out that this operation is not lossy since we recall that at each node we maintain (updated) statistics on items. When F orget runs, it removes the "old" item from the actual population and update the node statistics. Node statistics (we refer hereafter to them as model M where N is the node they refer to) we take into account for outlier detection are: number of items grouped by product category (count), average time spent at the node by items belonging to a given category (m), variance for items (v) belonging to a given category, maximum time spent at the current node by items belonging to a given category (max t ), minimum time spent at the current node by items belonging to a given category (min t ). By means of the reference population P N and the node statistics model N the chosen outlier function checks for anomalies. In particular, we can search for two kind of anomalies: 1) item based anomalies, i.e. anomaly regarding the item features, in this case we will run a distance-based outlier detection function; 2) time based anomalies, i.e. anomaly regarding arrival time or latency time, in this case we will run a statistical based outlier detection function.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">The RFID-T syntax</head><p>In this section we formalize the syntax for template definition. For basic stream operation we will refer to ESL-like syntax <ref type="bibr" target="#b6">[7]</ref>. We point out that even if in this paper we focus on RFID data and outlier detection task, the framework is rather general and could be exploited in several application domains and for other task such as aggregate queries evaluation.</p><p>The first step is to create the stream related to nodes being monitored. Once the streams are created at each node the T emplate definition has to be provided.</p><p>Aggregate function can be any SQL available function applied on the reference population as shown in Fig. <ref type="figure">5</ref>, where Return and N ext have the same interpretation as in SQL and &lt; T ype &gt; can be any SQL aggregate function. An empty T ERM IN AT E clause refer to a non-blocking version of the aggregate.</p><p>As the template has been defined it must be instantiated on the nodes being monitored. In particular triggers V alidate and F orget are activated at each node. As mentioned above they will continuously update the reference population and node and M aster statistics. The syntax of these triggers is shown in figure <ref type="figure">6</ref>.</p><p>We point out again that V alidate trigger has the important side-effect of signaling path outliers. We point out that the above presented definition is completely flexible so if the user may need a different outlier definition she simply needs to add its definition as a plug-in in our system.</p></div>		</body>
		<back>
			<div type="annex">
<div xmlns="http://www.tei-c.org/ns/1.0"><head>CREATE STREAM</head></div>			</div>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">DOLPHIN: An Efficient Algorithm for Mining Distance-Based Outliers in Very Large Datasets</title>
		<author>
			<persName><forename type="first">F</forename><surname>Angiulli</surname></persName>
		</author>
		<author>
			<persName><forename type="first">F</forename><surname>Fassetti</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">TKDD</title>
		<imprint>
			<biblScope unit="volume">8</biblScope>
			<biblScope unit="issue">1</biblScope>
			<date type="published" when="2009">2009</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<monogr>
		<title level="m" type="main">Outliers in Statistical Data</title>
		<author>
			<persName><forename type="first">V</forename><surname>Barnett</surname></persName>
		</author>
		<author>
			<persName><forename type="first">T</forename><surname>Lewis</surname></persName>
		</author>
		<imprint>
			<date type="published" when="1994">1994</date>
			<publisher>Wiley and Sons</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<analytic>
		<title level="a" type="main">Distance-based outlier: Algorithms and applications</title>
		<author>
			<persName><forename type="first">R</forename></persName>
		</author>
		<author>
			<persName><forename type="first">Ng</forename><forename type="middle">E</forename><surname>Knorr</surname></persName>
		</author>
		<author>
			<persName><forename type="first">V</forename><surname>Tucakov</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">VLDB J</title>
		<imprint>
			<biblScope unit="volume">8</biblScope>
			<biblScope unit="issue">3-4</biblScope>
			<biblScope unit="page" from="237" to="253" />
			<date type="published" when="2000">2000</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">Identification of Outliers</title>
		<author>
			<persName><forename type="first">D</forename><surname>Hawkins</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Monographs on Applied Probability and Statistics</title>
				<imprint>
			<publisher>Chapman and Hall</publisher>
			<date type="published" when="1980">1980</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">Lof: Identifying density-based local outliers</title>
		<author>
			<persName><forename type="first">R</forename><surname>Ng</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Sander</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><forename type="middle">M</forename><surname>Breunig</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Kriegel</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the International Conference on Managment of Data (SIGMOD00)</title>
				<meeting>the International Conference on Managment of Data (SIGMOD00)</meeting>
		<imprint/>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">Loci: Fast outlier detection using the local correlation integral</title>
		<author>
			<persName><forename type="first">P</forename><surname>Gibbons</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Papadimitriou</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Kitagawa</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Faloutsos</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the International Conference on Data Enginnering (ICDE)</title>
				<meeting>the International Conference on Data Enginnering (ICDE)</meeting>
		<imprint>
			<date type="published" when="2003">2003</date>
			<biblScope unit="page" from="315" to="326" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<monogr>
		<title level="m" type="main">An introduction to the Expressive Stream Language (ESL)</title>
		<author>
			<persName><forename type="first">H</forename><surname>Thakkar</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Wang</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y</forename><surname>Bai</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><forename type="middle">C</forename><surname>Luo</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Zaniolo</surname></persName>
		</author>
		<imprint/>
	</monogr>
	<note type="report_type">Tech. Report</note>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
