Chapters

5 RFID Standards and Protocols

rfid-nfc-uwb
standards
protocols

5.1 Start With the Story

Choose the Standard at the Boundary That Must Work

Picture a warehouse tag that one reader sees but another cannot decode. Both boxes say they support tags, yet the air link, reader control, and event record may follow different contracts.

Near field communication, or NFC, is a short-range radio method for nearby exchanges. Radio frequency means the rate of a radio wave. Radio frequency identification, or RFID, uses radio to identify a tag. Standards divide that work into layers that must not be confused.

Read one known tag with two approved readers. Record tag family, band, air contract, reader settings, identifier, event fields, filters, time, and result. Swap one reader and reject any event whose meaning changes.

This runway does not make one standards family fit every workflow. The deeper sections separate air interfaces, reader control, identifiers, business events, pilots, and retest evidence.

A working RFID system has several contracts at once. The tag and reader need an air-interface contract, the reader and software need a control contract, and the application needs event data that still means the same thing after filtering.

This chapter separates those contracts so design reviews do not mix them together. Start with the boundary that must interoperate, then choose the standard evidence that proves the right layer is doing the right job.

5.2 In 60 Seconds

RFID standards are easier to use when you keep the layers separate. ISO 14443, ISO 15693, ISO/IEC 18000, EPC Gen2, and NFC Forum specifications describe tag-to-reader behavior. LLRP describes a reader-control interface. EPC, EPCIS, and CBV describe identifiers and business events. Start with the workflow, choose the standard family that fits the read pattern, pilot it with real tags and materials, and record the settings and retest triggers.

The mathematical gist. At 13.56 MHz, wavelength is 22.1 m and the λ/(2π)\lambda/(2\pi) near-field screen is 3.52 m, so 2-10 cm HF reads are magnetic-coupling problems. At 915 MHz, a 0.3 m portal reaches its far-field screen by 0.549 m; a 36 dBm EIRP, 2 dBi tag, and -18 dBm wake threshold give a 16.5 m ideal forward-link ceiling, not a guaranteed read zone.

Math Bridge · guided foundationsWhen does RFID stop behaving like coupled loops and start behaving like radio?Let Eddie connect wavelength, field-region screens, EIRP, tag threshold, and ideal power-up range.

5.3 Learning Objectives

By the end of this chapter, you will be able to:

  • Separate air-interface standards from reader-control protocols and event-data standards.
  • Choose between ISO 14443, ISO 15693, EPC Gen2, NFC Forum, and active RFID families based on workflow evidence.
  • Explain why EPC Gen2 anti-collision needs a tuned inventory round instead of only higher reader power.
  • Describe how EPC identifiers become useful business events through middleware, EPCIS, and common vocabularies.
  • Review a proposed RFID standards choice for interoperability, operations, privacy, and retest risk.

5.4 Quick Check: RFID Standards

5.5 Why Standards Matter

An RFID project usually fails at one of three boundaries:

  • The tag and reader cannot communicate reliably.
  • The reader cannot be managed consistently across sites or vendors.
  • The raw tag reads do not become shared, auditable business events.

Standards reduce those risks, but they do not all solve the same problem. ISO 14443, ISO 15693, ISO/IEC 18000, EPC Gen2, and NFC Forum specifications describe how devices communicate over the air. LLRP describes a network interface for controlling compatible readers. EPC, EPCIS, and the GS1 Core Business Vocabulary describe how identifiers and read events are represented for supply-chain visibility.

Inspect Tag to reader radio behavior and Client software to reader in Figure 5.1 for why standards matter. To place why standards matter on firm evidence, set Tag to reader radio behavior against Client software to reader with it. The conclusion depends on CBV.

RFID standards map air interfaces, NFC behavior, reader control and event sharing to their protocols. Event records add what, where, when and why to identifiers.
Figure 5.1: RFID standards grouped by responsibility: air interface, NFC behavior, reader control, and event sharing

Read Tag to reader radio behavior with Client software to reader in Figure 5.1 for why standards matter. Move through it with Tag to reader radio behavior first, Client software to reader next, and CBV last. That ordering makes CBV depend on Tag to reader radio behavior. The conclusion in why standards matter now has a named boundary.

