ディレクトリ
RFCOMMプロトコルの概要
簡単な説明プロトコル
RFCOMMのプロトコルベースのL2CAP プロトコルシリアル（9 -pin RS-232）シミュレーション。最新の仕様は、V12 の間に2つのBluetoothデバイスまでサポート、60本の通信リンク道路。プロトコルは基づいているETSI 標準GSM 07.10 （文書はネットワークディスク）の私（序文で見つけることができます）、しかし、その代わりのみすべての仕様が含まれていないGSM 07.10 サブセットの標準を。この文書では、いくつかの変更とプロトコルを指定し、加えて、増加したRFCOMM フロー制御をサポートするように強制することができ、特定の拡張子を。
RFCOMMは、2つのタイプのデバイスがあり、仕様をサポートするシリアルポートデバイスへの応用、の使用をカバーすることを意図しています。
タイプ1：DTE、デバイス自身が通信端末である（コンピュータなど、プリンタ）
簡単な構成では、通信は、別のデバイスへのデバイスからのセグメントである以下に示すように、ブルートゥースリンクです。
タイプ2：DCE、通信ノード（モデム）
通信ノードが有効になっている場合、通信部は、デバイスとネットワーク接続装置のための別のネットワーク、ブルートゥース無線技術である（モデムなど）との間の経路。RFCOMMは、接続装置またはモデムデバイスとネットワーク条件との間の接続との間の直接接続を持つ唯一の懸念です。RFCOMMは、他端に有線インタフェースを提供する、Bluetoothワイヤレス技術を介して通信するためにそのようなモジュールの端のような他の構成をサポートすることができます。しかし、デバイスが実際にモデムではなく、同様のサービスを提供します。下図のように：
サービスの概要
経由している場合RFCOMMのサービス特定インターフェイスポートのボーレート、それが影響しませんRFCOMM で実際のデータスループットを、すなわちRFCOMMは、人工またはレート制限リズムが発生することはありません。デバイスの一つのタイプである場合は、2 装置（他のメディアにデータを中継する）、またはペースでデータ場合RFCOMMは、いずれかまたはサービス・インタフェースの両方の、実際の平均スループットは、ボーレートの設定を反映します
RS-232 の制御信号
RFCOMMは、シミュレート9 -pin RS-232 に示すように、インターフェイスを。
いいえモデムエミュレーションません
状態情報は、非データパスを送信する場合、区別しないDTE およびDCEの機器、 以下に示すように、制御信号の代わりに対応する信号、の対応関係：
GSM 07.10 送信RS-232 モード制御信号は、暗黙のヌルモデムを作成し、2台の類似の機器場合（などDTE）相互接続された場合、GSM 07.10は、ときに、送信制御信号作成されるヌルモデム。次の図は、経由示しRFCOMM 二つの接続DTEのときに作成ヌルモデム：
マルチポートシリアルエミュレーション
2つの使用RFCOMM 複数のシリアルエミュレーションを開くことができる通信Bluetoothデバイスを 、RFCOMMは、最大サポート60 -wayが、デバイス下記のように特定の場合に応じて達成するために開くことができる実際のデータによれば：
一个数据链接标识(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）
篇幅原因，上面我只举了前两个协议交互例子进行分析，后续的协议的log以及数据分析，以及相关资料，请到我的博客<蓝牙学习笔记（序）>最下面的网盘链接中下载！
目录