A Gen2 session is a flag state the tag keeps between inventory rounds. Which session a reader uses decides whether it re-reads tags it has already seen, and whether tags it cannot reach go quiet.
01 / FIELD NOTE
Keep the decision tied to the operating context.
Two readers covering the same shelf can report different sets of tags, and neither is malfunctioning. The usual reason is that they are using different sessions. Understanding sessions explains a class of behaviour that otherwise looks like unreliable hardware.
A passive tag has no battery and no memory of its own beyond what the chip retains, so it cannot simply be told to stay quiet forever. Instead Gen2 defines a small set of flag states, called sessions, that each tag maintains. A tag moves between two states within a session as it is inventoried, and which state it is in when a reader starts an inventory round decides whether that reader gets a reply.
The mechanism is the AB symmetry that replaced the earlier technique of putting tags to sleep. A tag inventoried in a session is flagged one way; when it is inventoried again it flips to the other flag. This avoids the problem of tags that cannot wake up or wake slowly for a new round, because no tag is ever truly asleep — it is simply in the other state.
Gen2 provides four sessions so that different readers can work the same population without interfering with each other's view of it. Two readers using different sessions each inventory the population independently and each sees the full set. Two readers using the same session share the flag state, so a tag that one has just inventoried is in the opposite state for the other and may not answer — which is exactly what a system wants when several readers are covering overlapping areas and only one should count a given tag, and exactly what it does not want when both are supposed to see everything.
Session choice also interacts with how long a tag stays quiet. A session that persists longer keeps a tag in its flagged state for a longer window, which reduces re-reads at the cost of making the tag harder to see for a reader that needs a fresh count. A session that resets quickly gives every reader a clean view at the cost of reading the same tag repeatedly.
The practical guidance follows from what the workflow needs. When a handheld operator walks an aisle and needs every tag reported, including ones a fixed reader saw a moment ago, the handheld should use a session that gives it an independent view. When several fixed readers overlap and each tag should be attributed to one of them, sharing a session is the mechanism that prevents double counting. When a portal has to report every item passing through, whatever the state left behind by an earlier read point, session choice and the reader's persistence settings have to be set together.
This is why a session setting is not a tuning detail to leave at a default copied from another site. It is the mechanism that decides which reader claims a tag, and it has to match the counting rule the business process actually uses.
02 / SESSION EFFECT
The flag decides who sees the tag.
- Different sessions give each reader an independent view
- A shared session lets overlapping readers split the population
- Longer persistence reduces re-reads and slows a fresh count
03 / MATCH THE RULE
Set sessions from the counting rule.
- Every tag reported: independent sessions
- One reader per tag: a shared session
- Every pass reported: session plus reader persistence together
Bring the item, material, movement, target read and system context to a sample or project review.
Request a sample test