RFID, NFC & UWB · Study deck

NFC IoT System Integration

Picture a nurse tapping a medicine cabinet with a phone.

Radio Remi is your guide for this deck.

commintegration

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Design an NFC-to-IoT integration boundary that separates tag data from authorization.
Define a compact event contract for tap events, gateway reads, application links, and controller actions.
Choose where policy should live across mobile apps, local gateways, controllers, brokers, and backend services.
Plan lab validation for offline operation, duplicate taps, replay risk, fallback, privacy, and audit records.

Major section

Start With the Story

The tap can identify the cabinet and start a request, but it should not decide by itself that the door may open.

The system must connect the person, cabinet, intended action, current conditions, and final result.
Near Field Communication (NFC) is a short-range link used during a deliberate close tap.
A gateway is a device that passes a local event into another service path.
This tap test does not prove every tag, phone, or cabinet.

Major section

Eddie's Math Bridge: Budget Five Years of NFC Wake Events · Integration Boundary

The mathematical gist: A 220 mAh, 3 V coin cell has about 167 mAh or 502 mWh usable after five years of 1% self-discharge and a 20% design reserve.

In most IoT systems, the tap identifies context; another layer decides the action.

NFC IoT integration boundary showing tag or credential input, reader, event builder, policy service, controller action, audit stream, fallback, and release evidence.

Major section

NFC Starts the Workflow, Not the System

NFC moves only small amounts of data slowly over a few centimeters, so its highest-value role in IoT is often bootstrapping a faster radio or authenticated workflow.

It makes the tap a strong selector for a setup workflow that still needs session checks, policy checks, and audit evidence.

NFC handover boundary showing NFC tap setup data separated from later Bluetooth, Wi-Fi, Thread, or backend carrier setup and session result.

Major section

NFC Starts the Workflow, Not the System (continued)

The app should not blindly configure that gateway.

A deliberate tap can hand over the information a device needs to join Wi-Fi, pair over Bluetooth, open a Thread commissioning path, or request a backend setup token.
App policy must validate that record and confirm the peer before any later carrier starts.
The integration is a chain with visible boundaries.
NFC selects the device and transfers a compact setup hint.

Major section

NFC Starts the Workflow, Not the System (continued)

Bluetooth, Wi-Fi, Thread, or a backend then carries configuration or service traffic; its connected, denied, timeout, or retry result is not an NFC result.

The token can carry the Wi-Fi or BLE setup path for this gateway; the tag itself should not contain a reusable network password or permanent authority.
The policy service decides whether this user may commission this asset now.
BLE or Wi-Fi carries the bulk configuration and later telemetry.
The audit stream records the tap, the decision, the action result, and the fallback path.

Major section

Gateway and Application Flow · Minimal Bridge Shape

The integration path depends on whether the tap is handled by a mobile app, a fixed gateway, an embedded reader, or a credential path.

The tag or credential is decoded and validated by the reader before an event is sent to a topic or API.

NFC IoT event flow from tap through reader validation, event topic or API, policy decision, local or backend action, audit stream, and fallback path.

Major section

Connection Handover and Setup Tokens

The NFC Forum Connection Handover standard defines how a tap bootstraps another carrier.

The NFC record is the handoff, not the long-running channel.
A release-quality handover test should include both the radio path and the ownership boundary.
A useful event can include tap_id, device_ref, reader_id, schema, payload_hash, session_id, network_state, and idempotency_key.

Major section

Connection Handover and Setup Tokens (continued)

For a sensor hub, the lab might use a static tag that carries an onboarding URL plus a device reference, not a shared building Wi-Fi password.

The mobile app follows the URL, authenticates the user, requests a one-use setup token, then opens a BLE session to write network settings to the hub.
Expected evidence includes decoded tag reference, token issued for the same hub, BLE connection established to the matching device identity, configuration write acknowledged, token consumed once, and audit row stored.
It should avoid direct personal identifiers in topic names or tag payloads.

Major section

Connection Handover and Setup Tokens (continued)

If the same tag is tapped twice in 10 seconds, the idempotency key should return the existing setup workflow rather than issuing two active tokens.

If the phone is offline, the app should either deny commissioning or use a documented cached policy with an expiry and a sync requirement.
If the tag points to an approved host but the gateway is already assigned to another site, policy must reject even though the NDEF record is syntactically valid.
For example, an MQTT topic like site/14/nfc/tap with a redacted event body is easier to govern than alice-smith/GW-142/tap.

Major section

Architecture Choice

A local policy can support an offline-critical action with low latency.

Backend policy centralizes decisions and audit but depends on connectivity for the action unless a fallback is defined.
A hybrid path must say which decisions may be made locally and how later records reconcile.
Topic design must avoid leaking sensitive identifiers and must include replay/idempotency handling.

Choosing where NFC IoT policy lives: local policy, backend policy, and hybrid cache compared across offline behavior, revocation, audit, latency, and support ownership.

Major section

Energy Harvesting and Battery-Less Commissioning

A field-detection pin can also let a powered device sleep until an NFC field appears, spending nothing until someone taps.