5.6 Standards By Responsibility

5.7 Air-Interface Standards

Air-interface standards define how the reader and tag communicate: frequency family, modulation, command sequence, timing, and anti-collision behavior.

  • ISO 14443: HF proximity cards and devices at 13.56 MHz. Use it when intentional close-range interaction matters, such as tap access, identity cards, and contactless card workflows.
  • ISO 15693: HF vicinity cards at 13.56 MHz. Use it when the item can be read farther than a tap but still benefits from HF behavior, such as library, document, and item-level asset workflows.
  • ISO/IEC 18000 family: RFID air interfaces across frequency families for item management. The UHF branch is the relevant family for many passive supply-chain and inventory systems.
  • EPC Gen2 / ISO 18000-63: The common UHF passive item-identification air interface used in many supply-chain RFID deployments. Older material may describe this lineage as ISO 18000-6C; current procurement and compliance language should be checked against the exact specification and region.

5.8 NFC Forum Specifications

NFC builds on HF proximity technology and defines predictable behavior for phones, tags, and readers. In practice, NFC decisions often combine two questions:

  • Which RF technology does the tag use, such as NFC-A, NFC-B, NFC-F, or NFC-V?
  • Which data behavior is required, such as NDEF records, reader/writer mode, card emulation, or peer interaction?

Do not treat every 13.56 MHz tag as an NFC tag. A phone-compatible workflow needs both compatible RF behavior and the right NFC data format.

5.9 Reader-Control Protocols

Reader-control protocols sit above the air interface. LLRP is used to control compatible RFID readers from client software. It can standardize inventory operations, reporting, and reader-client communication, but it does not erase every vendor-specific configuration detail.

In a review, ask which layer the team is standardizing:

  • Air interface between tag and reader.
  • Reader control between middleware and reader.
  • Event schema between business systems.
  • Operational process for commissioning, monitoring, and retesting.

5.10 Event-Data Standards

The Electronic Product Code gives physical things a structured identifier. EPCIS and the Core Business Vocabulary help turn observations into shareable events such as what was observed, where it was observed, when it happened, and why it matters to the business process.

This distinction is important. Reading a tag is not the same as proving that a shipment was received, a medicine was dispensed, or an asset changed custody. The event layer needs business context and reviewable evidence.

5.11 EPC Gen2 Dominates UHF Supply-Chain RFID

When people say “RFID” in supply-chain and retail contexts, they often mean EPC Gen2: the EPCglobal UHF Class-1 Generation-2 air interface, standardized internationally as ISO/IEC 18000-63 and operating in the UHF 860-960 MHz band. It defines radio behavior between reader and tag plus the tag data conventions that let a Gen2 reader from one vendor inventory Gen2 tags from another.

The other standards fill in the interaction patterns Gen2 does not cover. ISO/IEC 14443 supports proximity behavior at 13.56 MHz HF, ISO/IEC 15693 supports vicinity behavior at 13.56 MHz HF, and ISO 11784/11785 covers LF animal identification around 125-134 kHz. Picking a standard is really picking a band, range class, interaction pattern, and evidence model together.

The important design habit is to keep the standards family tied to the interaction that must be proven. A medicine cabinet badge tap is not the same problem as a dock-door carton portal. In the cabinet case, the review evidence may say: staff presents a badge within a few centimeters, the cabinet logs one deliberate access event, and a missed read sends the nurse to a manual identity check. That points toward ISO 14443 or NFC-style proximity behavior because short range is part of the control.

In the dock-door case, the evidence may say: a pallet spends 1.6 seconds in a 2.4 m read zone, cartons can be stacked, and the system must identify many passive labels without line of sight. That points toward EPC Gen2 UHF because bulk inventory and anti-collision are the central mechanisms. If a pilot reads 47 of 50 tagged cartons on dry cardboard but only 39 of 50 when foil packaging is added, the standards decision is not “Gen2 failed.” It is that Gen2 remains only a candidate until tag placement, antenna geometry, shielding, or exception handling closes the evidence gap.

