Bluetooth Low Energy プロトコル スタックを理解する

学習目的 : なぜ BLE プロトコル スタックを階層化する必要があるのですか? BLEの「接続」をどう理解するか？ATTは何に使用されますか? ガットはどうですか？BLE プロトコルに ATT 層のみがあり、GATT 層がない場合はどうなりますか?

1.プロトコルスタックフレームワーク

一般に、特定のプロトコルの実装コードをプロトコル スタックと呼びます。BLE プロトコル スタックは、Bluetooth Low Energy プロトコルを実装するコードです。BLE プロトコル スタックを実装するには、BLE プロトコルを理解して習得することが前提条件です。BLE プロトコル スタックのさまざまなコンポーネントを詳しく説明する前に、まず BLE プロトコル スタックの全体的なアーキテクチャを見てみましょう。BLE プロトコル スタックは主に、アプリケーション データをレイヤーごとにパッケージ化し、

エア データ パケットを生成するために使用されます。 BLE プロトコルを満たす、つまり、アプリケーション データを一連のヘッダーと末尾で包みます。具体的には、BLE プロトコル スタックは主に次の部分で構成されます。

1. PHY 層: PHY 層は、BLE で使用される無線周波数帯域、変調および復調方式などを指定するために使用されます。
   - LL 層: LL 層は、BLE プロトコル スタック全体の中核であり、BLE プロトコル スタックの難しさと焦点でもあります。 BLE プロトコル スタック LL 層はデータの転送のみを担当します データが送信されるか受信されるかにかかわらず、データの分析方法は上記の GAP または GATT に任されます。
2. HCI 層: HCI は主に、2 つのチップが BLE プロトコル スタックを実装し、2 つのチップ間の通信プロトコルと通信コマンドを標準化する場合に使用されます。
3. L2CAP 層: L2CAP は、暗号化チャネルか通常チャネルかを区別し、接続間隔も管理する必要があります。
4. SMP レイヤー: SMP は、BLE 接続の暗号化とセキュリティを管理するために使用されます。
5. ATT 層: ATT 層は、特定のデータの読み取りや特定のデータの書き込みなど、ユーザー コマンドとコマンド操作データを定義するために使用されます。BLE プロトコル スタックでは、開発者が ATT に最もさらされています。BLE では、データを 1 つずつ記述するために属性の概念が導入されています。データの定義に加えて、属性ではデータで使用できる ATT コマンドも定義します。
6. GATT 層: GATT は、属性のデータ内容を標準化し、グループの概念を使用して属性を分類および管理するために使用されます。
7. GAP 層: GAP は、デバイスの検出、リンクの確立、構成およびセキュリティ設定を含む、2 つの Bluetooth リンクの基本操作を説明します
   注: アプリケーション層を作成する場合、ATT 層と GATT 層がよく使用されます。

2. データパケットの送信方法

デバイス A とデバイス B があるとします。デバイス A は、現在の電力ステータスの 83% (16 進表記で 0x53) をデバイス B に送信したいと考えています。これはどのように行うべきでしょうか? 開発者として、彼はシンプルであるほど良いことを望んでいます。彼の場合、send(0x53) などのタスクを完了するために単純な API を呼び出したいと考えています。実際、私たちの BLE プロトコル スタックはこのように設計されています。 send(0x53) を呼び出してデータを送信するだけで済み、残りは BLE プロトコル スタックが処理します。では、BLE は何を処理するのでしょうか? ここで紹介する主な方法は次の 2 つです。

ブロードキャストモード

まず簡単なブロードキャストの状況を見てみましょう この場合、デバイス A を広告主 (ブロードキャスター) と呼び、デバイス B をスキャナーまたはオブザーバー (スキャナー) と呼びます。ブロードキャスト状態では、デバイス A の LL 層 API は send_LL(0x53,2402M, 0x8E89BED6) になります。デバイス B は多くのデバイスから同時にブロードキャストを受信できるため、データ パケットにはデバイス A のデバイス アドレス (0xE1022AAB753B) も含まれ、ブロードキャスト パケットがデバイス A からのものであることを確認する必要があります。この目的のために、send_LL パラメータは次のようにする必要があります。 (0x53,2402M、0x8E89BED6、0xE1022AAB753B)。LL 層では、データの完全性、つまり送信中にデータが改ざんされていないかどうかもチェックするため、データ パケット (0xB2C78E とする) をチェックするために CRC24 が導入されています。同時に、変復調回路をより効率的に動作させるために、各データ パケットの先頭に 1 バイトのプリアンブル (プリアンブル フレーム) が追加されます (通常、プリアンブルは 0x55 または 0xAA)。このようにして、エア パッケージ全体は次のようになります (注: エア パッケージはリトル エンディアン モードで表現されています!)