NFC can also power the device it configures.
The same tap provides the data channel and the temporary power.
Energy harvesting also changes the failure model.

Major section

Energy Harvesting and Battery-Less Commissioning (continued)

Battery-less commissioning lets a phone wake a headless unpowered device, deliver Wi-Fi or configuration data through an NFC-to-I2C bridge, store it, and then leave normal power to run the device later.

The hard engineering detail is the power budget, not the phrase "battery-less." Treat harvested energy as a measured resource for one short transaction.
If the wake-and-store sequence draws 2.8 mA at 1.8 V, the load is about 5.0 mW.
If the final product adds a metal bracket that weakens coupling, the measurement must be repeated with that bracket installed.

Major section

Energy Harvesting and Battery-Less Commissioning (continued)

If the lab measurement at the planned tap position only supports 4.0 mW continuously, the design has negative steady-state margin and must not be released as battery-less commissioning.

If a storage capacitor covers the shortfall, the evidence should show the capacitor voltage before and after the write, not just a successful demo video.
A normal powered gateway can retry, log locally, and use a network fallback.
A battery-less label may brown out halfway through a write, so records need a version, checksum or integrity marker, and a safe "not configured" state.

Major section

Release Evidence · Common Pitfalls

Payload proof identifies the NDEF record or object reference, hash, and schema; path proof names the reader or app, topic or API, and policy checkpoint.

The action record must show an idempotent result or rollback, while operations evidence keeps a sampled audit and owner.
Ignoring duplicate taps: NFC users often tap twice when feedback is slow.

NFC IoT release evidence records payload and path proof, a policy decision, action result, audit sample, owner, fallback and retest conditions for the approved integration.

Major section

Summary · Key Takeaway

NFC IoT integration should separate tag parsing from authorization.

A tap event needs schema, reader context, validation result, policy decision, idempotency, and audit fields.
Mobile apps, fixed gateways, embedded controllers, brokers, and backend services have different ownership boundaries.
Local, backend, and hybrid policy choices should be justified by offline behavior, revocation, audit, privacy, and support evidence.

Deck summary

Key takeaways

The tap can identify the cabinet and start a request, but it should not decide by itself that the door may open.

The mathematical gist: A 220 mAh, 3 V coin cell has about 167 mAh or 502 mWh usable after five years of 1% self-discharge and a 20% design reserve.
NFC moves only small amounts of data slowly over a few centimeters, so its highest-value role in IoT is often bootstrapping a faster radio or authenticated workflow.
The app should not blindly configure that gateway.
The NFC Forum Connection Handover standard defines how a tap bootstraps another carrier.

Retrieval practice

Recall check 1 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q1A maintenance tap works online. Which test best probes its release boundary?

AOffline replay/copy tests should cover fallback and audit.

BTap once more with the same phone while online

CTrust a valid tag URL to grant replacement permission

DHide failed taps from the audit trail to protect privacy

Show answer

Answer: A The test covers duplicate action, replay risk, offline policy, and evidence.

Retrieval practice

Recall check 2 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q2Why should an NFC-to-IoT integration never treat the decoded tag value as permission?

ABecause a URL record opens a web page, so access decisions belong to the browser.

BBecause the NDEF parser must validate record structure before the application accepts an action.

CBecause a tap can be repeated, so duplicate filtering should decide whether the action is allowed.

DThe tap only selects an object; policy and session must authorize the action.

Show answer

Answer: D In NFC-to-IoT integration the tap only selects an object; policy and session authorization must gate the action.

Retrieval practice

Recall check 3 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q3A headless smart speaker needs quick, secure setup that then streams audio. Why is NFC connection handover a strong choice, and what actually carries the audio?

ANFC handover passes Bluetooth pairing data out of band; the audio then streams over Bluetooth, not NFC.

BNFC streams the audio directly because it is faster than Bluetooth at very close range.

CThe tap works only if the speaker has no battery, using energy harvesting to stream.

DConnection handover encrypts the NFC radio so the audio is secure over NFC itself.

Show answer

Answer: A NFC connection handover passes Bluetooth or Wi-Fi setup material in alternative-carrier records so a tap bootstraps a faster radio.

Retrieval practice

Recall check 4 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q4An NFC tag on a gateway decodes to a valid service-record URL. What should the IoT application do before allowing a replacement action?

AValidate the record, evaluate policy and the work order, log the decision, then execute only if allowed.

BAllow the replacement because the service-record URL decoded successfully.

CStore the technician credential in the tag so the tag can approve the replacement later.

DSkip audit logging because tap actions are purely local, close-range interactions.

Show answer

Answer: A A valid NFC record identifies workflow context.

Print reference

Answers

Answer key.

A · The test covers duplicate action, replay risk, offline policy, and evidence.
D · In NFC-to-IoT integration the tap only selects an object; policy and session authorization must gate the action.
A · NFC connection handover passes Bluetooth or Wi-Fi setup material in alternative-carrier records so a tap bootstraps a faster radio.
A · A valid NFC record identifies workflow context.