Standards make interoperability possible; they do not remove the need to test the actual workflow. A reviewable standards packet records the object class, range expectation, material exposure, tag family, reader-control method, event-data owner, privacy exposure, and retest trigger.

5.12 Choosing A Standards Family

Start with the workflow, not with the technology name.

Inspect Intentional tap and Evidence: intent and fallback in Figure 5.2 for choosing a standards family. To make choosing a standards family reviewable, compare Intentional tap with Evidence: intent and fallback in it. Use Vicinity item as the boundary.

Four selection lanes compare intentional tap workflows, HF vicinity workflows, UHF bulk portal workflows, and active asset workflows. Each lane lists the likely standards family, the evidence to pilot, and the main review risk.
Figure 5.2: RFID standard selection lanes for tap, vicinity, bulk portal, and active asset workflows

Read Intentional tap with Evidence: intent and fallback in Figure 5.2 for choosing a standards family. Apply its criteria around the contrast between Intentional tap and Evidence: intent and fallback, then check Vicinity item. Vicinity item turns categories into a decision. This supplies choosing a standards family with a concrete retest point.

Use this sequence during design review:

  1. State the object being identified: person token, consumable, case, pallet, reusable asset, tool, document, animal, vehicle, or container.
  2. State the interaction pattern: deliberate tap, short vicinity read, portal pass, handheld inventory sweep, gate crossing, or periodic active beacon.
  3. Check the environment: metal, liquids, body proximity, stacked items, speed through the read zone, neighboring readers, privacy exposure, and expected exceptions.
  4. Select the candidate standards family.
  5. Pilot with representative tags, readers, mounting positions, and process events.
  6. Record the standard, regional settings, reader-control method, data schema, and retest trigger.

5.13 Common Selection Patterns

  • Use ISO 14443 and NFC Forum behavior when the user must intentionally present a card, phone, or tag at close range.
  • Use ISO 15693 or NFC-V behavior when HF vicinity reads are useful and phone or specialized-reader support is part of the workflow.
  • Use EPC Gen2 UHF when many passive items must be identified without line of sight and the environment supports reliable UHF reads.
  • Use active RFID or RTLS-specific systems when the asset must announce itself over a larger area or when battery-powered location behavior is required.

5.14 Folded Standards Selection Record

  1. Radio Remi pairs a representative tagged object with a workflow event and a proof question.

    Start with the object, event, and what a read must prove.

  2. Remi links distinct air-interface, tag, reader-control, and backend event-record blocks, each with its own owner marker.

    Link the air path, tag, reader, and event record without merging their jobs.

  3. Remi pilots representative moving and mounted objects, recording successful, false, duplicate, and missed reads plus a retest trigger.

    Pilot real objects and save false reads, missed reads, and the retest rule.

Choose an identification standard by linking the object and workflow to the air interface, tag and reader, event data, and representative pilot evidence.

A standards decision should link the air interface to the workflow, data model, and pilot evidence:

Review fieldWhat to write down
Object and eventPerson token, animal, document, tool, case, pallet, vehicle, or container, plus what a read should prove.
Frequency and couplingLF/HF inductive coupling, UHF radiative backscatter, active beaconing, or NFC tap behavior.
Standards familyISO 11784/11785, ISO/IEC 14443, ISO/IEC 15693, ISO/IEC 18000 family, EPC Gen2, NFC Forum, or event-data standards such as EPCIS.
Reader and tag constructionReader placement, antenna geometry, tag package, on-metal behavior, durability, and regional settings.
Backend event handlingDuplicate filtering, missed-read exceptions, wrong-read handling, event schema, and business-system ownership.
Pilot evidenceRepresentative objects, mounting, motion path, read rate, false reads, duplicate reads, and retest trigger.

Do not collapse all of this into “RFID standard selected.” The radio standard, reader-control protocol, and event-data standard solve different problems and usually have different owners.

5.15 EPC Gen2 Anti-Collision

Bulk UHF RFID works because the reader manages an inventory round. When many passive tags are energized at the same time, they cannot all answer at once. EPC Gen2 uses a slotted process where the reader announces a Q value, tags choose slots, and collided tags retry in later rounds.