。実際、上記のデータ パケットには何か問題があります。

1. データパケットの分類と編成がない、デバイス B は必要なデータ 0x53 を見つけることができません。このためには、アクセス アドレスの後に LL ヘッダーと長さバイトの 2 つのフィールドを追加する必要があります。LL ヘッダーはデータ パケットの LL タイプを示すために使用され、長さバイトはペイロードの長さを示すために使用されます。
2. デバイス B はいつ無線パケットを受信するために RF ウィンドウを開きますか? 上記のケース 1 に示すように、デバイス A のデータ パケットが無線で送信されると、デバイス B は受信ウィンドウを閉じ、この時点で通信は失敗します。同様に、デバイス A がデータ パケットを無線で送信しない場合、ケース 2 の場合も同様です。 , デバイスB 受信ウィンドウを開くと、この時点でも通信は失敗します。ケース 3 の場合のみ、つまり、デバイス A のデータ パケットが空中に送信され、デバイス B がたまたま無線周波数の受信ウィンドウを開き、この時点で通信が成功する可能性があります。通信のタイミングも定義する必要があります。
3. デバイス B がデータ 0x53 を取得した場合、このデータをどのように解析する必要がありますか? それは湿気、電気、または他の何かを意味しますか？これは、GAP 層が行う必要があることです。GAP 層は、020105、02-length、01-type (ブロードキャスト フラグを示す必須フィールド、ブロードキャスト パケットの必須フィールド) などのデータを定義するための LTV (長さ-タイプ-値) 構造を導入します。このフィールドが含まれます )、05-値。ブロードキャストパケットは最大31バイトまでしかないため、定義できるデータの種類は非常に限られており、例えばここで言う電力はGAPで定義されていないため、電力データをブロードキャストで送信するには以下の方法しかありません。サプライヤーのカスタマイズを使用します。データ型は 0xFF、つまり 04FF590053 で、04 は長さを表し、FF はデータ型 (カスタム データ) を表し、0x0059 はサプライヤー ID (カスタム データの必須フィールド)、0x53 は当社のデータ (両当事者は、0x53 が他の意味ではなく電力を表すことに同意します)。

無線で送信される最終データ パケットは次のようになります。
AAD6BE898E600E3B75AB2A02E102010504FF5900538EC7B2
AA – プリアンブル (プリアンブル)
D6BE898E – アクセス アドレス (アクセス アドレス)
60 – LL ヘッダー フィールド (LL ヘッダー)
0E – 有効データ パケット長 (ペイロード長)
3B75AB2A02E1 – ブロードキャスター デバイス アドレス(広告主アドレス)
02010504FF590053 – ブロードキャスト データ
8EC7B2 – CRC24 値

PHY、LL、および GAP を使用すると、広告パケットを送信できますが、ブロードキャスト パケットによって伝送される情報は非常に限られており、いくつかの大きな制限があります。

1. 1対1の双方向通信はできません（ブロードキャストは1対多の通信となり、片方向の通信となります）
2. 梱包・開梱には対応していないため、大きなデータは転送できません
3. 通信の信頼性が低く、非効率的です。ブロードキャスト チャネルが多すぎてはなりません。そうしないと、スキャン側の効率が低くなります。このため、BLE はブロードキャストとスキャンに 37 (2402MHz) / 38 (2426MHz) / 39 (2480MHz) の 3 つのチャネルのみを使用するため、ブロードキャストは周波数ホッピングをサポートしません。ブロードキャストは 1 対多であるため、ブロードキャストは ACK をサポートできません。これらにより、ブロードキャスト通信の信頼性が低くなります。
4. スキャン側の消費電力は大きいです。スキャナは、デバイスがいつブロードキャストするのか、またデバイスがどのチャネルをブロードキャストに選択するのかを知らないため、スキャナはスキャン ウィンドウ時間を延長し、3 つのチャネル 37/38/39 を同時にスキャンすることしかできません。消費量は減少しますが、相対的に高くなります。

この接続は上記の問題をうまく解決します。接続がどのように 0x53 を送信するかを見てみましょう。

接続モード

