依照學習流程，此章節主要介紹NFCForum中LLCP Spec。主要是将LLCP spec中重要的内容摘要出來，包含的内容肯定不是很全面，但基本上看代碼是夠用了。主要分為三部分：
1.LLC概述
2.LLC協定
3.LLCP鍊路
1 LLC概述
LLC：（logicallink control）按照網絡協定的層次劃分，就是其中的資料鍊層，用圖表表示如下：
依據資料傳輸模式，可以劃分為：
1. 面向連接配接傳輸
2. 無連接配接傳輸
依據連接配接的種類分：
Class1：無連接配接傳輸
Class2：面向連接配接傳輸
Class3：無連接配接傳輸和面向連接配接傳輸
2 LLC協定
由于LLCP Spec有49頁，目前研究的是1.2版本，主要從以下幾個方面進行解讀：
2.1 LLC封包格式：
2.1.1 服務通路點（Service AccessPoint）
其中服務通路點（Service Access Point）表征不同的服務，具體說明如下：
細化00h-0Fh如下：
00h：用于LLC管理子產品，不能用于任何SAP
01h：用于服務發現協定（Service Discovery Protocol），對應服務名urn:nfc:sn:sdp
04h：用于SNEP協定（Simple NDEF ExchangeProtocol），對應服務名：urn:nfc:sn:snep
2.1.2 類型PTYPE
其中PTYPE表征目前資訊的類型，為較好說明問題，簡單整理如下：
| PDU TYPE | PTYPE | EXPLAIN | SEQUENCE | INFORMATION |
| SYMM | 0000 | 可用于防止link timeout | X | X |
| PAX | 0001 | 交換參數資訊 | X | V |
| AGF | 0010 | 将資料拆包後發送，至少需要2個PDU | X | V |
| UI | 0011 | 無編号資訊 | X | V |
| CONNECT | 0100 | 連接配接請求 | X | V |
| DISC | 0101 | 斷開連接配接 | X | X |
| CC | 0110 | 連接配接完成，資訊域含有參數資訊 | X | V |
| DM | 0111 | 斷開模式，在CONNECT指令無法執行時回複,并且帶有REASON字段 | X | V |
| FRMR | 1000 | 拒絕，會帶flag說明拒絕原因 | X | V |
| I | 1100 | 有效資訊，含N(S),N(R) | V | V |
| RR | 1101 | 可以接收資料 | V | X |
| RNR | 1110 | 暫時無法接受資料 | V | X |
| SNL | 1001 | 服務名查詢 | X | V |
備注： X表示不含此field，V表示含有此field
每種TYPE的封包格式如下：
SYMM：
PAX：
AGF：
UI：
CONNECT：
DISC:
CC：
DM:
其中DM的reason字段說明如下：
FRMR：
其中information字段說明
I:
RR:
RNR：
SNL：
2.1.3 資訊域（Information）
介紹完PTYPE，就到Information域中的說明了，所有information中的資訊都遵循TLV格式（type，length，value），spec整理了下面的table友善大家了解：
同樣，針對上面的名稱，分别說明其格式：
VERSION：
MIUX：當information中的長度大于預設值128時，系統會發送IMUX給對方告知自身能力，對方會依據IMUX+128計算出實際接收的容量
WKS：依據SAP中00h-0Fh定義，每bit對應一個sap
LTO：預設為100ms，機關是10ms，表征上次收到資料和此次發送資料的時間差
RW：預設為1，表示每個I PDU都要回複，0表示不接收I PDU
SN：格式為“urn:nfc:sn:<servicename>”/“urn:nfc:xsn:<domain>:<sn>”
OPT：表征link service class(低2位)或其他(高6位)
SDREQ：
SDRES：
3 LLCP鍊路
此部分詳細過程請參考Spec第五章，抽取主要部分說明一下。
3.1 MIU說明
MIU預設值是128，發送端的資訊域大小不應該大于接收端的MIU，接收端收到大于自身MIU的資料時會直接丢棄。雙方各自維護自己和對方的MIU，預設值為128，且滿足MIUX+128=MIU。若收到對方的MIUX，儲存對應的MIU資訊。
3.2 鍊路激活流程
當MAC層激活完成，并判斷出對端節點帶LLCP能力時，就會來建立LLCP連接配接。MAC層中交換的LLC參數，對于LLCP過程是可見的。
在LLCP鍊路建立過程中，會先進行version判斷
1. Version判斷失敗，則連接配接過程直接斷開
2. Version檢查成功，繼續進行MIU的檢查，最後鍊路才建立完成
3.3 PAX流程
MAC層會知道目前的裝置角色是Initiator/Target：
1. Target
a) 發送MAC中還未交換的parameter資訊，等待對方回複
b) 收到回複，啟動Version判斷
c) Version通過，決定MIU，否則連接配接失敗
2. Initiator
a) 等待對方先發送PAX
b) Version檢查通過，決定MIU，并發送PAX PDU
3.3.1 Version檢查
其中Version檢查的流程如下：
1. Major&Minor 都相等 -> OK
2. Major相等，Minor不等，取Minor較小的版本 -> OK
3. Major&Minor都不相等，由major大的一端決定是否相容，若相容，使用Major小的版本
3.4 Intentional Link Deactivation
當DISC PDU中的SSAP和DSAP為00h時，發送端發送後，直接斷開本地連接配接，接收端收到後，也可以直接斷開本地連接配接。此類DISC PDU（SSAP和DSAP為00h）不需要等待回複，但其他的DISC PDU（SSAP和DSAP不為00h）需要等待DM PDU。
3.5 鍊路建立流程
在發送端發送CONNECT PDU，此類PDU(SSAP相同)不能在未收到CC/DM時重複發送。同時，收到CC PDU時，DSAP可能和CONNECT PDU中SSAP會不一緻。
此時分兩種情況：
Case1：發送端收到CC PDU，但未收到CONNECT的ACK時：
I. CC中DSAP和CONNECT中SSAP相等
*初始化V(S),V(R),V(SA),V(RA)為0
*處理CC PDU中的參數
*進入資料傳輸階段
II. CC中DSAP和CONNECT中SSAP不相等
*直接放棄連接配接
Case2：接收端收到CONNECT PDU時：
I. 無法處理時，傳回DM PDU
II. 可處理時
*處理CONNECT PDU中的參數
*通知上層，并等待上層接收或者拒絕
>拒絕時，直接放棄連接配接，并發送DM
>接受時，發送CC PDU，V(S),V(R),V(SA),V(RA)為0并開始資料傳輸
需要注意的是，在資料傳輸階段，任何的CONNECT/CC PDU都會被認為是Invalid。
3.6 服務發現（Service Discover）
SDREQ一般是出現在SNL PDU中。收到SDREQ後，需要先判斷Service Name是否有注冊，注冊過則回複SDRES，其中含有效SAP及TID，未注冊時，回複SDRES中SAP為全0。
以上是該Spec大緻的内容，基本上可以涵蓋Android NFC中LLCP的流程。如果有描述不正确的地方，也歡迎大家指正，感謝。
依照學習流程，此章節主要介紹NFCForum中LLCP Spec。主要是将LLCP spec中重要的内容摘要出來，包含的内容肯定不是很全面，但基本上看代碼是夠用了。主要分為三部分：
1.LLC概述
2.LLC協定
3.LLCP鍊路
1 LLC概述
LLC：（logicallink control）按照網絡協定的層次劃分，就是其中的資料鍊層，用圖表表示如下：
依據資料傳輸模式，可以劃分為：
1. 面向連接配接傳輸
2. 無連接配接傳輸
依據連接配接的種類分：
Class1：無連接配接傳輸
Class2：面向連接配接傳輸
Class3：無連接配接傳輸和面向連接配接傳輸
2 LLC協定
由于LLCP Spec有49頁，目前研究的是1.2版本，主要從以下幾個方面進行解讀：
2.1 LLC封包格式：
2.1.1 服務通路點（Service AccessPoint）
其中服務通路點（Service Access Point）表征不同的服務，具體說明如下：
細化00h-0Fh如下：
00h：用于LLC管理子產品，不能用于任何SAP
01h：用于服務發現協定（Service Discovery Protocol），對應服務名urn:nfc:sn:sdp
04h：用于SNEP協定（Simple NDEF ExchangeProtocol），對應服務名：urn:nfc:sn:snep
2.1.2 類型PTYPE
其中PTYPE表征目前資訊的類型，為較好說明問題，簡單整理如下：
| PDU TYPE | PTYPE | EXPLAIN | SEQUENCE | INFORMATION |
| SYMM | 0000 | 可用于防止link timeout | X | X |
| PAX | 0001 | 交換參數資訊 | X | V |
| AGF | 0010 | 将資料拆包後發送，至少需要2個PDU | X | V |
| UI | 0011 | 無編号資訊 | X | V |
| CONNECT | 0100 | 連接配接請求 | X | V |
| DISC | 0101 | 斷開連接配接 | X | X |
| CC | 0110 | 連接配接完成，資訊域含有參數資訊 | X | V |
| DM | 0111 | 斷開模式，在CONNECT指令無法執行時回複,并且帶有REASON字段 | X | V |
| FRMR | 1000 | 拒絕，會帶flag說明拒絕原因 | X | V |
| I | 1100 | 有效資訊，含N(S),N(R) | V | V |
| RR | 1101 | 可以接收資料 | V | X |
| RNR | 1110 | 暫時無法接受資料 | V | X |
| SNL | 1001 | 服務名查詢 | X | V |
備注： X表示不含此field，V表示含有此field
每種TYPE的封包格式如下：
SYMM：
PAX：
AGF：
UI：
CONNECT：
DISC:
CC：
DM:
其中DM的reason字段說明如下：
FRMR：
其中information字段說明
I:
RR:
RNR：
SNL：
2.1.3 資訊域（Information）
介紹完PTYPE，就到Information域中的說明了，所有information中的資訊都遵循TLV格式（type，length，value），spec整理了下面的table友善大家了解：
同樣，針對上面的名稱，分别說明其格式：
VERSION：
MIUX：當information中的長度大于預設值128時，系統會發送IMUX給對方告知自身能力，對方會依據IMUX+128計算出實際接收的容量
WKS：依據SAP中00h-0Fh定義，每bit對應一個sap
LTO：預設為100ms，機關是10ms，表征上次收到資料和此次發送資料的時間差
RW：預設為1，表示每個I PDU都要回複，0表示不接收I PDU
SN：格式為“urn:nfc:sn:<servicename>”/“urn:nfc:xsn:<domain>:<sn>”
OPT：表征link service class(低2位)或其他(高6位)
SDREQ：
SDRES：
3 LLCP鍊路
此部分詳細過程請參考Spec第五章，抽取主要部分說明一下。
3.1 MIU說明
MIU預設值是128，發送端的資訊域大小不應該大于接收端的MIU，接收端收到大于自身MIU的資料時會直接丢棄。雙方各自維護自己和對方的MIU，預設值為128，且滿足MIUX+128=MIU。若收到對方的MIUX，儲存對應的MIU資訊。
3.2 鍊路激活流程
當MAC層激活完成，并判斷出對端節點帶LLCP能力時，就會來建立LLCP連接配接。MAC層中交換的LLC參數，對于LLCP過程是可見的。
在LLCP鍊路建立過程中，會先進行version判斷
1. Version判斷失敗，則連接配接過程直接斷開
2. Version檢查成功，繼續進行MIU的檢查，最後鍊路才建立完成
3.3 PAX流程
MAC層會知道目前的裝置角色是Initiator/Target：
1. Target
a) 發送MAC中還未交換的parameter資訊，等待對方回複
b) 收到回複，啟動Version判斷
c) Version通過，決定MIU，否則連接配接失敗
2. Initiator
a) 等待對方先發送PAX
b) Version檢查通過，決定MIU，并發送PAX PDU
3.3.1 Version檢查
其中Version檢查的流程如下：
1. Major&Minor 都相等 -> OK
2. Major相等，Minor不等，取Minor較小的版本 -> OK
3. Major&Minor都不相等，由major大的一端決定是否相容，若相容，使用Major小的版本
3.4 Intentional Link Deactivation
當DISC PDU中的SSAP和DSAP為00h時，發送端發送後，直接斷開本地連接配接，接收端收到後，也可以直接斷開本地連接配接。此類DISC PDU（SSAP和DSAP為00h）不需要等待回複，但其他的DISC PDU（SSAP和DSAP不為00h）需要等待DM PDU。
3.5 鍊路建立流程
在發送端發送CONNECT PDU，此類PDU(SSAP相同)不能在未收到CC/DM時重複發送。同時，收到CC PDU時，DSAP可能和CONNECT PDU中SSAP會不一緻。
此時分兩種情況：
Case1：發送端收到CC PDU，但未收到CONNECT的ACK時：
I. CC中DSAP和CONNECT中SSAP相等
*初始化V(S),V(R),V(SA),V(RA)為0
*處理CC PDU中的參數
*進入資料傳輸階段
II. CC中DSAP和CONNECT中SSAP不相等
*直接放棄連接配接
Case2：接收端收到CONNECT PDU時：
I. 無法處理時，傳回DM PDU
II. 可處理時
*處理CONNECT PDU中的參數
*通知上層，并等待上層接收或者拒絕
>拒絕時，直接放棄連接配接，并發送DM
>接受時，發送CC PDU，V(S),V(R),V(SA),V(RA)為0并開始資料傳輸
需要注意的是，在資料傳輸階段，任何的CONNECT/CC PDU都會被認為是Invalid。
3.6 服務發現（Service Discover）
SDREQ一般是出現在SNL PDU中。收到SDREQ後，需要先判斷Service Name是否有注冊，注冊過則回複SDRES，其中含有效SAP及TID，未注冊時，回複SDRES中SAP為全0。
以上是該Spec大緻的内容，基本上可以涵蓋Android NFC中LLCP的流程。如果有描述不正确的地方，也歡迎大家指正，感謝。