Inspect Announces Q and T1 in Figure 5.3 for epc gen2 anti-collision. To test epc gen2 anti-collision, keep both Announces Q and T1 visible in it. T7 supplies the consequence.

A reader announces a Q value that creates time slots. Tags choose random slots. Some slots are empty, some have one successful tag response, and some collide. Collided tags retry in a later adjusted inventory round.
Figure 5.3: EPC Gen2 inventory round showing reader Q value, tag slot choice, successful slots, empty slots, and collision retry

Read Announces Q with T1 in Figure 5.3 for epc gen2 anti-collision. Review its branches around the contrast between Announces Q and T1, then check T7. T7 turns categories into a decision. For epc gen2 anti-collision, record the result beside T7.

The practical review question is not “what is the maximum read rate?” It is:

  • How many tags are expected in the field at the same time?
  • How long does the object stay inside the useful read zone?
  • How many antennas are switching during the inventory cycle?
  • How much tag orientation and material variation exists?
  • Does the reader adjust Q automatically, or is a fixed setting being forced?
  • What read evidence proves the process works on the real package mix?

5.16 Q Value As A Planning Heuristic

The slot count is 2^Q. A useful starting estimate is:

Qlog2(expected tags in the field)Q \approx \lceil \log_2(\text{expected tags in the field}) \rceil

That estimate is only a starting point. A larger Q reduces collisions but lengthens a round. A smaller Q shortens a round but increases collisions. The best setting depends on dwell time, tag count, antenna sequence, reader firmware, and the materials in the read zone.

Use these review statements instead of brittle promises:

  • “The reader configuration was piloted with the real tag population and dwell time.”
  • “The system records missed-read exceptions and retests after package, antenna, or reader changes.”
  • “Dense reader behavior was reviewed when neighboring readers could interfere.”
  • “The event layer does not assume that a single read is proof of business custody.”

5.17 The Select, Query, And ACK Handshake

A Gen2 reader does not just scan. It runs a defined command sequence to single out one tag at a time from a crowd:

  1. Select narrows the population to tags matching a filter, such as a company prefix, so the reader does not inventory the whole warehouse.
  2. Query opens an inventory round and sets a slot count from the parameter Q; each tag picks a random slot in 0..2^Q-1.
  3. When a tag’s slot counter reaches zero, it backscatters a 16-bit random number called RN16.
  4. The reader echoes that RN16 in an ACK; only the tag that sent it replies with its PC bits and EPC. Echoing the RN16 is how the reader proves it is talking to that one tag.
  5. For reading or writing memory, Req_RN returns a handle used by the Read, Write, Lock, and Kill access commands.

This is the anti-collision mechanism: random slotting plus the RN16 handshake lets many tags share the channel and be read one by one. Getting Q close to the population size is what separates a fast inventory from a stalled one.

Use the Q value as a planning estimate before the pilot. If a dock-door reader expects about 48 tags in the field, ceil(log2(48)) = 6, so Q = 6 gives 2^6 = 64 slots. That is a plausible starting point because it gives the population room to spread out. If the reader starts at Q = 4, there are only 2^4 = 16 slots, so many of the 48 tags will choose the same slots and collide. If it starts at Q = 9, there are 512 slots, so the round can waste time stepping through mostly empty slots. Both extremes can lose reads when the pallet is moving.

Now add dwell time. A pallet moving through a 2.4 m useful read zone at 1.2 m/s is available for 2.4 / 1.2 = 2.0 seconds. If the reader cycles four antennas evenly, each antenna has roughly 2.0 / 4 = 0.5 seconds of dwell time before the package geometry changes. That does not produce a universal maximum tag count because real timing depends on modulation settings, tag sensitivity, reader firmware, collisions, retries, and materials. It does give the design review a concrete question: did the pilot prove that the selected Q behavior, antenna sequence, and filter rules complete enough inventory rounds inside the actual dwell time?

5.18 From Identifier To Business Event

A standards-compliant read is still just an observation. The system becomes useful when the observation is filtered, associated with business context, and shared in a form that other systems can interpret.

Inspect EPC or UID and custody in Figure 5.4 for from identifier to business event. While tracing from identifier to business event, set EPC or UID against custody with it. Use Event data as the boundary.

