RFCOMM協議概覽
協議淺述
RFCOMM協議基於L2CAP協議的串行(9針RS-232)仿真。最新規範是V12，支持在兩個藍牙設備間高達60路的通信連接。該協議基於ETSI標準GSM 07.10，但不包含全部規範相反，只使用了GSM 07.10標準的一個子集。本文檔中指定了該協議的一些修改，此外，還增加了RFCOMM特定的擴展，使其能夠強制支持流控。
RFCOMM的目的是覆蓋使用其所在設備的串行端口的應用程序，該規範支持兩種設備類型的存在：
Type 1: DTE, 設備本身就是通信終端(如計算機，打印機)
在簡單的配置下，通信段是一個從一個設備到另一個設備的藍牙鏈接，如下圖：
Type 1: DTE, 設備本身就是通信終端(如計算機，打印機)
在簡單的配置下，通信段是一個從一個設備到另一個設備的藍牙鏈接，如下圖：
Type 2: DCE, 通信節點(調制解調器)
當作爲通訊節點使，其中通信段是另一個網絡，藍牙無線技術用於設備和網絡連接設備(如調制解調器)之間的路徑。RFCOMM只關心直接連接情況下設備之間的連接，或者網絡情況下設備與調制解調器之間的連接。RFCOMM可以支持其他配置，比如在一端通過藍牙無線技術通信的模塊，在另一端提供有線接口。但是設備並不是真正的調制解調器，而是提供類似的服務。如下圖所示：
服務概述
如果通過RFCOMM服務接口爲特定端口設置波特率，則不會影響RFCOMM中的實際數據吞吐量;即RFCOMM不會導致人爲的速率限制或節奏。但是，如果其中一個設備是類型2的設備(將數據中繼到其他媒體)，或者如果數據踱步在RFCOMM服務接口的任何一端或兩端進行，實際吞吐量平均將反映波特率設置
RS-232控制信號
RFCOMM模擬了9針RS-232接口，如下所示
無調制解調器仿真
當傳遞非數據通路的狀態信息時，不區分DTE和DCE設備， 而用控制信號來代替相應的信號，對應關係如下圖：
GSM 07.10傳輸RS-232控制信號的方式創建了一個隱式零調制解調器，當兩個同類設備(如DTE)互聯時，GSM 07.10傳輸控制信號時就會創建零調制解調器。下圖顯示了通過RFCOMM連接兩個DTE時創建的Null Modem ：
多串口仿真
兩個使用RFCOMM通信的藍牙設備可以同時打開多個串口仿真 ，RFCOMM支持最多60路，但是一個設備實際能打開的數據依實現而定，具體情況如下圖所示：
個數據鏈接標識(DLCI: 參考幀格式Address字段D+ServerChannel)標識一對客戶和服務器之間的持續連接 。DLCI在兩個設備間的RFCOMM會話中保持一致，中其可用值區間爲2~61，0爲控制信道 ，1由於服務器信道概念不能使用 ， 62-63保留。具體請參《3GPP TS 07.10 V7.2.0》第5.6節。
在一次RFCOMM會話中，客戶和服務器可以分佈在通信的兩端，每一端的客戶都可以獨立發起建立通信連接 因此可使用RFCOMM服務器信道的概念將DLCI值域空間在兩個正在進行通信的設備間進行劃分
如果藍牙設備支持多串口仿真，同時通信連接兩端允許使用不同BT設備
那麼RFCOMM實體必須能夠運行多路複用會話，每個多路複用使用L2CAP信道標識符(CID)來區分，如下圖所示
RFCOMM幀類型
RFCOMM支持的幀(Frame)類型如下：
GSM 07.10 幀類型還有UI不能被RFCOMM所支持，對每個幀具體的意義請參考《3GPP TS 07.10 V7.2.0》5.3節或《3GPP TS 07.10 中文版》第3.3節。
RFCOMM幀格式
RFCOMM幀格式如下所示
Address字段
Address字段如下圖所示，在GSM07.10和RFCOMM中有所區別：
EA(Extern Address)字段: 當爲1時，表示沒有額外的地址段。
C/R(Command/Response)字段: 表示該幀是一個Command還是Response,設置方式如下圖所示 ：
DCLI（或direction bit and server channel）, 通常initator將D位(即最低位)設置爲1，而Responser則將其設置爲0 ，故initator的DCLI的值總是基數(3,5,7,…,61)，而Responser則爲偶數(2,4,6,…,60)
Control字段
Control字段用來標識幀的類型，下圖是相關值
其中，P/F是Poll/Final位，在Commands中，被稱爲P位；而在Responses中則被稱爲F位 。當發送的Command需要一個相應時，就將P置1，接收方收到這樣的命令時需要馬上響應並將F置1 。如果接收到P/F位置爲0的SABM或DISC幀，接收方將把它們丟棄
Length字段
Length字段由最低位的EA來決定其長度
當EA爲1時，長度爲7bits(0~127)
當EA爲0時，長度爲15bits(0~32767)
其中，RFCOMM幀的默認長度爲127，最大長度爲32767
Data字段
Data字段僅僅在UIH幀中存在，其長度限制由L2CAP的MTU所限制
FCS字段
用於接收方校驗接收數據是否正確，校驗原理採用循環冗餘校驗CRC-8
對於SABM,DISC,UA和DM幀，FCS計算Address,Control and Length字段 對於UIH幀，FCS計算Address and Control字段
RFCCOMM協議數據分析
下面我們將對RFCOMM完整的一次建立過程進行數據分析。
以下藍色爲hci部分、綠色爲l2cap部分、紅色爲RFCOMM部分，這裏我只針對RFCOMM協議進行解析，如果你對其他協議有興趣，可以去看我的其他協議的數據分析
1、Master：SABM(Frame Type)
00000010 00000010 00100000 00001000 00000000 00000100 00000000 11000000 00000000 00000011 00111111 00000001 00011100
Address：000000 1 1（此字段可以分爲三部分，根據下圖所描述，有兩種結構，一種是GSM 07.10結構，一種爲藍牙RFCOMM結構）
{
DLCI：00000 0
{
D：0（當爲RFCOMM時爲1，其他都爲零）
Server Channel：00000（0x00，服務通道爲0）
}
Command/Response（C/R）：1（Initiator Started C/R Sequence）
Extension Bit(EA)：1（Not Extended）
}
Frame Type：00111111（根據下表可知爲SABM(Set Async Balanced Mode)）
{
Poll/Final Bit（P/F）: 1（bit-4位，當建立Data Link Connection(DLC)時，一般是由TE(Terminal Equipment )發起發送一個SABM，並將該位（Poll）置一，MS(Mobile Station) 確認連接時回覆的UA(Unnumbered Acknowledgement)包的該位（Final）也應該被置一）
}
Length：0000000（0x00，數據長度爲0）
Extension Bit(EA)：1（沒有額外的字節描述數據長度）
FCS：00011100（0x1c，冗餘校驗）
2、Slave：UA
00000010 00000010 00100000 00001000 00000000 00000100 00000000 01000011 00000000 00000011 01110011 00000001 11010111
Address：00000011（此字段可以分爲三部分，解析如下）
{
DLCI：00000 0
{
D：0（當爲RFCOMM時爲1，其他都爲零）
Server Channel：00000（0x00，服務通道爲0）
}
Command/Response（C/R）：1（Initiator Started C/R Sequence）
Extension Bit(EA)：1（Not Extended）
}
Length：0000000（0x00，數據長度爲0）
Extension Bit(EA)：1（沒有額外的字節描述數據長度）
FCS：11010111（0xd7，冗餘校驗）
3、Master：UIH
00000010 00000010 00100000 00010010 00000000 00001110 00000000 11000000 00000000 00000011 11101111 00010101 10000011 00010001 00000010 11110000 00000000 00000000 00000000 00000001 00000000 00000111 01110000
Address：000000 1 1（此字段可以分爲三部分）
{
DLCI：00000 0
{
D：0（當爲RFCOMM時爲1，其他都爲零）
Server Channel：00000（0x00，服務通道爲0）
}
Command/Response（C/R）：1（Initiator Started C/R Sequence）
Extension Bit(EA)：1（Not Extended）
}
Frame Type：11101111（查表可知爲UIH(Unnumbered Info with Header Check)）
{
Poll/Final Bit（P/F）: 0（bit-4位）
}
Length：0001010（0x0a，數據長度爲10）
Extension Bit(EA)：1（沒有額外的字節描述數據長度）
UIH Command/Response：（多路控制通道消息的格式如下：）
Type的格式如下圖所示：
當EA爲1時表示這是最後一個字節，當爲0時則表示有擴展的字節表述，如下圖：
T位代表類型編碼，編碼與命令的對應關係如下圖所示：
Type：10000011
Command：100000（0x20，查表可知爲PN命令）
Command/Response(C/R)：1（Command）
Extension Bit(EA): 1（Not Extended）
Length字段格式如下：
當EA爲1時表示這是最後一個字節，當爲0時則表示有擴展的字節
Length：00010001
Length：0001000（0x08，value的長度爲8）
Extension Bit(EA): 1（Not Extended）
Value根據不同的命令有不同的描述，在《3GGP TS 07.10 中文版》第3.4.6.3節有詳細介紹，則此處爲PN的值的描述，如下圖：
具體參數介紹，請參考《3GGP TS 07.10 中文版》第3.4.6.3.1節
Value：
DLCI(D)：000010（0x02，協商數據傳輸的DLCI）
Credit Based Flow Control(CL)：1111（0x0f，Sender Supports CFC）
Type of Frame for Information(I)：0000（0x0，UIH Frames）
Priority(P)：000000（0x0，優先級爲0，0爲最低優先級）
Acknowledgement Timer(T)：0（0x0，等待確認時間爲0）
Maximum Frame Size(N)：00000000 00000001（0x0100，最大幀大小爲256）
Maximum Number of Retransmission(NA)：00000000（0x0，最大重發次數爲0）
Credits(K)：111（0x07，窗口大小，即幀數量的的最大值，此處設置爲7）
FCS：01110000（0x70，冗餘校驗）
UIH Command/Response：
Type：10000011
Command：100000（0x20，查表可知爲PN命令）
Command/Response(C/R)：1（Command）
Extension Bit(EA): 1（Not Extended）
Length：00010001
Length：0001000（0x08，value的長度爲8）
Extension Bit(EA): 1（Not Extended）