This document describes the design of the edge server tag data layer.

High Level

The purpose of the tag data layer serves three main purposes

1. To provide a base set of classes that reader adapters can use to store tag reads and send them up to a higher layer in the edge server. In addition the the edge server can use these classes to store tag information which the reader adapters can use to write data to tags. This service is, for now, concerned with C1G2 and C1G1 tags.
2. To provide the necessary algorithms to convert between various ID encodings and their representations. Currently this is primarily concerned with the EPC encodings such as SGTIN and GID. This service allows a bit string to be converted to a URN representation, for example.
3. To provide hooks that allow some other aggregating, filtering, or reporting services to use the data that has been collected. For now this is primarily concerned with ALE.

It is important to note that these services, while now aimed at an implementation of EPC Gen1 and Gen2 tags and using ALE to aggregate and report data, are general enough to support future extensions. For example, it is possible to use ALE to report non-epc data that is not stored on a physical tag adhering to a EPCGlobal spec. Therefore the three main services are distinct and are loosely coupled.

Physical Tag Layer

The point of the physical tag layer is to provide some base abstractions to store data obtained from a tag read. The data at this level is raw -- the bits are not interpreted or encoded. It is intended to be easy to use by developers who are writing code that interacts with RFID readers to obtain tag reads. In addition it is intended to be extensible so that new physical tag models can be developed when needed. Below is a class diagram describing the physical tag layer in the edge server.

• The TagData class represents a single tag read. It has two main data structures:
  • The model<code> represents the bits that were read
  • The <code>metainformation is a hashmap to store other information about the tag read, such as a timestamp, antenna number, and other information not stored on the tag itself, but which may be useful to a higher level application
• The PhysicalTagModel is an abstract class that serves as a base class for various concrete Physical Tag Models. This class does not require many methods to be implemented because it is imagined that tag models can behave in very different ways. For example, while some tags -- such as C1G2 use a "memory bank" paradigm, others might follow a "file access" model.
• The concrete classes -- C1G1PhysicalTagModel and C1G2PhysicalTagModel provide data structures that mimic the EPC specifications from a data point of view (they do not mimic state changes, such as locking and killing). Data models other than EPCGlobal-specified ones could be introduced at this level
• The Physical Tag Layer also provides some classes that can be reused across many kinds of PhysicalTagModels, such as a BitVector that facilitates storing and manipulating bits as well as a class that helps convert between various representations of numbers (bits to hex, and so forth).

EPC Layer

The EPC layer is a set of algorithms that convert between various representations of EPC-encoded bits. While the Physical Tag Layer views information only in terms of bits, the EPC layer knows how to encode and decode this information. For example, with the EPC layer can convert this string of bits:

001100000000100000110011101100101101110111011001000000010100000000110101000001010000000000000000

into this URI, encoded in Tag-URI format:

urn:epc:tag:sgtin-96:0.0867360217.005.889520128

and can take that URI and convert it into this URI encoded in Pure-URI format:

urn:epc:id:sgtin:0867360217.005.889520128

The EPC Layer is based on the Tag Data Specification from EPCGlobal. It relies on the TDT library from the open source Fosstrak project.

It is again important to point out that this layer is separate from the Physical Tag Layer -- A PhysicalTagModel other than a C1G1 or C1G2 PhysicalTagModel could potentially store EPC information. In addition, it is possible that a EPC tag could store data that is not encoded as an EPC.

ALE Layer

While the ALE layer is contains other classes than those just used by the tag data layer, it does provide interfaces necessary for it to aggregate, filter, and report tag data. The ALE layer defines what contracts a PhysicalTagModel needs to fulfill in order for ALE to be able to use it. In addition the ALE specification defines datatypes, formats, and fields that are used at the ALE level to report tag data.

The ALE Specification defines three data structures that are important with regards to tags:

Fields

A field is a specific data item that resides on a tag. The fields define the ALE-Tag interface. If the ALE layer needs some data from a tag, it asks for a certain field. For example, there is the epc field, and the userBank field. It is important to note that the meaning of the field depends on the type of tag that is reporting the data. For example, for a gen2 tag, the epc field refers to the toggle bit, the AFI, and the EPC as defined in the gen2 spec. For a gen1 tag, the epc refers to only the epc payload. For a different tag model, it could refer to something completely different. In addition, each field has an associated set of datatypes that are valid for that field. A field also has a default datatype and a default format for that datatype.

Data Types

The ALE specification defines several built-in datatypes for the use of intrepreting data. Each datatype has an associated set of formats that it can report the data in. For example, the unsigned integer (uint) data type can report data in either hex or decimal format.

Formats

A format defines a syntax for reporting data of a certain format. For example, for the epc datatype, there are four valid formats: epc-tag, epc-pure, epc-hex, and epc-decimal.

ALE Physical Tag Model Adapter

Because the semantics of fields depend on the type of tag that ALE is asking about, the PhysicalTagModel needs to provide that information to the ALE layer. This is done through an adapter. Each concrete implementation of the PhysicalTagModel provides an ALEPhysicalTagModelAdapter to the ALE layer. This adapter knows how to get a specific field from its own kind of PhysicalTagModel. This way the ALE layer does not need to care about what kind of tag model (e.g. C1G1, C1G2, savi, etc) it is dealing with. It simply needs to ask the adapter for the field.

As an example, suppose a Gen1 tag was read. The ALE layer is interested in knowing the epc field from that tag. The abstract super class of the tag model -- PhysicalTagModel provides an adapter to the ALE layer. The ALE layer then calls the getEPC() on the adapter. Since the adapter contains the logic for figuring out that the epc field only refers to the epc payload of memory bank 0 on the Gen1 Tag, the ALE layer does not have to worry about the fact that this tag is a gen1 tag.

Packages

• ALE Layer - blue
• Physical Tag Layer - pink
• EPC Layer - green

org.rifidi.tags

The org.rifidi.tags package contains the base classes that can be used by all kinds of different implementations of physical tag models. For example, it contains the PhysicalTagModel abstract class, the TagData class, and the BitVectorclasses among others

org.rifidi.edge.tags.epc

The org.rifidi.edge.tags.epc contains the specific implementations of PhysicalTagModel for Class 1 Gen 1 and Class 1 Gen 2 tags.

org.rifidi.tags.encodings.epc

This package has several packages that wrap the org.fosstrak.tdt libraries to help convert EPCs between various encodings and formats as defined in the EPCglobal Tag Data Specification. It basically provides an interface into the tdt classes.

org.fosstrak.tdt

This package does the heavy lifting of translating tags between various formats.

org.rifidi.edge.ale

This package defines the contracts that concrete implementations of PhysicalTagModel must fulfill in order to be used by ALE. In addition it defines all the necessary datatypes and formats required by ALE.

org.rifidi.edge.tags.epc.ale

This package provides the ALE adapters for the C1G1 and C1G2 tags. It is separated from org.rifidi.edge.tags.epc in order to allow the org.rifidi.edge.tags.epc package to be independent from ALE.

Use Cases

Reading a Tag

The most common usecase for using these classes is when a reader adapter is reading a tag. In this case, a new PhysicalTagModel is created for the kind of tag being read (e.g. C1G2PhysicalTagModel). This object will be placed inside an instance of TagData. This class is put on the queue and sent to the receiver.

Writing data to a Tag

This use case has not been implemented yet.