13 NFC Protocols: Mode Foundations

13.12 One Radio, Three Roles

This section: One Radio, Three Roles — All NFC runs at 13.56 MHz over a few centimetres, but a single NFC chip can take different roles on different taps.

All NFC runs at 13.56 MHz over a few centimetres, but a single NFC chip can take different roles on different taps. A phone may read a poster tag in reader/writer mode, present a credential to a cabinet reader in card emulation mode, and exchange a setup token with another powered device through peer-to-peer or handover. The role switch changes who owns timing, who owns the RF field, and which software boundary must approve the result.

Figure 13.3 assigns each NFC mode a different application owner.

+

The three exchanges in Figure 13.3 assign different owners to the same radio. In reader/writer mode, a phone reads a passive GW-142 label; the app validates its URI and asks whether the signed-in technician may configure that gateway. Peer mode exchanges a setup token between powered endpoints, then policy and freshness checks precede a Bluetooth or Wi-Fi handover. In card emulation, the phone answers a cabinet reader under issuer and verifier rules. Each mode has a different data owner and fallback, so a successful RF exchange says little about permission. Name the role and policy owner before choosing a commissioning or access design.

Use an IoT commissioning review as the concrete test. If a phone taps a gateway label to open https://ops.example/setup/GW-142, the phone is in reader/writer mode and the passive label only supplies a small record. The app must still validate the URI, bind it to an authenticated technician session, and ask policy whether this gateway can be configured.

If the same phone is presented to a cabinet reader as a service credential, it is in card emulation mode. The reader powers the field, sends commands, and the phone answers only if the credential application allows that reader application. If two powered devices exchange a setup token, peer-to-peer or handover may apply, but the follow-on Bluetooth, Wi-Fi, Thread, or backend session carries the durable connection.

A useful mode decision names four things before release: the physical role, the payload type, the policy owner, and the fallback. For reader/writer, fallback might be a printed asset ID. For card emulation, fallback might be a manual credential check or denied-entry message. For handover, fallback might be a setup code when the follow-on carrier fails.

Math Bridge · guided foundationsWhy are 106, 212, and 424 kbps hiding inside 13.56 MHz?Let Eddie divide the field clock, time one bit, and compare the result with a bounded capacity screen. Learn the maths

The data-rate discussion rests on the carrier and coupling mechanism, not just three memorised numbers. Inspect Figure 13.4 to place the labelled 13.56 MHz reader beside the tag’s Antenna coil before following the protocol timing.

+

Read Figure 13.4 from the magnetic field (near-field coupling) between the reader and Contactless Card / Tag to its explicit conclusion, Like a transformer, not a radio link. A passive tag harvests energy from that overlapping field and replies by load modulation rather than launching an independent travelling wave. That physical account connects back to the chapter’s rates: the protocol’s subcarrier and coding choices are organized around the 13.56 MHz field, while successful operation still depends on coil overlap and coupling.

13.13 Reader/Writer Mode

This section: Reader/Writer Mode — Reader/writer mode is the default pattern for smart posters, asset tags, commissioning labels, maintenance tags, and many IoT field workflows.

Reader/writer mode is the default pattern for smart posters, asset tags, commissioning labels, maintenance tags, and many IoT field workflows. The reader creates the RF field, polls for targets, activates one tag, and performs reads or writes. The tag responds only when selected and powered by the reader field.

Use reader/writer mode when the physical object can carry a passive tag and the application can treat the tap as an input signal. The tag can hold a short identifier, a URI, a configuration hint, or a small signed payload. It should not be treated as the authority for high-impact decisions unless the application verifies the data and the deployment threat model supports that choice.

13.14 Card Emulation Mode

This section: Card Emulation Mode — Card emulation mode lets a device respond to an external reader as if it were a contactless card.

Card emulation mode lets a device respond to an external reader as if it were a contactless card. The external reader still controls the RF field and command timing. The emulating device decides, through its local policy and credential storage model, whether it can answer the requested application.

Use card emulation when the environment already has readers that expect card behavior, such as access terminals, fare gates, equipment cabinets, or dedicated service tools. The important design question is not only “can the phone emulate a card?” but also “which application owns the credential, which reader applications are accepted, and how are failed or ambiguous taps handled?”

13.15 Peer-to-Peer Mode

This section: Peer-to-Peer Mode — Peer-to-peer mode uses NFCIP-1 so two active devices can exchange data over an NFC link.

Peer-to-peer mode uses NFCIP-1 so two active devices can exchange data over an NFC link. LLCP provides a link layer for peer services, and SNEP is one way to exchange NDEF messages over that link.

The two powered peers first negotiate a link they can both implement. The initiator proposes communication parameters during activation; the target answers with its capabilities. The agreed values bound data rate, active or passive communication behavior, timing, and the maximum information field that can be carried in one protocol data unit. In the classic teaching profile, the data block is at most 256 bytes. That is a block limit, not a promise of 256 bytes of application payload: protocol control and framing consume part of the exchange, and a larger message needs segmentation, acknowledgements, and recovery.

Walk a short setup exchange:

1. Discover and activate. One device polls, the other answers, and anti-collision leaves one target selected.
2. Negotiate. The peers agree parameters that fit both endpoints, including the maximum data unit they will accept.
3. Bind a service. LLCP identifies the peer service; SNEP or another agreed protocol carries the small record.
4. Exchange setup evidence. Send a carrier choice, device identifier, ephemeral public key, nonce, or setup token—not an unbounded media object.
5. Confirm the boundary. Both applications validate the record, user intent, freshness, and authorization before enabling another radio.
6. Transfer elsewhere. Bluetooth or Wi-Fi owns the longer-range or higher-bandwidth session, including its own key establishment, retry, reconnect, and throughput behavior.

For example, an NFC tap can identify a speaker and carry authenticated Bluetooth handover data. The devices then stop treating NFC as the transport and establish the audio link over Bluetooth. This reduces discovery and device-selection friction, but proximity is not authorization: the application still has to reject stale or substituted handover records and make failure visible.

Do not assume general-purpose phone-to-phone P2P is available in a deployed device. Many systems instead use NFC for a small handover message and move the longer session to Bluetooth, Wi-Fi, Thread commissioning, or an application backend. Treat P2P as a specific capability to verify, not as something every NFC device will expose to applications.