EPC Gen2 UHF RFID Protocol

Air interface fundamentals — reader-talks-first, backscatter and the physical-layer behaviour

A passive UHF tag is the most reluctant participant in any radio conversation: it carries no battery, says nothing until a reader floods it with energy, and then answers only by subtly changing how it reflects that same energy back. It is, in effect, a device that communicates by choosing how to stay quiet — and somehow this is the bedrock of a global supply-chain ecosystem. EPC Gen2 is a reader-talks-first backscatter protocol. The reader provides all the RF energy; the tag harvests energy from the reader's carrier to power its circuitry and modulates (reflects) the carrier to communicate back. Understanding the physical-layer behaviour is the starting point for understanding every higher-layer behaviour, because read range, read rate and protocol timing all derive from the reader's transmit power and the tag's energy-harvesting efficiency.

• Continuous-wave carrier and modulation. The reader transmits a continuous-wave (CW) carrier at the operating frequency. The tag absorbs energy to power its IC and periodically changes the impedance of its antenna, which modulates the backscattered signal. The reader receives the backscattered signal superimposed on its own transmitted carrier.
• Forward-link modulation: reader-to-tag commands use PIE (Pulse-Interval Encoding) with DSB-ASK (Double Side-Band Amplitude Shift Keying) or PR-ASK (Phase-Reversal ASK) depending on regional regulations. Tari (the reference time interval) and the R→T (reader-to-tag) data rate are configurable parameters tuned for the environment and the regulatory regime.
• Reverse-link modulation: tag-to-reader responses use FM0 or Miller-modulated subcarrier encoding, with link frequencies typically in the 40-640 kHz range. The modulation choice balances data rate against interference immunity, and dense-reader environments typically run higher Miller subcarrier depth for better reader-to-reader co-existence.
• Sensitivity budget: read range is governed by the link budget, which has three legs: reader to tag forward link (how much energy reaches the tag), tag harvest efficiency (how effectively the tag converts incident RF to DC for the IC), and tag to reader reverse link (how strong the backscattered signal is at the reader). Chip sensitivity (typically -18 to -24 dBm for modern RAIN chips) is the key forward-link figure.
• Regional regulatory envelopes: Gen2 operates within regional UHF allocations: 865-868 MHz Europe with 2W ERP and LBT under EN 302 208; 902-928 MHz North America with 4W EIRP and frequency-hopping under FCC Part 15.247; 916.7-923.5 MHz Japan; 920-925 MHz China. Tag antenna tuning and reader configuration differ by regulatory regime, and truly global tags use broader-band antennas that compromise peak performance for regional flexibility.
• Dense-reader-mode operation. In environments with many concurrent readers (distribution centres, retail stores, supply-chain portals), the dense-reader-mode operating parameters manage inter-reader interference. Channel separation, subcarrier choice and session/target management together determine how many readers can run simultaneously without degrading inventory performance.
• Link timing: command-response timing is precisely defined by the protocol: T1 is the maximum tag response time after a reader command, T2 is the minimum reader response time after a tag reply, T3 is the reader-to-reader hold-off, and T4 is the reader idle time before next command. Timing accuracy is critical for reliable anti-collision behaviour.

Memory bank architecture — Reserved, EPC, TID and User banks explained

Gen2's memory model is the protocol's most architecturally important feature because it creates a stable addressing framework for every application built on top. Understanding what each bank is for, how it is addressed, how it is protected, and how it typically is populated is essential for anyone designing a Gen2 data architecture beyond the default EPC-only read.