RFID data path begins with a tag identifier read over the air interface, passes through a reader controlled by middleware, becomes a filtered observation, is written as an EPCIS style event with vocabulary, and is consumed by inventory, custody, or traceability applications.
Figure 5.4: RFID data path from tag identifier to reader, middleware filtering, EPCIS event, and business application

Read EPC or UID with custody in Figure 5.4 for from identifier to business event. Move through it from EPC or UID through custody to Event data. A failure at custody changes the route from EPC or UID. Reopen from identifier to business event whenever custody changes.

Review each layer separately:

  • Tag memory and identifier: Is the identifier encoded consistently? Who owns the numbering scheme? How are duplicates prevented?
  • Air-interface behavior: Which standard family is used? Which regional settings, channels, power constraints, and tag classes apply?
  • Reader control: How are readers configured, monitored, and updated? Which settings are standardized and which remain vendor-specific?
  • Read filtering: How are duplicate reads, ghost reads, missed reads, and antenna zones handled?
  • Event representation: What business step, location, disposition, and timestamp are recorded?
  • Sharing boundary: Which partners or systems can query events, and what privacy or access rules apply?

5.19 Gen2 Memory Banks Are Separate Evidence Fields

Reading a Gen2 tag well means knowing where its data lives. The standard defines four memory banks that are addressed independently:

BankNameContents
00Reserved32-bit kill password and 32-bit access password.
01EPCCRC-16, Protocol-Control bits, and the EPC identifier itself.
10TIDTag identifier: chip maker and model; many tags add a permanent unique serial.
11UserOptional application data, not present on the cheapest tags.

Inspect primary identifier and TID: when is chip identity useful evidence? in Figure 5.5 for gen2 memory banks are separate evidence fields. To place gen2 memory banks are separate evidence fields on firm evidence, follow the change from primary identifier to TID: when is chip identity useful evidence? on it. Privacy: what can outsiders read? limits the claim.

Gen2 RFID tag memory-bank map showing Reserved for kill and access controls, EPC as the primary writable identifier, TID as chip identity evidence, and User memory as optional tag-resident data, with review prompts for access control, identifier trust, helper evidence, and payload necessity.
Figure 5.5: Gen2 tag memory banks showing reserved controls, EPC, TID, and user memory

Read primary identifier with TID: when is chip identity useful evidence? in Figure 5.5 for gen2 memory banks are separate evidence fields. Work through it with primary identifier as one fact, TID: when is chip identity useful evidence? as another, and Privacy: what can outsiders read? as the closeout. Both primary identifier and TID: when is chip identity useful evidence? need evidence. Carry primary identifier into the evidence for gen2 memory banks are separate evidence fields.

Two practical consequences follow. First, the EPC in Bank 01 is writable and clonable, so anti-counterfeiting work should read the factory-locked unique serial in the TID bank beside the EPC. Second, the passwords in Bank 00 are only 32 bits and are sent with light cover-coding, so classic Gen2 security is weak by design. The security chapter builds on that point.

Use memory banks to write acceptance tests, not just documentation. Suppose a reusable tool is issued with a 96-bit EPC. That is 96 / 8 = 12 bytes of identifier payload, but the reader report will usually include more than those 12 bytes because the EPC bank also carries protocol-control information and a CRC. The business system should parse the EPC payload according to the encoding scheme the organization actually owns, then store the reader, antenna, timestamp, and event reason beside the observation.

A stronger commissioning test reads both EPC and TID. The record might say: expected EPC prefix matched, TID manufacturer and model matched the approved inlay, 48 of 48 pilot labels produced the same EPC/TID pair across three inventory passes, and 0 duplicate EPCs appeared with different TIDs. That catches a common weak design: accepting only the writable EPC as truth. If an operator finds two tags that both report the same EPC but different factory-locked TIDs, the event layer should flag a clone or encoding error rather than silently merging the observations.

5.20 Check TID Versus EPC Evidence

5.21 Matching Standards To Roles

5.22 Worked Review: Receiving Doorway

