Chapters

14 NFC Protocols: Handover Boundaries

rfid-nfc-uwb
modes
protocols

14.1 Start With the Decision

This section: Start With the Decision — An NFC tap is a short-range radio exchange.

An NFC tap is a short-range radio exchange. The reader starts that exchange and a tag responds. A mode sets their roles; handover uses the tap to set up another link that carries data. Polling looks for a target, and anti-collision helps the reader select one tag when several respond. This part follows the handover boundary and the activation mistakes that make a tap fail in the field.

14.2 Route Overview

This section: Route Overview — This is part 2 of 2.

This is part 2 of 2. Review NFC Protocols: Mode Foundations for the preceding evidence.

14.3 Learning Objectives

This section: Learning Objectives

  • Test handover boundary with a concrete scenario and pass criteria.
  • Validate design review checklist with a concrete scenario and pass criteria.

14.4 Chapter Roadmap

This section: Chapter Roadmap

  • Handover Boundary
  • Polling, Anti-Collision, and Activation
  • Common Activation Mistakes
  • Initiator, Target, and Passive Communication
  • Quick Check: NFC Role
  • Tag Types, Technologies, and NDEF
  • Technology Matrix and Compatibility Evidence
  • Reader/Writer Tag Choices
  • NDEF Message Structure
  • NDEF Design Rule
  • Trust Boundaries
  • Release Evidence
  • Knowledge Check
  • Match Modes to Responsibilities
  • Order the NFC Reader/Writer Flow
  • Common Pitfalls
  • Assuming Every NFC Device Supports Every Mode
  • Confusing NDEF With Authorization
  • Skipping Write Verification
  • Letting Handover Hide the Real Failure
  • Design Review Checklist
  • Summary
  • Key Takeaway
  • Concept Relationships
  • See Also
  • What’s Next

14.5 Handover Boundary

This section: Handover Boundary — Handover is a boundary pattern, not a promise that NFC will carry the whole session.

Handover is a boundary pattern, not a promise that NFC will carry the whole session. NFC carries enough information to identify the peer, select a carrier, or pass a setup token. The other bearer owns discovery completion, encryption, reconnect behavior, and bulk data exchange.

Figure 14.1 shows where an NFC tap hands setup to another carrier.

NFC handover diagram showing a short NDEF setup exchange crossing into application policy, followed by Bluetooth, Wi-Fi, Thread, or backend connection handling outside the NFC link.
Figure 14.1: NFC handover boundary between tap setup and follow-on connection

The tap selects a target and carries a small setup record. The app then validates the token or record and confirms the intended peer under its policy. That is the end of the NFC evidence: Bluetooth, Wi-Fi, Thread, or a backend must establish the later session. Record whether that carrier connected, was denied, timed out, or retried, and keep the result separate from the tap log. A successful NDEF exchange does not prove that the follow-on link is secure or usable. The boundary makes failures assignable to the tap, app check, or carrier setup.

For IoT products, this distinction matters during review:

NFC owns Tap intent, close-range target choice, small setup records, and visible fallback when the tap cannot be parsed.
The carrier owns Pairing completion, session protection, reconnect behavior, throughput, range, and long-running data exchange.
The application owns Authorization, device binding, user confirmation, telemetry, retry rules, and rollback when setup fails.

14.6 Polling, Anti-Collision, and Activation

This section: Polling, Anti-Collision, and Activation — Before an NDEF record, APDU, or peer message can be exchanged, the reader must find and activate a target.

Before an NDEF record, APDU, or peer message can be exchanged, the reader must find and activate a target. Keep this level of detail in design reviews; diving into every modulation bit is usually unnecessary unless you are building reader firmware.

Figure 14.2 divides a tap into polling, selection, activation, and exchange states.

Sequence from idle polling through target response, anti-collision, selection, protocol activation, data exchange, and release evidence capture.
Figure 14.2: NFC polling and activation flow before application data exchange

The activation loop in Figure 14.2 begins with reader polling across NFC modes. Detection is followed by anti-collision so the reader selects one target before protocol activation and application data exchange. Release returns it to polling and saves the stage, input, decision, and reason. The failure examples distinguish a malformed TLV, which the parser rejects, from an unknown URI host, which policy rejects. A successful Type 2 read of a setup URI only establishes that data arrived. The app still needs an authenticated session and backend work-order approval before taking a service action, so log where a failed tap stopped.