• Memory bank addressing: Gen2 organizes tag memory into four banks numbered 0 through 3, with reads and writes specifying the bank number, the starting word offset and the word count. Bank 0 is Reserved, Bank 1 is EPC, Bank 2 is TID, Bank 3 is User. Each bank has its own length, its own typical content and its own protection model.
• Reserved bank (Bank 0). Stores the 32-bit access password and the 32-bit kill password at fixed memory addresses. The access password gates the secured protocol state where write and lock operations are permitted; the kill password permanently disables the tag when issued correctly. Reserved bank data is not included in the inventory response. It must be explicitly read with the tag in the secured state.
• EPC bank (Bank 1). Stores the CRC, the Protocol Control word (PC), and the Electronic Product Code itself. The PC encodes the EPC length, whether the tag is compliant with Gen2v2 features, and an optional 'StoredPC Extension' for encoded data. The EPC is the primary identifier read during normal inventory, and modern deployments typically use 96-bit EPCs encoded per GS1 SGTIN-96, SSCC-96, GRAI-96 or other scheme-specific formats.
• TID bank (Bank 2). The Tag Identifier is factory-programmed and typically read-only, containing a class identifier, the chip manufacturer's Tag Designer ID, and a chip-specific serial or model number. Many modern chips include a unique 32 or 64-bit serial in the TID that guarantees chip-level uniqueness even when EPC memory is reprogrammed. The TID is the foundation of tag authentication because it cannot be cloned simply by copying the EPC.
• User bank (Bank 3). Variable-size application-specific memory. Low-cost chips have no User memory (Impinj M730 / M830, NXP UCODE 9 base, UCODE 9xe); mid-range chips have 32-128 bits (M750 / M775 / M850, M770 64-bit, M780 + Higgs-EC 128-bit); large-user-memory chips have 512-752 bits (Impinj M781 512-bit, Alien Higgs-9 688-bit, NXP UCODE 9xm 752-bit); the only mainstream UHF chips reaching 2-64 kilobits are NXP UCODE DNA (3 kbit / 384 byte) and Impinj Monza X-2K / X-8K (16-64 kbit, HF+UHF dual-frequency), plus Fujitsu MB97R FRAM (8 KB / 64 kbit). User memory stores maintenance records, calibration data, batch identifiers, lot codes, temperature-log excerpts, or any custom data the application requires.
• EPC encoding schemes: the GS1 family of encoding standards defines how the EPC field is populated. SGTIN-96 for retail trade items encodes a GS1 Company Prefix, item reference and serial number into 96 bits. SSCC-96 for shipping containers encodes extension digit, Company Prefix and serial. GRAI-96 is for returnable assets, GIAI-96 is for individual assets, ADI-96 is for aerospace parts, and several others exist for specific industries.
• Write-once and permalock behaviour. Gen2 supports permanent locking of memory, making writes impossible for the life of the tag. Permalock is a one-way operation useful for applications where the EPC should never change after manufacture (serialized parts, pharmaceutical unit packaging). Conventional lock makes the memory writable only in the secured state, allowing authorized updates without permanent commitment.

Anti-collision mechanics — the Q-algorithm, inventory rounds and slot mechanics

Anti-collision is the part of the protocol that has no right to work as well as it does: a crowd of tags, all mute until addressed and none aware of each other, somehow take turns without a conductor. The protocol's ability to read thousands of tags per second in dense populations rests on the Q-algorithm, a slotted-Aloha variant adapted for RFID's one-sided forward link. Understanding how the Q-algorithm works, how readers tune Q for different population sizes, and how session and target state management coordinate with anti-collision is the core of Gen2 performance engineering.

• Inventory-round structure: a reader conducts an inventory round by issuing a Query command with a Q parameter in the range 0-15, specifying 2^Q timeslots for tags to respond in. Each tag selects a random slot and transmits its preamble and RN16 (a 16-bit random number) in its chosen slot.
• Q parameter tuning: the reader tunes Q to the estimated tag population. For a single tag, Q=0 gives one slot and the tag always responds. For 1000 tags, Q=10 (1024 slots) distributes responses across slots to minimize collisions. Modern readers use Q adjustment heuristics, incrementing Q when slots are empty (indicating population overestimate), decrementing Q when collisions occur (indicating slot shortage), and adapting in real time as the population changes.
• Slot mechanics: in each slot the reader issues a QueryAdjust (to change Q) or QueryRep (to move to the next slot). Tags that selected the current slot transmit their RN16 preamble; the reader ACKs the RN16 if it received one cleanly; the tag then responds with its EPC; the reader issues a QueryRep to move on. Slots with zero responses or with unresolvable collisions are skipped forward.
• Collision resolution: when two tags respond in the same slot, the reader typically cannot decode either response and treats the slot as a collision. The Q-algorithm adjusts Q upward to spread subsequent inventory across more slots, probabilistically resolving collisions. Some advanced readers implement collision-recovery algorithms that extract partial information from colliding responses, but the baseline protocol simply re-inventory.
• Session management: Gen2 defines four sessions (S0, S1, S2, S3), each with independent flag states per tag. When a tag responds in a session, its flag is toggled and it stops responding in that session until the flag is reset. Session flags have different persistence. S0 resets when the tag loses power, S1 has a millisecond-scale persistence timer, S2 and S3 persist for seconds to hours.
• Target state (A/B). Within each session, tags have a target flag that can be A or B. Readers inventory tags with target=A, which toggles their flag to B; a subsequent Query targeting B then inventories the same population again. Alternating A/B inventory lets readers cycle through a tag population repeatedly with known state.
• Dense-reader session strategy. In multi-reader environments, operators assign different sessions to different readers so that reader-1's inventory does not reset reader-2's tag states. A typical strategy is reader-1 on S2 and reader-2 on S3, ensuring that each reader sees its tag population with minimal interference from the other. Dense-reader tuning is one of the highest-leverage optimizations in production deployments.

