26 NFC Modes and Protocols
Sammy the Sensor was confused: “Why does NFC need three different modes?” Max the Microcontroller broke it down: “Imagine you have a walkie-talkie. Sometimes you talk to a wall poster to get information – that is read/write mode. Sometimes you talk to your friend’s walkie-talkie – that is peer-to-peer mode. And sometimes you pretend your walkie-talkie is a door key – that is card emulation mode!” Bella the Battery compared the tag types: “Tags come in different sizes like T-shirts. Type 1 and 2 are like small sticky notes, good for a web address. Type 4 is like a full notebook with a lock on it, good for keeping payment secrets safe.” Lila the LED added, “And NDEF is like using the same language so every phone in the world can read every tag. No matter if you have an iPhone or Android, the tag always works!”
26.2 Learning Objectives
By the end of this chapter, you will be able to:
- Compare Operating Modes: Differentiate the technical details of peer-to-peer, read/write, and card emulation modes and justify when each is appropriate
- Evaluate Tag Types: Assess NFC tag types 1-5 based on memory, speed, security, and cost to select the optimal type for a given use case
- Analyze NDEF Messages: Deconstruct the NFC Data Exchange Format structure and classify common record types by their encoding and purpose
- Configure Protocol Selection: Apply protocol knowledge to design and justify NFC mode and tag type choices for specific IoT applications
NFC operates in three modes: reader mode (your phone reads a tag), card emulation mode (your phone acts like a contactless card), and peer-to-peer mode (two devices exchange data). Each mode has its own protocols and use cases. Understanding these modes helps you design the right NFC interaction for your IoT application.
26.3 Prerequisites
Before diving into this chapter, you should have completed:
- NFC Introduction and Basics: Understanding of what NFC is, its range characteristics, and basic operating modes
26.4 NFC vs RFID: Understanding the Relationship
NFC is a subset of HF RFID (13.56 MHz) with added capabilities:
What makes NFC different:
- Peer-to-peer mode: Two active devices can exchange data
- Card emulation: Phone can act like contactless card
- Built into smartphones: Billions of NFC-enabled devices
- User-initiated: Intentional touch-to-connect experience
- Standardized protocols: NDEF data format for interoperability
| Feature | RFID (General) | NFC |
|---|---|---|
| Frequency | LF, HF, UHF, Microwave | HF only (13.56 MHz) |
| Range | cm to 10m+ | 4-10 cm (intentionally short) |
| Modes | Read-only typically | Peer-to-peer, read/write, emulation |
| Devices | Specialized readers | Smartphones, tablets, wearables |
| Use Cases | Inventory, logistics, access | Payments, pairing, smart marketing |
| Standards | ISO 14443, 15693, 18000 | ISO 14443, ISO 18092, NFC Forum |
26.5 How NFC Works
26.5.1 Basic Operating Principle
NFC Communication:
- Proximity detection: Devices come within 4-10 cm
- Field generation: Active device creates 13.56 MHz field
- Power transfer: Passive tag harvests energy from field
- Data exchange: Bi-directional communication via load modulation
- Action: Payment, data transfer, or configuration triggered
26.6 NFC Operating Modes
NFC supports three distinct operating modes, making it more versatile than traditional RFID:
26.6.1 Peer-to-Peer Mode
Two active NFC devices exchange data
Use Cases:
- File sharing: Photos, contacts, documents between phones
- Bluetooth pairing: Touch phones to pair speakers/headphones
- Gaming: Transfer game data between devices
- Business cards: Exchange contact info
Protocol: ISO 18092 (NFCIP-1)
Example: Android Beam (deprecated but illustrative)
Android Beam used NFC P2P to share data between devices: - NfcAdapter enables NFC functionality - setNdefPushMessage() configures NDEF data to share - When devices touch, NDEF message is exchanged automatically
26.6.2 Read/Write Mode
Active device reads from or writes to passive NFC tag
Use Cases:
- Smart posters: Tap tag to open URL, download app
- Product information: Get details, reviews, instructions
- Home automation: Tap tag to trigger IoT scene
- Museum exhibits: Interactive information displays
- Inventory: Track and update asset information
Tag Types:
- Type 1-5 (different memory sizes and capabilities)
- Writable (can update content)
- Read-only (locked after writing)
26.6.3 Card Emulation Mode
Active device emulates a contactless smart card
Use Cases:
- Mobile payments: Apple Pay, Google Pay, Samsung Pay
- Transit ticketing: Subway/bus tap-to-pay
- Access control: Phone as building/hotel key
- Loyalty cards: Digital membership cards
Technologies:
- HCE (Host Card Emulation): Software-based, uses phone CPU
- SIM-based: Secure element in SIM card
- Embedded SE: Dedicated secure chip in phone
26.7 NFC Tag Types
NFC tags come in different types with varying memory and capabilities:
| Type | Memory | Speed | Rewritable | Use Case | Example |
|---|---|---|---|---|---|
| Type 1 | 96 bytes - 2 KB | 106 Kbps | Yes | Simple marketing | Topaz |
| Type 2 | 48 bytes - 2 KB | 106 Kbps | Yes | Smart posters | MIFARE Ultralight |
| Type 3 | Variable | 212 Kbps | Yes/No | Transit, eSIM | Sony FeliCa |
| Type 4 | 4 KB - 32 KB | 424 Kbps | Yes | High-security | MIFARE DESFire |
| Type 5 | 256 bytes - 8 KB | 106 Kbps | Yes | IoT sensors | ISO 15693 |
For simple tasks (URL, text): Type 2 (widely available) For payments, access: Type 4 (secure, encrypted) For IoT sensors: Type 5 (longer range within NFC spec) For read-only: Lock Type 2 after writing
26.8 NDEF (NFC Data Exchange Format)
NDEF is the standard data format for NFC, ensuring interoperability between devices.
26.8.1 NDEF Message Structure
26.8.2 Common NDEF Record Types
URI Record (open URL):
Type: U (URI)
Payload: https://example.com/product/123Text Record:
Type: T (Text)
Payload: "Tap to connect to Wi-Fi"Smart Poster:
Wi-Fi Configuration (Android):
Type: application/vnd.wfa.wsc
Payload: [Wi-Fi credentials encrypted]Scenario: You’re building a smart museum guide where visitors tap NFC tags to get exhibit information. You need to decide what content goes on the NFC tag vs. loaded from the cloud. Assume a typical Type 2 tag budget of ~888 bytes (NTAG216 user memory, plus NDEF overhead).
Think about:
- At 424 Kbps maximum, how long does ~888 bytes take to transfer? (Hint: ~7,100 bits / 424,000 bps)
- Users expect “instant” response (< 300 ms). Can you fit rich content on the tag?
- What’s the trade-off between tag-stored content vs. URL-to-cloud approach?
Key Insight - Transfer Time Calculation (order-of-magnitude):
- 888 bytes approximately 7,100 bits at 424 Kbps approximately ~17 ms theoretical
- Real-world with overhead: typically tens of milliseconds for ~1 KB
For an NTAG216 tag with 888 bytes user memory, how long does a full read take at maximum NFC speed? Convert bytes to bits and divide by data rate:
\[\text{Transfer time} = \frac{888 \text{ bytes} \times 8 \text{ bits/byte}}{424{,}000 \text{ bps}} = \frac{7{,}104 \text{ bits}}{424{,}000 \text{ bps}} = 0.01675 \text{ s} \approx 17 \text{ ms}\]
This is theoretical. Real-world protocol overhead (NDEF headers, anti-collision, ACKs) typically adds 2-3× the raw transfer time, giving 35-50 ms for a full 888-byte read. For a 4 KB Type 4 tag at 424 Kbps: \(4{,}096 \times 8 / 424{,}000 = 77\) ms theoretical, or ~150-200 ms with overhead — still under the 300 ms “instant” threshold.
| Data Type | Size | Transfer Time | UX |
|---|---|---|---|
| URL deep link | 200 bytes | a few ms | Instant |
| Payment token | 500 bytes | ~10-30 ms | Instant |
| vCard (basic) | ~700 bytes | tens of ms | Seamless |
| Full exhibit text | several KB | may not fit on typical Type 2 tags | Use URL |
| Photo/audio/video | 100+ KB | does not fit | Use Wi-Fi/BLE |
Museum Design Decision:
- Tag-stored: Exhibit ID + short URL (instant lookup)
- Cloud-loaded: Rich media, translations, audio guides
- Best practice: NFC for small identifiers/URLs, Wi-Fi/Bluetooth for bulk content
Verify Your Understanding:
- Why do transit cards (Oyster, Suica) only store ~500 bytes despite using NFC?
- For photo sharing between phones, why does “Android Beam” use NFC to initiate but Bluetooth/Wi-Fi for actual transfer?
26.9 NFC Bluetooth Handover
NFC handover combines the strengths of both technologies - NFC’s ease-of-use for connection setup, Bluetooth’s speed for data transfer:
Traditional Bluetooth pairing (without NFC):
Manual pairing steps:
- Enable Bluetooth on both devices
- Make device discoverable
- Scan for nearby devices (10-30 seconds)
- Select correct device from list
- Confirm pairing code or PIN
- Wait for connection (5-10 seconds)
- Begin data transfer
Total time: 30-60 seconds User actions: 5-8 steps
NFC-assisted Bluetooth pairing:
Simplified flow:
- Tap NFC devices together (< 1 second)
- NFC exchanges Bluetooth credentials via NDEF
- Bluetooth automatically connects (2-5 seconds)
- Data transfer begins
Total time: 3-6 seconds User actions: 1 step (tap)
What NFC exchanges:
NDEF message structure:
Handover Select Record:
- Carrier Type: Bluetooth
- Bluetooth MAC Address: 01:23:45:67:89:AB
- Bluetooth Class: 0x240404 (audio device)
- Bluetooth Name: "My Speaker"
- Bluetooth UUID: 0x110B (audio sink)
- Optional: Bluetooth passkey/PIN
Size: ~50-100 bytes Transfer time: < 100 milliseconds
Complete handover flow:
Performance comparison:
| Metric | Manual BT | NFC Handover |
|---|---|---|
| Pairing time | 30-60 sec | 3-6 sec |
| User steps | 6-8 steps | 1 tap |
| Discovery | Must scan | Instant |
| Selection | Pick from list | Automatic |
| Confirmation | PIN code | None |
| Error prone | Often fails | Reliable |
Why not use NFC for data transfer?
NFC limitations:
- Max speed: 424 Kbps (53 KB/sec)
- Practical range: 4-10 cm (must hold close)
- Requires proximity throughout transfer
Bluetooth advantages:
- Speed: 1-3 Mbps (125-375 KB/sec) = 7x faster
- Range: 10-100 meters (can move apart)
- Established connection persists
File transfer example:
10 MB photo album:
- Via NFC: 10 MB / 53 KB/sec = 189 seconds (3+ minutes, holding phones together!)
- Via Bluetooth: 10 MB / 250 KB/sec = 40 seconds (can put phones down!)
Best of both worlds:
- NFC: Quick pairing (1 second tap)
- Bluetooth: Fast transfer (40 seconds, hands-free)
26.10 Knowledge Check
Test your understanding of NFC modes and protocols with these questions.
A museum deploys NFC tags with NTAG216 chips (user memory 888 bytes) for exhibit information. Each tag stores a JSON payload with exhibit ID, title, and a short description. Calculate whether visitors will experience “instant” response (<300 ms).
Tag Configuration:
- Chip: NTAG216 (888 bytes user memory)
- Protocol: ISO 14443A at 106 kbps (Type 2 tag)
- Payload: 240 bytes JSON + 8 bytes NDEF header = 248 bytes total
Transfer Time Calculation:
Raw data: 248 bytes = 1,984 bits
At 106 kbps: 1,984 / 106,000 = 18.7 ms theoretical
With protocol overhead:
- Anti-collision (REQA/ATQA): ~3 ms
- UID selection: ~2 ms
- NDEF message read commands: ~15 ms
- CRC checks and ACKs: ~8 ms
Total realistic time: ~47 msComparison Table:
| Payload Size | Theoretical | With Overhead | User Experience |
|---|---|---|---|
| 48 bytes (URL only) | 3.6 ms | ~15 ms | Instant |
| 248 bytes (exhibit data) | 18.7 ms | ~47 ms | Seamless |
| 888 bytes (max capacity) | 67 ms | ~150 ms | Very responsive |
| 3 KB (Type 4 tag) | 226 ms | ~400 ms | Noticeable delay |
Result: At 47 ms, the tag read is well within the 300 ms “instant” threshold. The museum can confidently deploy this configuration.
Design Decision: The museum chooses to store the exhibit summary on-tag (240 bytes) rather than just a URL (40 bytes) because: - 47 ms vs 15 ms is imperceptible to users - Works offline (no cellular/Wi-Fi required) - Reduces cloud infrastructure costs - Degrades gracefully if backend is down
Selection Matrix:
| Use Case | Best Tag Type | Capacity | Security | Cost | Justification |
|---|---|---|---|---|---|
| Smart poster URL | Type 2 | 48-888 bytes | None | $0.10-0.30 | Read-only after encoding, disposable |
| Product authentication | Type 4 (DESFire) | 4-32 KB | AES-128 | $1.50-3.00 | Challenge-response prevents cloning |
| Transit payment card | Type 3 (FeliCa) | Variable | 3DES | $0.80-2.00 | 212 kbps speed, proven in Japan transit |
| Loyalty card (rewritable) | Type 2 (NTAG424) | 416 bytes | AES-128 | $0.50-1.00 | Balance updates, tamper detection |
| Pet microchip | ISO 15693 (Type 5) | 256-2048 bytes | None | $5-10 | 13.56 MHz penetrates tissue, global standard |
| Conference badge | Type 2 | 888 bytes | Optional | $0.30-0.50 | Name, company, QR code backup |
Decision Tree for Security Requirements:
- Does the application involve money or high-value assets?
- Yes → Type 4 (DESFire EV2/EV3) with mutual authentication
- No → Proceed to question 2
- Do you need to prevent tag cloning?
- Yes → Type 4 or NTAG 424 DNA (SUN authentication)
- No → Proceed to question 3
- Will the tag data be updated frequently (>100 times)?
- Yes → Type 3 (FeliCa) or Type 4 (10+ year endurance)
- No → Type 2 is sufficient
- Is cost the primary constraint (budget <$0.50 per tag)?
- Yes → Type 2 (NTAG213/215/216), lock after writing
- No → Type 4 for future flexibility
Real-World Example: Hilton Hotels initially tested Type 2 tags for room access (2012 pilot) but switched to Type 4 DESFire for production (2015 rollout) because Type 2 UIDs are easily cloned with $30 Proxmark devices. The $1.20 price premium per lock was justified by eliminating the risk of unauthorized room access.
The Mistake: A smart home startup designs a product catalog with NFC “tap to buy” tags using Type 2 NTAG213 chips. After deploying 5,000 tags in retail stores, they discover that older Android phones (pre-2018) frequently fail to read the tags, causing a 40% abandonment rate at checkout.
Why It Happens: Developers test with their current flagship smartphones (iPhone 14, Pixel 7) which support all NFC tag types. They assume “NFC works” universally without verifying backward compatibility with devices 3-5 years old, which represent 60%+ of the install base in emerging markets.
The Numbers:
| Phone Model | NFC Chip | Type 2 Support | Read Success Rate |
|---|---|---|---|
| iPhone 13+ (2021+) | Broadcom | Full | 99.2% |
| iPhone X-12 (2017-2020) | NXP PN80V | Full | 98.7% |
| Pixel 4+ (2019+) | ST Micro | Full | 98.9% |
| Galaxy S8-S10 (2017-2019) | Samsung S3FWRN5 | Partial | 72% (Type 2 only) |
| Budget Androids (<$200) | Various | Partial | 65-85% |
The Galaxy S8-S10 series (60 million units sold) has a firmware bug that causes 28% read failures on NTAG213 tags when the phone is in certain power states. The fix requires a non-standard NDEF format that breaks compatibility with iPhones.
How to Avoid:
- Test on device matrix: iPhone (oldest supported iOS), Android flagship (2 years old), Android budget (<$300), before production
- Use Type 4 tags for wide compatibility: Type 4 (ISO 14443-4) has better driver support across all vendors
- Design for degradation: Include a QR code backup on the same tag/sticker
- Monitor field failures: Track read success rates via app telemetry, flag specific phone models with low success
- Verify antenna coupling: Test tag reads at various angles and with phone cases (metal cases block NFC entirely)
The Fix (Post-Deployment): The startup reprinted 5,000 tags with Type 4 tags ($0.60 → $1.80 per tag, $6,000 additional cost) and added a QR code fallback. Read success rate increased to 96.5%, and checkout abandonment dropped to 8%.
26.11 Real-World Deployments: NFC Modes in Production
26.11.1 Tokyo Metro Suica: 89 Million Transit Cards on FeliCa (Type 3)
Japan’s Suica transit card system, operated by JR East, handles 89 million active NFC cards processing 16 million tap transactions per day across 4,370 station gates. Suica uses Sony FeliCa (NFC Type 3 tag), chosen specifically for its 212 kbps speed – double the 106 kbps of Type 1/2 tags used in Western transit systems.
Why speed matters for transit gates:
Tokyo’s busiest station gates process 60 passengers per minute during rush hour. Each tap must complete in under 200 ms to maintain flow. The transaction includes reading the card balance, deducting the fare, writing the new balance, and logging the trip – all within that 200 ms window:
| Operation | FeliCa (Type 3, 212 kbps) | MIFARE (Type 4, 106 kbps) | Impact |
|---|---|---|---|
| Mutual authentication | 35 ms | 70 ms | DES3/AES handshake |
| Read balance (16 bytes) | 8 ms | 16 ms | Balance + last trip |
| Calculate fare | 5 ms (card-side) | 5 ms | Same CPU |
| Write new balance | 12 ms | 24 ms | Includes verify |
| Write trip log | 12 ms | 24 ms | Station + timestamp |
| Total | 72 ms | 139 ms | FeliCa: 48% faster |
At 139 ms per transaction, MIFARE-based gates could theoretically handle 43 passengers per minute. FeliCa’s 72 ms enables 83 passengers per minute – essential for Shinjuku Station’s 3.6 million daily passengers.
Card emulation evolution:
Since 2016, JR East has offered “Mobile Suica” using card emulation mode on smartphones. The transition revealed critical differences between physical FeliCa cards and phone-based HCE:
- Physical FeliCa: Transaction completes in 72 ms (powered by reader’s RF field, no OS overhead)
- Apple Pay Suica (Secure Element): 95 ms (SE processes crypto independently from iOS)
- Android HCE Suica: 145 ms initially, optimized to 110 ms (CPU must wake from Doze, run crypto in OS)
JR East required all gate manufacturers to increase the NFC field hold time from 250 ms to 400 ms to accommodate smartphone latency variations, at a cost of $2.1M across 4,370 gates.
26.11.2 Apple AirTag: Card Emulation + Read/Write Hybrid
Apple’s AirTag uses a novel dual-NFC-mode design. When an iPhone taps a lost AirTag, the AirTag operates in card emulation mode (powered by the phone’s NFC field) and presents an NDEF URL record containing the AirTag’s encrypted serial number and the owner’s Find My contact information. This is technically Read/Write mode from the phone’s perspective but Card Emulation from the AirTag’s perspective – the AirTag has no battery-powered NFC controller and relies entirely on energy harvested from the 13.56 MHz field.
The NDEF payload is approximately 280 bytes:
NDEF Smart Poster Record:
URI: https://found.apple.com/airtag?id=<encrypted_serial>
Title: "AirTag Found"
Action: Open in browser
Apple-specific record: encrypted owner contact + location hintThis works with ANY NFC-enabled phone (Android or iPhone) because NDEF URL records are universally supported. No Apple app is required to help return a found AirTag – the standard NFC read/write capability of any smartphone opens the found.apple.com URL in a browser.
Common Pitfalls
NFC P2P mode requires both devices to support ISO 18092 (NFC-IP-1). Some NFC-enabled devices support only Reader/Writer mode. Fix: verify P2P support in both devices’ NFC specifications before designing a P2P application.
HCE emulates a card in software on the application processor; SE emulates a card in dedicated secure hardware. HCE is more flexible but less secure. Fix: use SE-based card emulation for payment applications; HCE is acceptable for access control and identification applications where the security bar is lower.
An NFC device that switches between Reader/Writer and Card Emulation modes may have timing delays during mode switching that cause failed transactions. Fix: measure mode-switching latency and verify it meets the timing requirements of both use cases.
26.12 Summary
This chapter covered NFC operating modes and protocols:
- NFC vs RFID: NFC is a specialized subset of HF RFID with peer-to-peer, card emulation, and smartphone integration
- Operating Modes: P2P for device-to-device, Read/Write for tag interaction, Card Emulation for payments
- Tag Types: Type 1-5 with varying memory (48 bytes to 32 KB), speed, and security features
- NDEF Format: Standardized data structure for URLs, text, smart posters, and custom records
- Bluetooth Handover: NFC reduces pairing from 60 seconds to 3 seconds with single tap
26.13 Concept Relationships
Builds On:
- RFID Fundamentals - NFC is a specialized HF RFID subset
- ISO 14443/18092 physical layer specifications provide the foundation for NFC protocols
Enables:
- NFC Security and Best Practices - Security practices require understanding modes
- NFC Access Control - Read/Write mode implementation
- Mobile payment systems via Card Emulation mode
Related Concepts:
- Bluetooth handover leverages P2P mode to simplify pairing
- NDEF format ensures cross-platform interoperability for all modes
- Tag types determine appropriate use cases for Read/Write mode
26.14 See Also
Standards & Specifications:
- NFC Forum Specifications - Official NDEF and LLCP protocol docs
- ISO 14443 - Proximity card standard underlying NFC
- ISO 18092 (NFCIP-1) - NFC Interface and Protocol specification
Practical Resources:
- Android NFC Developer Guide - P2P and Card Emulation examples
- NFC Tools App - Hands-on tag reading and NDEF creation
Books:
- Beginning NFC by Tom Igoe - Comprehensive guide to all three operating modes
- NFC Essentials by Ali Koudri - Deep dive into protocol layers and security
26.15 Try It Yourself
Beginner Challenge: Install an NFC reader app on your smartphone (NFC Tools or TagWriter). Find an NFC tag (transit card, hotel key, or purchase a blank tag for $0.50). Scan the tag and examine the NDEF message structure. Can you identify the record type (URI, Text, Smart Poster)?
Intermediate Challenge: Write a custom NDEF message to a blank tag using the app. Create a Smart Poster with: (1) a URL to your LinkedIn profile, (2) a text record with your name, and (3) a recommended action (“Visit website”). Test that both iOS and Android phones can read all three records.
Advanced Challenge: Use Android Beam (if available on older devices) or implement NFC P2P using the Android NDK. Exchange a vCard contact between two phones using LLCP protocol. Measure the transfer time for different payload sizes (100 bytes, 1 KB, 8 KB) and verify the practical limit for “instant” transfers (<300ms).
Hardware Project: Build an NFC tag reader using Arduino/ESP32 + RC522 module following the examples in NFC Access Control. Modify the code to detect which NFC tag type is scanned (Type 1-5) and display appropriate information about memory capacity and speed.
26.16 What’s Next
| Chapter | Focus | Link |
|---|---|---|
| NFC Security and Best Practices | Common implementation mistakes, security considerations, and decision frameworks for choosing between NFC, Bluetooth, RFID, and QR codes | Read |
| NFC Access Control Systems | Build an ESP32-based NFC door lock using PN532 reader, servo motor, and UID authorization with access logging | Read |
| NFC Smart Home Automation | Raspberry Pi-based smart home controller triggered by NFC tags placed around the house | Read |
| NFC Hands-On and Applications | Practical NFC implementations including tag programming, NDEF writing, and real-world deployment exercises | Read |