RFID, NFC & UWB · Study deck
Practice: NFC Reader Simulation
Picture a phone tapping a label to open the correct equipment record.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Define what an NFC reader simulation can and cannot prove.
- Model the reader state sequence from polling through tag selection, NDEF parsing, policy validation, and release evidence.
- Decode simple NDEF TLV and URI records well enough to spot length, type, and host-validation failures.
- Simulate multi-tag, malformed-payload, cloned-static-data, and relay-risk scenarios without overclaiming physical accuracy.
Major section
Start With the Story
A software exercise can show whether the reader accepts a wrong field or repeated message before radio details make the fault harder to see.
- NFC means Near Field Communication, a short-range link used for deliberate taps.
- A payload means the useful record carried inside a message.
- A protocol means the shared rules for an exchange.
Major section
Start With the Story (continued)
This runway does not prove antenna range, phone behavior, or field timing.
- The deeper lab covers reader states, NDEF structure, validation, injected faults, evidence capture, and the hardware checks left open.
- A simulation cannot prove the RF field, but it can make the NFC logic visible.
- Polling, anti-collision, NDEF parsing, policy checks, and failure cases become easier to inspect when the lab removes the hardware uncertainty.
Major section
In 60 Seconds · Simulation Scope
The goal is not to emulate antenna tuning, phone operating-system behavior, or every timing detail of the 13.56 MHz radio link.
- An NFC simulation is useful when it is honest about its boundary.
- A browser or microcontroller sketch can model bytes, state transitions, and policy checks.
- The next plan must test typical tags, phones, cases, mount surfaces, and fault paths on real hardware.
Try it: In 60 Seconds · Simulation Scope in the chapter
Major section
Reader State Model · Minimal Scenario Record
The simulation should make each transition explicit so a bad tag, ambiguous field, malformed record, or policy denial is visible rather than hidden behind a single "read failed" message.
- Idle to polling: The reader waits, then sends a polling request for compatible tags in range.
- Polling to selection: If more than one candidate responds, the anti-collision procedure selects one tag at a time.
- Policy to evidence: The simulation stores the decision, trace, inputs, and reason codes for the lab report.
- The record should describe what the simulated reader sees, not pretend to be real RF data.
Major section
Activation Loop Trace · Activation Sequence Details
Simulating an NFC reader means modelling a repeating loop, not a single read.
- Detection reports a nearby target, while anti-collision resolves a participant when more than one response appears.
- That trace lets a review distinguish a polling miss, collision-resolution issue, payload rejection, policy denial, or release-evidence outcome.
- The byte trace can stay small.
Major section
NDEF Trace Review · Parser Checks
The simulation should teach byte-level reasoning without burying the learner in a thousand-line sketch.
- The important question is whether the parser and application disagree with the raw bytes.
- The 03 TLV marks an NDEF message and its length field bounds the bytes that follow.
Major section
Failure Injection Matrix
A useful lab does not only show the happy path.
- It should include failure scenarios that force the reader and application to explain their decision.
- A valid maintenance URI may reach authorization, while two visible tags require isolation or explicit selection.
- Each outcome retains inputs, reason codes, lock state, timing, and the resulting decision.
Major section
Failure Injection Matrix (continued)
Malformed length must stop before policy receives a partial URI, and an unknown host must not be opened even when parsing succeeds.
- Locked-tag writes fail safely, while suspicious timing is recorded as a freshness and review signal rather than automatic attack proof.
- Malformed payload: Confirm that parser errors stop action and produce a readable reason code.
- Multiple tags: Confirm that the reader either selects one predictable tag or asks the user to isolate the target.
Major section
UID Anti-Collision and Cascade Levels · Worked Example: Maintenance Tag Review
Once the full UID is known, SELECT activates that one card.
- For NFC-A, ISO/IEC 14443-3 Type A uses bit-oriented anti-collision over the card UID.
- That binary walk continues until one card is uniquely identified.
- The simulator should expose the difference between reader capability and application safety.
Major section
Simulation Design
The local run returned ACCEPT reference=https://ops.example/A7 action=requires_app_authorization.
- The expected output is an asset reference, not permission to update an asset.
- In the card-emulation workbench, compare the host app and secure-element routes and note the selected AID.
- Changing the URI host in the fixture returned REJECT unknown_host.
Try it: Simulation Design in the chapter
Major section
Checkpoint: Acceptance Evidence · Common Pitfalls
Using a new-project simulator as evidence: A generic board page does not validate an NFC workflow unless the scenario, parser, policy, and failure cases are explicit.
- Confusing parsed data with trusted data: Valid NDEF syntax only means the bytes decoded.
- The application still needs host, type, length, schema, and authorization checks.
- Overclaiming relay detection: Timing signals can inform risk, but credential flows need challenge freshness, policy, audit, and fallback decisions.
Major section
Checkpoint: Summary · Key Takeaway
A useful NFC simulation is a logic and evidence tool, not a substitute for RF, phone, and installation testing.
- Valid NDEF syntax does not mean the payload is trusted or authorized.
- Failure injection is part of the lab, especially malformed records, unexpected hosts, nearby tags, lock-state errors, and relay-risk signals.
- The final lab output should say what passed, what failed, what remains unproven, and what must be tested with real hardware.
Deck summary
Key takeaways
A software exercise can show whether the reader accepts a wrong field or repeated message before radio details make the fault harder to see.
- This runway does not prove antenna range, phone behavior, or field timing.
- The goal is not to emulate antenna tuning, phone operating-system behavior, or every timing detail of the 13.56 MHz radio link.
- The simulation should make each transition explicit so a bad tag, ambiguous field, malformed record, or policy denial is visible rather than hidden behind a single "read failed" message.
- Simulating an NFC reader means modelling a repeating loop, not a single read.
Retrieval practice
Recall check 1 of 5