Security and access control — passwords, lock, kill and the Gen2 baseline

Gen2's baseline security model is modest but useful: access passwords gate writes and locks, kill passwords permanently disable tags, and lock commands control memory-protection state. The baseline is sufficient for many supply-chain applications but is not cryptographic authentication. That lives in the Gen2v2 extensions covered in the next section. Understanding the baseline model clarifies what Gen2 does and does not protect against.

• Access password: a 32-bit value stored in Reserved memory that gates entry to the secured state. A tag in the open state responds to inventory and EPC reads; to write, lock or modify protected memory, the reader must authenticate with the access password. The default access password is 0x00000000 (no protection); customers set an application-specific password during initial programming.
• Secured state and access commands. When the reader issues an Access command with the correct password, the tag transitions to the secured state and accepts Write, BlockWrite, Erase, Lock and Kill commands. The secured state persists until the tag loses power or receives a state-transition command.
• Lock command and lock bit states. Each memory bank has four possible lock states: unlocked, perma-unlocked, locked, permalocked. Unlocked allows writes freely; locked allows writes only in the secured state; perma-unlocked is permanently writable; permalocked is permanently unwritable. Lock-state choice is a trade-off between write flexibility and tamper resistance.
• Kill password and kill command. A 32-bit kill password enables the Kill command, which permanently disables the tag. Kill is used at retail point-of-sale to prevent post-purchase tracking, at end-of-life for pharmaceutical unit packaging, and in other privacy-sensitive scenarios. Kill is irreversible: a killed tag is electronically equivalent to a non-functional part.
• Privacy limitations of the baseline. The baseline password model protects writes and enables deactivation but does not encrypt EPC reads. Any reader in range can read the EPC of an unlocked tag, and since the EPC typically encodes the GS1 product identifier, anyone nearby can potentially identify the product. For applications where this exposure matters (government IDs, military equipment, high-value consumer goods), the Gen2v2 untraceable-mode and crypto-suite features add stronger protection.
• Password management at scale. In production deployments, factory-level password setting and per-tag or per-batch password management is a non-trivial operational discipline. Password storage, access-control logging and password rotation procedures need enterprise-grade handling to be credible at scale, and this is one of the practical operational engineering areas where Proud Tek and other mature suppliers add value for enterprise customers.
• TID-based authentication: because the TID is factory-programmed and read-only, an EPC-plus-TID verification scheme provides a form of tag authentication even without cryptographic features. An application that checks the TID against a known-good database detects simple clones that copy only the EPC. Modern chips with unique TID serials make this check operationally useful for anti-counterfeiting in mid-security applications.

Gen2v2 extensions — crypto-suite, file management, loss prevention and untraceable mode

The Gen2v2 amendment, ratified in 2013 and incorporated into ISO/IEC 18000-63 in its 2013 update, extends the original Gen2 protocol with optional features for authentication, structured data and privacy. Gen2v2 is backward compatible (a Gen2v2 chip interoperates with Gen2-only readers for basic inventory) but the extended features require reader support to access. Understanding the Gen2v2 feature set clarifies what the current generation of chips can do beyond the baseline.

