Every UHF RFID tag in the world carries a tiny piece of state that most people never think about. It has no battery, no processor worth mentioning, and barely enough silicon to hold an EPC number. But tucked inside its memory is a set of four single-bit flags called session flags, and understanding how they work is the difference between a system that reads 500 tags cleanly and one that chokes on 50.
If you have ever watched a reader repeatedly count the same tag over and over, or wondered why two readers pointed at the same population seem to interfere with each other, the answer almost certainly involves sessions. The concept is baked into the EPC Gen2 standard (ISO 18000-63), and it governs something fundamental: how a reader knows which tags it has already talked to and which ones it has not.
Here is the basic problem. A UHF RFID reader does not address tags individually the way a barcode scanner targets one label at a time. Instead, it shouts into the void and waits for responses. When dozens or hundreds of tags respond simultaneously, collisions happen. The reader needs a mechanism to work through the population methodically: talk to one tag, set it aside, move to the next. That mechanism is the inventory round, and sessions are what make inventory rounds work.
The Anti-Collision Problem
Each EPC Gen2 tag maintains four session flags, labeled S0 through S3. Each flag can be in one of two states: A or B. When a reader begins an inventory round, it selects a session and tells the tag population it wants to talk to tags whose flag for that session is currently in state A. As each tag is successfully singulated (read individually without collision), it flips its flag from A to B. Once a tag is in state B for that session, it stops responding to queries on that session. The reader works through the population until no more A-state tags respond, and the round is complete.
Simple enough in principle. The subtlety is in what happens next.
Persistence: How Long Does “Already Read” Last?
The four sessions behave differently in terms of persistence. S0 is volatile. A tag’s S0 flag reverts from B back to A almost immediately after the reader’s RF field goes away, often within a few milliseconds. S1 has a short persistence, typically between 500 milliseconds and 5 seconds depending on the tag. S2 and S3 are the durable ones: their flags persist for at least 2 seconds and can last much longer, with the Gen2 spec allowing persistence of minutes or more depending on implementation.
Why does persistence matter? Because it determines what “already read” means in practice.
Consider a conveyor belt application where items move through a read zone over the course of a second or two. You want each tag read once, reliably, without duplicates. S1 is a reasonable choice. The reader inventories on S1, tags flip to B as they are read, and by the time they exit the read zone, the flag has not yet reverted. A single read per tag. If you used S0 instead, tags would flip back to A almost instantly and the reader would count them again and again for as long as they remained in the field.
Now consider a warehouse with fixed readers mounted at dock doors, and a forklift occasionally driving through with a pallet. You might use S2 or S3 so that tags read at one door do not immediately re-present themselves at the next door a few seconds later. The longer persistence gives downstream readers a window where those tags stay quiet.
Multi-Reader Coexistence
This is where multi-reader environments get interesting. The session mechanism was designed partly to let multiple readers coexist on the same tag population without stepping on each other. If Reader A inventories on S2 and Reader B inventories on S3, they each maintain independent flag state on every tag. Reader A’s activity does not affect how tags respond to Reader B, and vice versa. They can operate simultaneously on overlapping populations without conflict, at least at the session level.
In practice, RF interference and dense reader mode (DRM) protocols add their own complexity, but the session separation is the logical foundation that makes coexistence possible.
Ping-Ponging and Continuous Monitoring
There is a nuance here that catches people out. When a reader sends a Query command to begin an inventory round, it specifies three things that control which tags participate: the session, the target (A or B), and optionally a select mask to filter by EPC or other memory content. The target parameter is what lets a reader deliberately inventory B-state tags. A common pattern is to alternate: inventory A-to-B, then B-to-A, and repeat. This “ping-pong” approach provides continuous monitoring of a tag population because tags that were set aside in one round become available again in the next, without relying on flag persistence timers.
Ping-ponging on S0 is the simplest continuous-read strategy. Because S0 reverts so quickly, a reader using S0 with target A will naturally re-see all tags every round anyway. But explicit ping-ponging on S1, S2, or S3 gives you more control. You can track which tags appeared in each round, detect tags that have left the field (they stop toggling), and build event-level logic on top of raw reads.
This is where session choice starts to affect application architecture, not just RF performance. A system that needs to detect tag arrival and departure events (a portal reader, for example) will behave very differently depending on whether it uses S0 with rapid re-reads and software-based deduplication, or S2 with alternating targets and firmware-level state tracking. Neither approach is inherently better. The right choice depends on tag velocity, population size, reader count, and how much processing you want to push to the edge versus handling in middleware.
Pre-Filtering with Select
One more thing worth understanding: the select command. Before starting an inventory round, a reader can issue Select commands that set session flags on specific subsets of the tag population based on EPC, TID, or user memory content. This is how you can pre-filter a population before inventory, essentially telling certain tags to move to state A or B for a given session before the Query even begins. Combined with sessions, Select gives you a powerful (if sometimes fiddly) toolkit for partitioning and sequencing reads across large or mixed populations.
If you want to see how sessions and flag states interact in real time without needing hardware in front of you, I built an interactive session demo that simulates two readers operating on a single tag. You can watch how each reader’s session choice affects the tag’s flag states independently, and see exactly why session separation matters for multi-reader coexistence. It makes the abstract mechanics concrete in a way that spec documents rarely do.
The Gen2 session mechanism is one of those protocol-level details that separates people who configure RFID systems from people who understand them. Most commercial middleware hides it behind “automatic” mode settings, and for simple applications that is fine. But when read rates drop, when duplicate reads spike, when two readers start fighting over the same tags, sessions are almost always part of the diagnosis. Knowing how they work gives you a vocabulary for asking the right questions, and a mental model for predicting how a system will behave before you ever power it on.