The activation sequence is reader-driven:

  1. Poll: The reader cycles through supported technologies such as NFC-A, NFC-B, NFC-F, or NFC-V.
  2. Detect response: A compatible target answers with enough information to continue selection.
  3. Resolve collisions: If more than one target responds, the reader selects one target at a time.
  4. Activate protocol: The reader moves into the protocol needed for tag memory, ISO-DEP, or peer exchange.
  5. Exchange data: Only after activation does the application see NDEF records, APDU responses, or peer payloads.
  6. Release or retry: The system records success, timeout, unsupported tag, malformed payload, or user-cancel evidence.
Common Activation Mistakes
  • Assuming the closest tag is always the selected tag when multiple targets are inside the field.
  • Writing application logic that cannot distinguish “no tag,” “unsupported tag,” “activation failed,” and “payload rejected.”
  • Treating a UID or serial-like value as a durable identity without a clone-resistance design and an application-side validation step.

14.7 Initiator, Target, and Passive Communication

This section: Initiator, Target, and Passive Communication — Every NFC exchange has an initiator that starts and drives the exchange and a target that responds.

Every NFC exchange has an initiator that starts and drives the exchange and a target that responds. In passive communication mode, only the initiator generates the 13.56 MHz field; the target replies by load modulation, varying how much energy it draws from the initiator field. This is the same operating idea that lets an unpowered HF RFID tag answer a reader.

This distinction explains several field failures. A phone can read an unpowered sticker because the phone is the initiator generating the field and the passive tag load-modulates a reply. At a cabinet reader or payment terminal, the fixed reader creates the field and sends commands; the phone acts as the card-emulation target and answers only through an allowed card application. Having a battery does not mean the phone owns the field.

Diagnose NFC failures from the bottom upward:

  1. No target reported: inspect field coupling, antenna orientation, tag technology support, shielding, mounting surface, and polling configuration.
  2. Target reported but no NDEF or APDU response: inspect activation, tag type mapping, memory access, ISO-DEP application selection, and record format.
  3. Payload parsed but action denied: inspect application policy, technician session, object state, authorization, and fallback.
  4. Handover tap succeeds but setup fails later: inspect peer identity, carrier pairing, session protection, timeout behavior, and rollback.

For card emulation, release evidence should record which application was selected, what happens when the reader asks for an unsupported application, whether user presence is required, and what audit event is emitted for declined or ambiguous taps. A successful “phone seen by reader” test can still hide a credential-policy failure.

14.8 Quick Check: NFC Role

This section: Quick Check: NFC Role

14.9 Tag Types, Technologies, and NDEF

This section: Tag Types, Technologies, and NDEF — Tag type, RF technology, and NDEF record type are different decisions.

Tag type, RF technology, and NDEF record type are different decisions. They often get collapsed into one phrase, which leads to weak reviews.

Tag technology The low-level family exposed during polling and activation, such as NFC-A, NFC-B, NFC-F, or NFC-V.
NFC Forum tag type The mapping that defines how an NDEF message is stored or accessed on a supported tag.
NDEF record type The application envelope inside the message, such as URI, text, MIME, smart poster, or handover.
Application meaning The product-specific decision made after parsing and validating the payload.

14.10 Technology Matrix and Compatibility Evidence

This section: Technology Matrix and Compatibility Evidence — Beneath the modes are RF technologies inherited from HF RFID smart cards.

Beneath the modes are RF technologies inherited from HF RFID smart cards. A tap works only when both sides share a supported technology.

TechnologyBased onNotes
NFC-AISO/IEC 14443 Type ACommon MIFARE and NTAG family; 106 kbps base rate with modified Miller/OOK signaling.
NFC-BISO/IEC 14443 Type BUsed by many ID and banking-card systems; NRZ/BPSK signaling.
NFC-FJIS X 6319-4, FeliCa212/424 kbps; common in Japanese transit and payment deployments.
NFC-VISO/IEC 15693Vicinity-card family; longer practical coupling distance at lower data rate.