• Crypto-suite framework: Gen2v2 defines an authentication framework with registered crypto-suites for symmetric encryption. Registered crypto-suites include AES-128 (suite 0x21), PRESENT-80 (suite 0x22), and others adopted through the ISO process. A chip supporting a crypto-suite can perform cryptographic challenge-response authentication with a reader that implements the same suite.
• Authenticated read and tag authentication. The Authenticate command lets a reader verify that a tag knows a shared secret, cryptographically proving the tag is genuine rather than a clone. NXP's UCODE DNA family implements this with AES-128 and is the leading chip family for brand-authentication applications that need cryptographic verification rather than TID-only checks.
• File management (FileList, FileOpen, FilePrivilege). Gen2v2 defines file-based organization within User memory, letting applications structure data as named files rather than raw memory offsets. File-level access control supports multi-tenant applications where different vertical users (manufacturer, logistics, maintenance, end-of-life) access different sections of the tag.
• Untraceable command: the Untraceable command puts a tag into a privacy-aware mode where inventory responses return limited information and access requires the proper secret. Used in consumer-facing applications after sale to limit post-purchase tracking, while still allowing authorized applications (returns, recycling) to access the tag with the correct credentials.
• Secure-access commands: ReadBuffer, BlockPermalock and authenticated variants of read/write provide more granular control over secure memory operations than the Gen2 baseline. These commands are used in deployments where structured secure access patterns (for example, incremental authenticated reads of a long secure data file) are required.
• Chip-family support: Gen2v2 features are supported by modern chip families: NXP UCODE 9 and UCODE DNA implement crypto-suite authentication; Impinj Monza R6 and M-series implement various Gen2v2 feature subsets; specialized chips for high-security applications implement additional features. Chip datasheets specify which Gen2v2 features are supported, and applications should verify feature-level compatibility rather than relying on generic 'Gen2v2 compliant' claims.
• Backward-compatibility rules: Gen2v2 chips must remain readable by Gen2-only readers for basic inventory, ensuring that deployments with mixed reader infrastructure continue to function. The extended Gen2v2 features are invisible to Gen2-only readers but usable by Gen2v2-aware readers. This compatibility property is essential for large-scale ecosystem migration from Gen2 baseline to Gen2v2 features.

Dense-reader-mode engineering — channel planning, session tuning and real-world throughput

A single reader in a quiet environment can comfortably read 1,000+ tags per second. A dense distribution centre with many readers running simultaneously in overlapping fields is a materially harder engineering problem, and the real throughput figures that enterprise deployments achieve depend on channel planning, session tuning, antenna placement and regulatory envelope. Understanding the dense-reader engineering discipline is the difference between laboratory throughput figures and deployed performance.

• Channel planning: within the regional band (for example, 902-928 MHz in North America), the reader frequency-hops across channels (50 channels of 500 kHz in the FCC-regulated band). Multiple readers in the same facility are scheduled to avoid channel collision through reader middleware, typically coordinated through LLRP-enabled reader management.
• Session assignment: assigning different sessions (S0, S1, S2, S3) to different readers prevents each reader from resetting the other's inventory flag states. Typical patterns assign long-range portals to S2 or S3 and short-range handhelds to S0 or S1, reflecting the different persistence requirements of each use case.
• Antenna isolation and placement. Physical antenna placement to minimize inter-reader field overlap, and use of antenna polarization (linear vs circular, horizontal vs vertical) to isolate overlapping read zones, are practical engineering techniques that materially improve dense-reader performance. Stream-of-consciousness 'more power solves everything' tuning is usually counterproductive.
• Listen-before-talk (LBT) in Europe. EN 302 208 requires LBT behaviour above certain power levels in the core European band. LBT adds latency to each read (the reader must check the channel before transmitting) and interacts with dense-reader coordination differently than the US frequency-hopping regime. European dense-reader deployments tune channel and session assignment to minimize LBT-induced overhead.
• Throughput degradation under interference. When multiple readers operate in overlapping fields without proper coordination, inventory round lengths stretch dramatically and effective throughput can fall to 10-30% of single-reader performance. Measuring deployed throughput and tuning channel/session/antenna until throughput matches expectation is a standard commissioning workflow in enterprise deployments.
• Reader middleware role: LLRP (Low-Level Reader Protocol) and proprietary reader-management middleware coordinate channel assignment, session assignment and inventory scheduling across reader fleets. Mature middleware automates much of the dense-reader tuning that otherwise requires manual configuration.
• Realistic throughput expectations: enterprise deployments should plan for 400-800 tags per second per reader under real operating conditions, not the 1,500+ theoretical maximum. For portal-read performance, the relevant throughput metric is 'tags read per pallet pass' rather than 'tags per second'. A well-tuned portal reads an 80-case pallet completely in a single pass, which is the operational target that matters.

