SNEP (Simple NDEF Exchange Protocol)
A protocol for exchanging NDEF messages between two NFC devices in peer-to-peer mode. SNEP provides a simple request/response model for putting and getting NDEF messages over an LLCP connection.
What Is SNEP?
SNEP (Simple NDEF Exchange Protocol) is a lightweight application-layer protocol defined by the NFC Forum for exchanging NDEF messages between two active NFC devices in peer-to-peer mode. Built on top of LLCP (Logical Link Control Protocol), SNEP provides a simple request-response model for putting (sending) and getting (requesting) NDEF messages over an NFC peer-to-peer connection.
SNEP Architecture
SNEP operates at the top of the NFC peer-to-peer protocol stack:
| Layer | Protocol | Function |
|---|---|---|
| Application | SNEP | NDEF messageNDEF messageComplete data unit containing one or more NDEF recordsView full → exchange (put/get) |
| Transport | LLCP | Connection management, flow control |
| Data link | NFCIP-1 | RF communication, role switching |
| Physical | 13.56 MHz | RF field and modulation |
SNEP uses LLCP's connection-oriented transport service (service access point 4) to ensure reliable, ordered delivery of NDEF messages. The connection-oriented mode provides acknowledgment and retransmission, guaranteeing that the complete NDEF message is received without corruption.
Protocol Operations
SNEP defines two primary operations:
PUT request. The client sends an NDEF message to the server. The server acknowledges receipt with a success or failure response. This is the operation used by Android Beam to push content from one phone to another.
GET request. The client requests an NDEF message from the server, optionally specifying an acceptable record type. The server responds with the requested NDEF message or an error if no matching content is available.
Message Format
A SNEP message consists of a compact header followed by the payload:
| Field | Size | Description |
|---|---|---|
| Version | 1 byte | SNEP protocol version (currently 1.0) |
| Request/Response | 1 byte | Operation type or status code |
| Length | 4 bytes | Payload length in bytes |
| Information | Variable | NDEF message payload |
The maximum NDEF message size that SNEP can transmit depends on the negotiated LLCP MIU (Maximum Information Unit). With the default MIU of 128 bytes, large NDEF messages are fragmented across multiple LLCP information PDUs. SNEP handles this fragmentation transparently.
Response Codes
SNEP uses a simple set of response codes:
| Code | Meaning |
|---|---|
| 0x81 | Success |
| 0xC0 | Not Found (GET only) |
| 0xC1 | Excess Data (payload too large) |
| 0xC2 | Bad Request (malformed message) |
| 0xE0 | Not Implemented |
| 0xFF | Unsupported Version |
SNEP and Android Beam
The most widely known implementation of SNEP was Android Beam, introduced in Android 4.0 (2011). When two Android phones with NFC were tapped together, SNEP exchanged NDEF messages containing the current activity's content. For large transfers, Android Beam used SNEP only for the initial handshake, then handed off to Bluetooth or Wi-Fi Direct.
Although Android Beam was deprecated in Android 10 (2019), SNEP remains a required component of the NFC Forum Certification program. Devices must demonstrate correct SNEP client and server behavior as part of the certification test suite.
SNEP vs Direct NDEF Access
For tag-based NFC interactions (reader/writer mode), SNEP is not used. The reader accesses the tag's NDEF data directly through the tag's command set (READ, WRITE). SNEP is exclusively a peer-to-peer protocol for device-to-device NDEF exchange. Understanding this distinction is important when designing NFC systems: tag interactions use NDEF over the tag protocol, while device-to-device interactions use NDEF over SNEP over LLCP.
Related Terms
Related Guides
الأسئلة الشائعة
The NFC glossary is a comprehensive reference of technical terms, acronyms, and concepts used in Near Field Communication technology. It is designed for developers, product managers, and engineers who work with NFC and need clear definitions of terms like NDEF, APDU, anti-collision, and ISO 14443.
Each glossary term is cross-referenced with related NFC chips, standards, and other terms. For example, the term 'AES-128' links to chips that support AES encryption (NTAG 424 DNA, DESFire EV2/EV3), and the term 'ISO 14443' links to all chips compliant with that standard.
Yes. NFCFYI provides glossary definitions in 15 languages including English, Korean, Japanese, Chinese, Spanish, Portuguese, Hindi, Arabic, French, Russian, German, Turkish, Vietnamese, Indonesian, and Thai. Use the language selector in the header to switch languages.