A manufacturer wants to scan incoming cartons as pallets pass through a dock doorway. Each pallet may contain a mixed number of tagged cartons, and neighboring dock doors may have their own readers.

5.23 Candidate Choice

EPC Gen2 UHF is a reasonable candidate because the workflow needs passive, non-line-of-sight, bulk identification. The review should not stop there.

5.24 Evidence To Collect

  • Use ISO 14443 and NFC Forum behavior when the user must intentionally present a card, phone, or tag at close range.
  • Use ISO 15693 or NFC-V behavior when HF vicinity reads are useful and phone or specialized-reader support is part of the workflow.
  • Use EPC Gen2 UHF when many passive items must be identified without line of sight and the environment supports reliable UHF reads.
  • Use active RFID or RTLS-specific systems when the asset must announce itself over a larger area or when battery-powered location behavior is required.

5.25 Acceptance Record

A defensible record should include:

  • Candidate standards and exact product conformance claims from vendors.
  • Regional RF settings and deployment constraints.
  • Pilot evidence with representative cartons and pallet speeds.
  • Missed-read handling and manual exception path.
  • Retest trigger after tag, packaging, reader firmware, antenna layout, or process changes.

5.26 Common Mistakes

5.27 Treating Frequency As The Standard

“13.56 MHz” and “UHF” are not enough. The review needs the actual standard family, tag behavior, data format, and reader-control assumptions.

5.28 Using One Standard For Every Workflow

A hospital, warehouse, or campus can legitimately use several RFID families. Force-fitting every workflow into one standard often creates either privacy risk, missed reads, or poor user intent.

5.29 Confusing Tag Reads With Business Events

An antenna read does not automatically mean receiving, shipping, dispensing, or custody transfer. EPCIS-style events require context and business vocabulary.

5.30 Assuming LLRP Removes All Vendor Differences

LLRP can standardize an important reader-control interface, but antenna mapping, diagnostic data, firmware features, and device management may still differ.

5.31 Ignoring Retest Triggers

Standards conformance is not a one-time proof. Packaging, mounting, regional settings, reader firmware, tag supplier, neighboring readers, and workflow speed can all require retesting.

5.32 Review Checklist

Before approving an RFID standards choice, confirm that the team can answer these questions:

  • Which workflow is being supported, and what evidence shows the read pattern is correct?
  • Which standards layer is being selected: air interface, NFC behavior, reader control, identifier syntax, or event sharing?
  • Which exact tag class, memory behavior, and regional radio settings apply?
  • How are multiple tags, collisions, missed reads, and duplicate reads handled?
  • What event data is produced, and which business meaning does it carry?
  • How will privacy, access control, and partner sharing be governed?
  • What changes require the pilot evidence to be repeated?

5.33 Reference Notes

Use official standards bodies and current vendor conformance statements when writing procurement language:

  • GS1 EPC/RFID standards for EPC, EPC Gen2 lineage, and related supply-chain RFID guidance.
  • GS1 EPCIS and CBV standards for event-sharing and vocabulary guidance.
  • GS1 LLRP material for reader-client interface guidance.
  • NFC Forum specifications for NFC device and tag behavior.
  • ISO/IEC 18000-6 overview material for UHF RFID item-management air-interface context.

5.34 Summary

RFID standards are most useful when they are assigned to the right layer. ISO 14443, ISO 15693, ISO/IEC 18000, EPC Gen2, and NFC Forum specifications shape tag-to-reader behavior. LLRP helps control compatible readers. EPC, EPCIS, and CBV help transform observations into shared business events. Good design review starts with the workflow, chooses the candidate standards family, pilots the real environment, and records the retest triggers.

5.35 Key Takeaway

RFID standards choices should document the air interface, data model, reader integration, certification need, and interoperability boundary.

5.36 Concept Relationships

  • Frequency-band knowledge explains why LF, HF, UHF, and active systems behave differently.
  • Tag-type knowledge explains why passive, battery-assisted, and active tags fit different workflows.
  • RFID security knowledge explains why range, identity, and event sharing create privacy and misuse risks.
  • Deployment knowledge explains how antenna placement, reader scheduling, and exception handling affect the final outcome.

5.37 What’s Next

5.38 Sequence Review