How the Gen 2 protocol works

The basic operation of EPCglobal Class 1 Generation 2 is similar to other air interface protocols, and to most passive RFID protocols: Passive RFID readers need to provide power to the tags they intend to read, give commands to the tags, and receive responses. This is the essential action that allows the RF to transit the ID.

The RFID reader does not generally know how many tags are in position to respond, so it has to somehow allocate the “right to talk” to individual tags in a population of unknown size. This need has implications for how the reader should be configured to read your tags.

In many cases your reader or middleware will hide the details of the Select operations we describe here. The good news is you probably will not need to count bits as we do below. With less friendly user interfaces, you may encounter requests for such elements as the mask, pointer, length and action. Even if you are not required to calculate any of this, it doesn’t hurt to understand what’s going on under the hood.

The first thing a reader does when it starts an inventory operation is to send continuous wave power (CW) – a signal of constant frequency and amplitude – the purpose of which is to get the tags started up. This takes a few milliseconds. After the power-up step is done, the reader may send one or more Select commands. Select commands are Gen 2’s way of allowing the user to decide which kind of tags should respond to a given inventory.

THE SELECT COMMAND

The syntax of the Select command is complex, but the purpose is simple: tags are told whether to reply, or not, based on the value of bits in their memory. Select works by setting flag values in the tag; these values are then used when the reader asks for the tags to send relevant data with a Query command.

For example, let’s imagine we are operating a portal reader at a loading dock, and are receiving a shipment from a specific manufacturer. We know that all the tags we care about at the moment are from this vendor, and we remember that portal readers can sometimes read tags in staging areas, people’s pockets, and other unlikely places having nothing to do with the packages we are trying to identify. It might not be a bad idea to have only tags from this specific vendor respond to our queries. How can we arrange such a feat?

We start with EPCglobal’s standard for converting a GTIN (the familiar bar code number) into an electronic product code or EPC, stored in the tag. A typical EPC representing a serialized GTIN would start with a header value of 48 (indicating GTIN conversion), followed by 3 bits for the type (e.g. 3 = case), and 3 bits indicating the partition of the remainder.

A partition value of 5 tells us that the 24 bits are devoted to the manager number: the unique vendor ID that we’re trying to find. So in the situation described above, we need to tell our interrogator (RFID reader) to look for tags whose EPC contains that particular vendor’s number (for example, 0078742).

To do it we need to send a Select command with a “mask.” The mask is a set of bits that identify which tags should respond to the current Query. In addition to the bits themselves, we need to specify the memory location of these bits. To know how to figure this out, you need to know how the tag memory is organized. Fortunately, the Gen 2 standard is fairly specific on this issue (Figure 1).

Figure 1: memory organization of an EPCglobal Class 1 Gen 2 tag

There are four memory banks, each constructed of two-byte words. The EPC is always found in bank 01 (that’s 1 in ordinary decimal notation). The first word of bank 01 is the CRC16, an error check code that is calculated by the tag when it powers up. The second word is the protocol control word (often abbreviated PC with no political connotations intended), which contains some descriptive information including the length of the EPC in bits. Finally, the EPC is found in word 3.