14 NFC Protocols: Handover Boundaries

rfid-nfc-uwb

modes

protocols

14.1 Start With the Decision

An NFC tap only works when the reader and the tag agree on a mode and then hand over cleanly to the protocol that carries the data. This part follows that handover: where the boundary sits, how polling and anti-collision activate one tag among several, and the activation mistakes that make a tap fail in the field.

14.2 Route Overview

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

14.3 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

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

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.

Inspect NFC tap and NDEF in Figure 14.1 for handover boundary. At the decision point in handover boundary, separate NFC tap from NDEF using it. The figure ties this to not NFC.

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

Read NFC tap with NDEF in Figure 14.1 for handover boundary. Read it with NFC tap as one fact, NDEF as another, and not NFC as the closeout. Keep not NFC separately reviewable. Attach the next action in handover boundary to not NFC.

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

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.

Inspect cycle modes and one target in Figure 14.2 for polling, anti-collision, and activation. To challenge the claim in polling, anti-collision, and activation, separate cycle modes from one target using it. The route closes at malformed, denied.

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

Read cycle modes with one target in Figure 14.2 for polling, anti-collision, and activation. Work across it from cycle modes through one target to malformed, denied. That ordering makes malformed, denied depend on cycle modes. Use that distinction when deciding polling, anti-collision, and activation.

The activation sequence is reader-driven:

Poll: The reader cycles through supported technologies such as NFC-A, NFC-B, NFC-F, or NFC-V.
Detect response: A compatible target answers with enough information to continue selection.
Resolve collisions: If more than one target responds, the reader selects one target at a time.
Activate protocol: The reader moves into the protocol needed for tag memory, ISO-DEP, or peer exchange.
Exchange data: Only after activation does the application see NDEF records, APDU responses, or peer payloads.
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

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:

No target reported: inspect field coupling, antenna orientation, tag technology support, shielding, mounting surface, and polling configuration.
Target reported but no NDEF or APDU response: inspect activation, tag type mapping, memory access, ISO-DEP application selection, and record format.
Payload parsed but action denied: inspect application policy, technician session, object state, authorization, and fallback.
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

14.9 Tag Types, Technologies, and NDEF

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

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

Technology	Based on	Notes
NFC-A	ISO/IEC 14443 Type A	Common MIFARE and NTAG family; 106 kbps base rate with modified Miller/OOK signaling.
NFC-B	ISO/IEC 14443 Type B	Used by many ID and banking-card systems; NRZ/BPSK signaling.
NFC-F	JIS X 6319-4, FeliCa	212/424 kbps; common in Japanese transit and payment deployments.
NFC-V	ISO/IEC 15693	Vicinity-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

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

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

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

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

Inspect Compatibility and Policy outcome in Figure 14.3 for release evidence. While tracing release evidence, keep both Compatibility and Policy outcome visible in it. Release only when failures are classified by boundary: identifies the later check.

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

Read Compatibility with Policy outcome in Figure 14.3 for release evidence. Work through it from the Compatibility field to Policy outcome, then the Release only when failures are classified by boundary: disposition. Keep Release only when failures are classified by boundary: separately reviewable. For release evidence, record the result beside Release only when failures are classified by boundary:.

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

14.16 Match Modes to Responsibilities

14.17 Order the NFC Reader/Writer Flow

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

Use this short checklist before approving an NFC mode decision:

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

14.19 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

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

Builds On:

RFID Fundamentals - HF RFID, tag selection, reader timing, and standards context.
NFC Fundamentals - NFC range, tap intent, and basic active/passive behavior.

Enables:

NFC Tags and NDEF - Tag family, capacity, record structure, and write-state decisions build on mode choice.
NFC Communication and IoT Integration - Tap payloads need application policy, controller behavior, and follow-on carrier evidence.
NFC Security and Comparisons - Threat models and controls depend on the operating mode and trust boundary.

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

Standards and Specifications:

NFC Forum Specifications - NDEF, tag operation, LLCP, and handover specifications.
ISO/IEC 14443 - Proximity card communication used by many NFC systems.
ISO/IEC 18092 - NFC Interface and Protocol specification.

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

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 final part closes the route from Handover Boundary through What’s Next. Return to NFC Protocols: Mode Foundations or continue from the rfid-nfc-uwb module index.