つながりとは正確には何ですか? 有線 UART と同様に、デバイス A とデバイス B に有線 (Rx と Tx など) で接続されていることが理解しやすいです。「回線」を使用して 2 つのデバイスを接続すると、実際には 2 つのデバイスが共通の通信媒体を使用してクロックを同期できるようになります。これは Bluetooth 接続にも当てはまりませんか? デバイス A とデバイス B の間でいわゆる Bluetooth 接続が確立されるということは、デバイス A とデバイス B が 1 対 1 で正常に「同期」されることを意味し、これには具体的には次の側面が含まれます。

• デバイス A とデバイス B が次に使用する物理チャネルに同意します

• デバイス A とデバイス B は両方とも共通の時間アンカー ポイントを確立します。つまり、両方の当事者の時間原点を同じポイントに変更します。

• デバイス A とデバイス B のクロックは正常に同期されています。つまり、どちらの当事者も相手がいつデータ パケットを送受信するかを知っています。

• 接続が成功した後のデバイス A とデバイス B 間の通信プロセスは次のようになります。

上図に示すように、デバイス A とデバイス B が正常に接続されると (この場合、デバイス A をマスターまたはセントラルと呼び、デバイス B をスレーブまたはペリフェラルと呼びます)、デバイス A は定期的に CI (接続間隔) データを使用します。パケットは CI 間隔でデバイス B に送信され、デバイス B も CI 間隔で定期的に無線周波数受信ウィンドウを開き、デバイス A からデータ パケットを受信します。同時に、Bluetooth 仕様要件によれば、デバイス B がデバイス A からデータ パケットを受信して​​から 150us 後に、デバイス B は送信状態に切り替わって自身のデータをデバイス A に送信し、デバイス A は受信状態に切り替わってデータを受信します。デバイスBから送信されたデータ。接続状態では、デバイス A とデバイス B の無線周波数送受信ウィンドウが計画的に定期的にオン/オフされ、オン時間が非常に短いため、システムの消費電力が大幅に削減され、大幅に節約されることがわかります。システム効率の向上。

ここで、接続状態でデータ 0x53 がどのように送信されるかを見てみましょう。これにより、誰でも Bluetooth プロトコル スタックの階層構造の美しさを理解できるでしょう。

• 開発者にとっては非常に簡単で、send(0x53) を呼び出すだけです。
• GATT 層はデータのタイプとグループを定義します。便宜上、電気のデータ タイプを表すのに 0x0013 を使用します。これにより、GATT 層はデータを 130053 (リトル エンディアン モード!) にパッケージ化します。
• ATT 層は、読み取り/書き込み/通知/表示などの特定の通信コマンドを選択するために使用されます。ここでは、通知コマンド 0x1B が選択されているため、データ パケットは次のようになります。
• L2CAPは接続間隔（接続間隔）を指定するため、例えば10msごとに同期する（CIはデータパケットに反映されない）、論理チャネル番号0004（ATTコマンドを示す）を指定し、最後にATTデータを追加します。パケットヘッダーに長さ 0x0004 を追加すると、データは 040004001B130053 になります。
• LL 層にはやるべきことがたくさんあります。まず、LL 層は送信に使用する物理チャネル (物理チャネルはデータ パケットには反映されません) を指定し、これにアクセス アドレス (0x50655DAB) を割り当てる必要があります。サービスをデバイス B に直接接続し、LL ヘッダーとペイロード長フィールドを追加します。LL ヘッダーは、このパケットが制御パケットではなくデータ パケットであることを識別します。ペイロード長は L2CAP フィールド全体の長さであり、最後に CRC24 フィールドを追加してパケット全体のデータ整合性を確保するため、データ パケットは最終的に次のようになります。
• AAAB5D65501E08040004001B130053D550F6
• AA – プリアンブル
• 0x50655DAB – アクセスアドレス
• 1E – LL ヘッダー フィールド (LL ヘッダー)
• 08 – ペイロードの長さ
• 04000400 – ATT データ長および L2CAP チャネル番号
• 1B – 通知コマンド
• 0x0013 – 電力データハンドル
• 0x53 – 送信される実際の電力データ
• 0xF650D5 – CRC24 値
  開発者は send(0x53) を呼び出しただけですが、低電力 Bluetooth プロトコル スタックのレイヤーごとのパッケージ化により、実際に空中で送信される最終データは次の図のようになります。低電力の要件を満たします。 Bluetooth 通信の必要性により、ユーザー API がシンプルになります。
  
  参照:
  [1]: https://www.cnblogs.com/iini/p/8969828.html
  [2]: https://www.cnblogs.com/iini/p/8834970.html
  [3]: https: //www.cnblogs.com/iini/p/12334646.html
  [4]: http://adrai.github.io/flowchart.js/