Gen2 evolution and the protocol roadmap

The EPC Gen2 protocol has evolved since its original 2004 ratification and continues to evolve under GS1 and ISO governance. Understanding the historical evolution and the current direction helps operators anticipate how their deployments will need to adapt over multi-year programmes, and helps suppliers align chip and reader roadmaps with ecosystem direction.

• Gen2 v1.0.9 (2004-2008). The original EPC Gen2 specification from EPCglobal, adopted as ISO/IEC 18000-6C in 2006. Defined the baseline air interface, memory banks and anti-collision mechanics still in use today. The specification was the unification point that ended the earlier fragmentation between ISO 18000-6A and 18000-6B.
• Gen2 v2.0 (2013). Gen2v2 amendment added crypto-suite support, file management, untraceable mode and other optional features. Incorporated into ISO/IEC 18000-63 in its 2013 revision. Most modern chip families support at least a subset of Gen2v2 extensions.
• Gen2 v3.0 (January 2025). Gen2v3 — the first protocol revision in a decade — was published by GS1 in alignment with the RAIN Alliance technical workgroup (chaired by Claude Tetelin, with Josef Preishuber-Pflügl as ISO/IEC 18000-63 Project Editor). Three headline additions: Query X and Query Y selection commands enable advanced filtering by EPC scheme, header value or feature flag (clutter reduction in environments where many unrelated tags are present); modulated-power inventory lets the interrogator briefly reduce field strength so only on-target tags wake (suppressing fringe-tag responses in dense-reader deployments); and the Read-Var command instructs the tag to backscatter exactly the requested User / TID memory subset rather than fixed-width reads. Gen2v3 is fully backward compatible: Gen2v2 tags work on Gen2v3 readers and vice versa; reader vendors add support through firmware updates only. Tag-chip silicon supporting Gen2v3 sampled through 2025; production rollout is 2026-2027.
• ISO/IEC 18000-63:2021 maintenance — the current ISO edition (third edition, 2021, replacing the 2015 second edition) is maintained on a periodic review cycle, with editorial corrections and occasional feature additions. The companion ISO/IEC 18000-63 update aligning to Gen2v3 is in progress through JTC 1/SC 31 of ISO with RAIN Alliance and GS1 technical input.
• Emerging extensions: specific industry working groups have advanced extensions targeting retail anti-counterfeiting, pharmaceutical authentication, automotive parts lifecycle and aerospace parts management. Some extensions standardize through GS1 and ISO; others remain vendor-specific and become de facto standards through market adoption.
• Sensor integration standards: integration of temperature, humidity, tamper and other sensors into Gen2 tags has produced specialized protocol extensions for sensor data reading and battery-assisted-passive operation. Standardization in this area is evolving and varies by chip vendor.
• IoT and cloud integration standards. Beyond the air interface, the broader RAIN ecosystem includes standards for reader-to-middleware communication (LLRP), middleware-to-enterprise event exchange (EPCIS), and cloud-integration APIs (OData, REST). These higher-layer standards are where significant ecosystem evolution happens, even though the air-interface layer stays stable.
• Operator guidance for protocol evolution. Enterprise operators should plan their deployment infrastructure assuming Gen2v2 chip capability is now baseline rather than extended, specify chip and reader selections that support Gen2v2 crypto-suite for applications that may need it later, and stay aware of vertical-specific working-group output that may surface new requirements (for example, the pharmaceutical and automotive working-group outputs have produced vertical-specific features that have propagated to mainstream chip lines).

FAQ