Turn this matrix into release evidence. A field-service app might support low-cost Type 2 labels for equipment lookup, a phone wallet credential for cabinet access, and an NFC handover tag for a Bluetooth sensor. Those are not one test. The label path needs reader/writer tests with the actual tag family, record size, lock state, and mounting surface. The cabinet path needs card-emulation tests against the installed readers and accepted application identifiers. The sensor setup path needs a handover test that proves the NFC record leads to the intended Bluetooth device, not merely that the tag can be read.

Write each result as a small compatibility record: mode=reader/writer, technology=NFC-A, tag_type=Type 2, payload=URI, max_length_checked=true, write_locked=true, fallback=manual asset search. For card emulation, record the reader model or class, selected application, declined-reader behavior, and audit event. For handover, record the carrier chosen, device identity check, timeout behavior, and rollback if the follow-on link fails.

14.11 Reader/Writer Tag Choices

This section: Reader/Writer Tag Choices

Choose tags from the evidence your workflow needs:

  • Simple public pointer: A URI or short text record can use a small widely supported tag. Locking after write may be appropriate when the content should not change in the field.
  • Field-updated asset state: Prefer a tag and workflow that can verify write success, preserve a previous known-good value, and recover from interrupted writes.
  • Structured device commissioning: Store a compact identifier or setup token, then let the application fetch policy from a trusted service or local controller.
  • Access or entitlement decision: Do not rely on tag memory alone. Use an explicit credential model, challenge-response design, or backend check as required by the system.

14.12 NDEF Message Structure

This section: NDEF Message Structure — NDEF is a message format.

NDEF is a message format. It is not encryption, not anti-collision, and not proof that the tap should be trusted. A message contains one or more records. Each record identifies its type and carries a payload.

Common record patterns include:

URI record
  Purpose: open or route to a resource
  Review point: validate scheme, host, and expected path

Text record
  Purpose: carry a short human-readable value
  Review point: handle language, length, and unexpected characters

MIME record
  Purpose: carry application-specific structured data
  Review point: parse with a strict schema and reject unknown fields

Handover record
  Purpose: carry setup data for another bearer
  Review point: confirm the follow-on connection before changing state
NDEF Design Rule

Put the smallest useful claim on the tag. The tag can identify an object or propose an action; the application should verify whether that action is allowed in the deployment context.

14.13 Trust Boundaries

This section: Trust Boundaries — The tap is intentional, but the data is still external input.

The tap is intentional, but the data is still external input. Treat reader/writer, card emulation, and handover flows as separate trust-boundary reviews.

Reader/writer Validate record type, length, encoding, allowed URI schemes, tag write state, and expected object binding before changing IoT state.
Card emulation Limit which reader applications are answered, define user presence rules where applicable, and log declined or ambiguous reader requests.
Peer-to-peer Verify both devices expose the required P2P capability and decide whether peer data is informational, binding, or command-authorized.
Handover Bind the NFC setup token to the follow-on carrier session. A successful tap is not enough evidence that the later connection is the intended one.

14.14 Release Evidence

This section: Release Evidence — NFC failures often appear as “the tap did not work.” Good release evidence makes those failures diagnosable before field rollout.

NFC failures often appear as “the tap did not work.” Good release evidence makes those failures diagnosable before field rollout.

Figure 14.3 combines reader compatibility, protocol traces, and policy outcomes.

NFC release evidence covers compatibility, protocol behavior, policy outcomes and operations. Release requires failures classified by activation, parsing, policy, carrier or operational boundary.
Figure 14.3: Release evidence for NFC modes and protocol reviews

Compatibility names the device and reader matrix, supported tag types, and the final mount or phone-case conditions. Protocol evidence records polling, activation, NDEF parsing, and write read-back rather than a single pass flag. Policy evidence includes both an allowed and rejected action and the fallback route. These records need to describe the same release setup: changing a tag family, reader firmware, or mounting surface can invalidate an earlier result. A tap that worked once is only one observation; the matrix and negative cases show what can be promised to users.

Capture evidence in four areas:

Compatibility Target device matrix, supported tag technologies, reader firmware version, phone operating system range, and case or mounting conditions.
Protocol behavior Polling result, activation success or failure, selected technology, NDEF parse result, write verification, and retry outcome.
Policy outcome Allowed action, rejected action, user confirmation, fallback path, and whether the IoT state changed.
Operations Telemetry fields, support diagnostics, tag replacement process, lost or damaged tag handling, and regression tests for known failures.

