如有轉載此文，請注明出處，文中引用的資料，如果有涉及到版權問題，還請告知，會立馬删除。
依照消息處理的流程，LLCP的消息會封裝成SNEP，交由上層進行分析處理。此章節将重點介紹SNEP Spec中重要的部分。
1. SNEP簡介
2. SNEP協定
SNEP簡介
SNEP(SimpleNDEF Exchange Protocol)是通過request/response的方式進行互動,對應的服務名稱(Service Name):urn:nfc:sn:snep,服務通路點(Service AccessPoint)：4.
SNEP支援分片傳輸，傳輸的第一個fragment必須包含完整的Header資訊，示意圖如下：
分片傳輸示意圖如下：
需要注意的是：
1. 接收方收到第一個分片資訊後，需要回複continue PDU給發送方。發送方收到continue PDU後，會繼續傳輸剩餘的分片資訊。如果接收方不支援對應的Version，則不會回複continue PDU，并放棄接收後續資料。
2. SNEP中檢查Version時，如果Major不一緻時，可能會傳回unsupportedversion；如果隻是minor版本不一緻，則會采用低版本的協定進行溝通
SNEP協定
主要從request和response兩個方面進行介紹。
request和response的封包格式如下：
由于Request/Response中的type字段都是由8bits資料表征其含義，是以整理了總表如下：
| 代碼 | 名稱 | 說明 | 解釋 |
| 00 | Continue | [Req]Send remain fragment | Client請求Server發送剩餘分片資訊 |
| 01 | Get | [Req] Server should return a NDEF MSG | 請求Server發送NDEF，此消息含Client能接收的最大消息長度 |
| 02 | Put | [Req]Server should accept a NDEF MSG | 請求Server接收NDEF，理論上Server端不要支援此部分 |
| 03-7E | Reserve | --- | ---- |
| 7F | Reject | [Req]Server should not send remaining msg | 停止發送資料，此消息不含information field |
| 80 | Continue | [Resp] Send remain fragment | Server回複的消息過長時，會以frag的方式發送 |
| 81 | Success | [Resp] Operation Success | 回複PUT時不含資訊域，回複GET時含資訊域 |
| 82-BF | Reserve | --- | --- |
| C0 | Not Found | [Resp]Resource not found | 不含資訊域 |
| C1 | Excess Data | [Resp]Resource exceed max size | 不含資訊域 |
| C2 | Bad request | [Resp]malformed request | 無法解析Request消息 |
| C3-DF | Reserve | --- | --- |
| E0 | Not impelement | [Resp]Unsupported functionality request | 無法識别的request code |
| E1 | Unsupported Version | [Resp]version not support | 不支援的版本資訊 |
| E2-FE | Reserve | --- | --- |
| FF | Reject | [Resp]don’t send remaining fragment | 不在接收剩餘的分片資訊 |
SNEP的協定比較簡單，是以介紹的篇幅會比較少。