Radio Remi says: answer from memory, then check your reasoning.
Q1A reader simulation accepts a tag before checking its payload and host policy. Which sequence should be tested?
Show answer
Answer: C Selection precedes decoding and application approval.
Retrieval practice
Recall check 2 of 5

Radio Remi says: answer from memory, then check your reasoning.
Q2A software-only NFC reader simulation passes its tests. Which claim is safe to make?
Show answer
Answer: B A software-only NFC simulation can only claim its parser and policy handled the tested NDEF and failure cases.
Retrieval practice
Recall check 3 of 5

Radio Remi says: answer from memory, then check your reasoning.
Q3A tag record claims more bytes than the reader received. What should reject it first?
Show answer
Answer: B An invalid length must not become a partial URI.
Retrieval practice
Recall check 4 of 5

Radio Remi says: answer from memory, then check your reasoning.
Q4In an NFC reader simulation, two Type A cards enter the field simultaneously. What should the modelled reader do, and via what mechanism?
Show answer
Answer: A NFC-A resolves multiple cards with bit-oriented UID anti-collision across cascade levels for 4, 7, or 10 byte UIDs, then SELECT activates one card before ISO 7816-4 APDU exchange.
Retrieval practice
Recall check 5 of 5

Radio Remi says: answer from memory, then check your reasoning.
Q5Which claim is safe to make after a software-only NFC reader simulation passes?
Show answer
Answer: B The right conclusion is limited and evidence-based: the modeled logic passed the tested scenarios.
Print reference
Answers 1 of 2
Answer key.
- C · Selection precedes decoding and application approval.
- B · A software-only NFC simulation can only claim its parser and policy handled the tested NDEF and failure cases.
- B · An invalid length must not become a partial URI.
- A · NFC-A resolves multiple cards with bit-oriented UID anti-collision across cascade levels for 4, 7, or 10 byte UIDs, then SELECT activates one card before ISO 7816-4 APDU exchange.
Print reference
Answers 2 of 2
Answer key.
- B · The right conclusion is limited and evidence-based: the modeled logic passed the tested scenarios.