14.15 Knowledge Check

This section: Knowledge Check

14.16 Match Modes to Responsibilities

This section: Match Modes to Responsibilities

14.17 Order the NFC Reader/Writer Flow

This section: Order the NFC Reader/Writer Flow

Common Pitfalls

This section: Common Pitfalls

Assuming Every NFC Device Supports Every Mode

Some devices expose reader/writer mode but not general-purpose peer-to-peer services. Some readers only activate specific tag technologies. Verify the mode and technology matrix for the deployment, then document fallback behavior.

Confusing NDEF With Authorization

An NDEF URI, text record, or MIME payload can be well formed and still be wrong for the target device, user, location, or workflow. Parse first, validate second, act third.

Skipping Write Verification

For writable tags, a successful write command is not enough release evidence. Read the tag back, parse the resulting NDEF message, and record what the application will do if the write is interrupted.

Letting Handover Hide the Real Failure

If an NFC-assisted setup fails after the tap, separate NFC parse failures from carrier connection failures and application authorization failures. The support path needs to know which boundary failed.

14.18 Design Review Checklist

This section: Design Review Checklist

Use this short checklist before approving an NFC mode decision:

  1. Mode: Name reader/writer, card emulation, peer-to-peer, or handover. Identify the field generator and command initiator.
  2. Target technology: List supported tag technologies or card protocols, plus unsupported cases that users may encounter.
  3. Payload: Define the NDEF records, schemas, maximum accepted length, and rejection behavior.
  4. Trust boundary: State which component validates the tap and which component is allowed to change IoT state.
  5. Fallback: Provide a visible path for no tag, unsupported tag, malformed payload, denied action, and follow-on carrier failure.
  6. Evidence: Attach device coverage, activation logs, parse results, write verification, telemetry fields, and field-test notes.

14.19 Summary

This section: Summary

This chapter covered NFC modes and protocols as a layered design problem:

  • Reader/writer mode is for passive tags and reader-driven tag memory access.
  • Card emulation mode is for devices that answer external readers as contactless card applications.
  • Peer-to-peer and handover must be treated as explicit capabilities, with NFC usually carrying only small setup data in modern IoT workflows.
  • NDEF is a portable message format, not a trust decision.
  • Activation evidence explains whether the system failed to find a target, activate a protocol, parse a payload, or authorize an action.
  • Release evidence should cover compatibility, protocol behavior, policy outcome, fallback, telemetry, and operations.

14.20 Key Takeaway

This section: Key Takeaway — NFC mode selection should match the interaction: reader-writer, peer-to-peer, and card-emulation patterns create different security, data, and user-flow obligations.

NFC mode selection should match the interaction: reader-writer, peer-to-peer, and card-emulation patterns create different security, data, and user-flow obligations.

14.21 Concept Relationships

This section: Concept Relationships

Builds On:

Enables:

Related Concepts:

  • Bluetooth, Wi-Fi, and Thread commissioning often use NFC as a setup input rather than as the long-running connection.
  • NDEF records should be schema-checked before they drive IoT actions.
  • Tag type choice should be documented with compatibility and release evidence, not only with memory size.

14.22 See Also

This section: See Also

Standards and Specifications:

Practice:

  • Read a known NFC tag with a phone reader app and identify the record type, payload length, and tag technology.
  • Write a test tag with a short URI record, read it back, and document the parse result and fallback if the record is malformed.
  • For a handover design, write down exactly what NFC carries and what the follow-on bearer must prove before the application acts.

14.23 What’s Next

This section: What’s Next

NFC Tags and NDEF Choose tag families, NDEF records, write states, and capacity checks from the mode decision.
NFC Communication and IoT Integration Connect tap payloads to controllers, gateways, policy services, and follow-on carrier sessions.
NFC Security and Comparisons Review threats, controls, and validation patterns for NFC deployments.
NFC Apps Simulation Lab Practice tag programming, reader testing, write verification, and release evidence.

14.24 Continue Your Route

This section: Continue Your Route — This is the last part of this chapter.

This is the last part of this chapter. Return to NFC Protocols: Mode Foundations or continue from the RFID, NFC and UWB Module Guide.

Find help

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed