NFC LLCP Peer-to-Peer Workbench

Trace how two NFC peer devices activate NFC-DEP, negotiate LLCP, and exchange NDEF data with SNEP.

Learner-ready NFC LLCP peer-to-peer workbench with scenario presets, animated protocol exchange, service discovery, SNEP payload and failure diagnostics, quick reference cards, source links, and desktop/mobile visual checks.

NFC peer mode LLCP SNEP NDEF

NFC LLCP Peer-to-Peer Workbench

Two NFC-enabled peer devices can exchange short application data after the RF link is active, LLCP has negotiated services, and the selected application protocol has a valid payload. This workbench makes each layer visible and shows why a tap-to-share exchange passes or fails.

Current objective Send a URI NDEF record over SNEP using connection-oriented LLCP.

Protocol path NFC-DEP -> LLCP -> SNEP -> NDEF

Important limit MIU and link timeout decide fragmentation pressure.

1

Peer-to-peer is a separate NFC role

A peer device is not just reading a passive tag and is not acting as a payment card. Both sides participate in a bidirectional NFC-DEP link.

2

LLCP multiplexes services

LLCP sits above NFC-DEP and offers connectionless and connection-oriented services using service access points, or SAPs.

3

SNEP moves NDEF messages

SNEP uses LLCP connection-oriented transport for simple request-response exchange of NDEF records such as URI, text, or handover messages.

Interactive workbench

URI share over SNEP

A phone sends a compact URI NDEF record to a nearby peer through the default SNEP service.

Peer A Initiator

ApplicationShare URL

SNEP / servicePUT request

LLCP SAPSSAP 16 -> DSAP 4

NFC-DEPPeer data link

Ready Tap Step to begin.

91% RF link quality

Peer B Target

ApplicationOpen received URI

SNEP / serviceDefault server SAP 4

LLCP SAPDSAP 4 accepts

NFC-DEPPeer data link

Current frame

RF field alignment

Bring both devices into a stable near-field operating volume before the peer data link can start.

Layer	RF / NFC activity
PDU or message	Polling and activation
DSAP / SSAP	Not used yet
Payload	No application data yet
Teaching note	NFC range is intentionally short; a weak field prevents every later protocol stage.

A

Watch the pass path

Use the URI share preset and step through the stages. Notice where NFC-DEP ends, where LLCP begins, and when SNEP carries NDEF.

B

Break service discovery

Turn off service advertisement. The RF link still works, but the application cannot bind to the expected LLCP service.

C

Compare transport styles

Use the connectionless notice preset and increase payload size beyond the MIU. Then compare it with SNEP fragmentation behavior.

Session controls

Link and payload conditions

Peer communication mode Active-passive peer mode Active-active peer mode

Tap distance

1.5 cm

Field disturbance

4%

NDEF payload

96 B

Negotiated LLCP MIU

248 B

Link timeout

500 ms

Both devices support NFC peer modeModern devices may support tag reading or payments without exposing phone-to-phone peer sharing to applications.

Expected LLCP service is advertisedSNEP can use its default service access point; named services still need discoverable binding.

NDEF message is validMalformed record length, type, or version fields should fail at the application exchange, not at RF activation.

SNEP version is compatibleA SNEP server can reject unsupported versions after the LLCP connection is already open.

Live readout

What the model predicts

OutcomePass

Frames14 frames

Payload plan1 SNEP chunk

Exchange time330 ms

Healthy peer-to-peer exchange

The RF link is strong, peer mode is available, the service can bind, and the NDEF payload fits the negotiated transport behavior.

Quick reference

NFC LLCP facts worth locating quickly

Use these cards to keep the protocol roles straight while experimenting with the workbench.

Peer mode

Both devices are active protocol peers. This is different from reader/writer mode and card emulation mode.

NFC-DEP

LLCP service types

Connectionless service has low setup cost; connection-oriented service adds in-order delivery and flow control.

UI or I-PDU

Service Access Points

SAP values multiplex link management, service discovery, default SNEP, and application services.

DSAP / SSAP

SNEP and NDEF

SNEP is a request-response protocol for exchanging NDEF messages over connection-oriented LLCP.

PUT / GET

Technical accuracy notes

• LLCP is shown as a data-link style protocol above NFC-DEP, not as an IP routing protocol or a payment protocol.
• SNEP is modeled on top of LLCP connection-oriented transport. The connectionless preset is included to contrast LLCP service types, not to imply SNEP normally uses connectionless delivery.
• The MIU, timeout, frame count, and exchange-time readouts are teaching approximations. They are useful for seeing pressure and failure modes, not for certifying a chipset.
• Android Beam is treated as a historical example of NFC-based sharing; Android deprecated it in Android 10 and related APIs are marked removed in current Android references.

Primary source links and next study

NFC Forum LLCP specification

Defines LLCP peer-to-peer communication, connectionless and connection-oriented services, and service multiplexing.

NFC Forum specification list

Includes Digital Protocol, SNEP, NDEF, and profile specifications used to place LLCP in the wider NFC stack.

NFC Forum NDEF specification

Defines the common data format carried by SNEP and many NFC tag applications.

Android Beam deprecation

Explains the platform status of Android Beam so learners do not treat it as a current universal sharing path.

Next: NFC card emulation, NFC Type 4 tag read/write, and NFC fundamentals.