顕微鏡下での BLE (ATTы GATTы…)

顕微鏡下での BLE (ATTы GATTы…)

パート 1、概要

Bluetooth 4.0 の最初の仕様がリリースされてから、すでにかなり長い時間が経過しました。 また、BLE のトピックは非常に興味深いものですが、その複雑さのため、多くの開発者は依然として先延ばしにしています。 前回の記事では、主に最下位のリンク層と物理層について説明しました。 これにより、属性プロトコル (ATT) や一般属性プロファイル (GATT) などの複雑でわかりにくい概念に頼る必要がなくなりました。 しかし、それを理解しないと対応機器の開発はできません。 今日はこの知識を皆さんと共有したいと思います。 私の記事で私が頼るのは 教科書 Nordicのウェブサイトから初心者向けにアクセスしてください。 それでは始めましょう。

なぜすべてがそんなに難しいのですか？

私の意見では、スマートフォンを介したデバイスの管理は非常に有望で長期にわたるテーマであることはすぐに明らかでした。 したがって、彼らはそれを即座に最大限に構築することに決めました。 そのため、さまざまなガジェットのメーカーが互換性のない独自のプロトコルを開発することはありません。 したがって困難です。 すでに最初の段階で、彼らは可能な限りすべてを BLE プロトコルに詰め込もうとしました。 そして、それが後で役に立つかどうかは関係ありません。 さらに、将来的にデバイスのリストを拡張する可能性も提供されました。

BLE プロトコル図が描かれている図を見てみましょう。 いくつかの層で構成されています。 最下位の物理層 (PHY) は、デバイスの無線チャネルを担当します。 リンク層 (LL) には、送信メッセージ内のバイト シーケンス全体が含まれます。 以前の記事では、まさにこれについて研究しました。 ホスト コントローラー インターフェイス (HCI) は、コントローラーとホストが異なるチップに実装されている場合の BLE レイヤーまたはチップ間の交換プロトコルです。 Logical Link Control and Adaptation Protocol (L2CAP) は、パケットの形成、フレーミング、エラー制御、およびパケットの組み立てを担当します。 Security Manager Protocol (SMP) はパケットの暗号化を担当します。 General Access Profile (GAP) は、「誰が誰なのか」を判断するためのデバイス間の最初のデータ交換を担当します。 スキャンや広告も含まれます。 この記事では、プロトコルの残りの XNUMX つの部分、GATT と ATT に焦点を当てます。 GATT は ATT の上部構造であるため、これらは密接に絡み合っています。

話を簡単にするために、例え話に移りたいと思います。 どこかで聞いたので応援したいと思います。 BLE デバイスを、いくつかの棚がある本棚と考えてください。 各棚には個別のテーマがあります。 たとえば、SF、数学、百科事典の棚があります。 各棚には、指定されたトピックの本が置かれています。 また、本によってはメモが書かれた紙のしおりが付いていることもあります。 さらに、すべての書籍をまとめた小さな紙のカタログもあります。 覚えていると思いますが、学校図書館は紙のカードが入った狭い箱です。 この例えで言えば、キャビネットはデバイスのプロファイルです。 棚はサービス、本は特性、カタログは属性テーブルです。 ブック内のブックマークは記述子であり、これについては後ほど詳しく説明します。

デバイスを開発したことがある人なら誰でも、多くのプロジェクトに同様のコードが含まれていることを知っています。 実際、多くのデバイスが同様の機能を備えています。 たとえば、デバイスがバッテリーで駆動されている場合、充電とそのレベルの監視の問題は同じになります。 センサーについても同様です。 実は、プログラミングに対するオブジェクト指向のアプローチ 「プロパティと動作を自己完結型のユニオンに結合し、再利用できるオブジェクトを作成する機能を提供します。」。 私の意見では、BLE も同様のアプローチを試みました。 プロファイルは Bluetooth Special Interest Group (SIG) によって開発されました。 同じプロファイルを持つ異なるメーカーのデバイスは、問題なく相互に動作するはずです。 プロファイルは、サービスと、記述子によって補足された特性のサービスで構成されます。 一般的には次のようになります。

たとえば、心拍数モニター (フィットネス ブレスレット) のプロファイル図を考えてみましょう。 これは XNUMX つのサービスといくつかの特徴で構成されます。 そこから、プロファイルの階層がすぐに明らかになります。 チェックポイント特性により、総消費カロリー数がゼロにリセットされます。

1. 心拍数サービスには 0 つの特性 (180xXNUMXD) が含まれます。
    a) 必須の心拍数特性 (0x2A37)
    b) オプションのボディセンサー位置特性 (0x2A38)
    c) 心拍数制御ポイント (0x2A39) の条件特性
2. バッテリー保守サービス (0x180F):
    a) 必須のバッテリー充電レベル特性 (0x2A19)

UUID

プロファイル要素 (サービス、特性、記述子) に一意にアクセスするには、何らかの方法ですべてに番号を付ける必要があります。 この目的のために、Universally Unique ID (UUID) や Universally Unique Identifier などの概念が導入されます。 UUID は各行の括弧内に示されています。 そしてここには一つの特徴があります。 UUID については、長さ 16 ビットと 128 ビットのコードを使用することにしました。 なぜ聞くの？ BLE プロトコルでは、すべてが省エネです。 したがって、16 ビットのサイズは非常に合理的です。 近い将来、65 を超える数が作成される可能性は低いです。 ユニークなサービスと特徴。 現時点では、数えられるものはすべてすでに数えられています (これがどこから来たのか覚えておいてください - 「彼はあなたも数えました」:-)) 番号付きの要素 プロフィール, サービス, 特性 и 記述子 リンクを見ることができます。

しかし、インターネット上の 4 バイトの IP アドレスの話を誰もが覚えていると思います。 最初はこれで十分だと思っていましたが、今ではまだ 6 バイトのアドレスに切り替えることができません。 この間違いを繰り返さず、DIY ユーザーの遊び心に自由を与えるために、SIG はただちに 128 ビット UUID の導入を決定しました。 これは個人的に、無線チャンネルからあらゆる種類のクリビンに与えられた無認可の 433 MHz 帯域を思い出させます。 私たちの場合、サービスと特性の 128 ビット識別子が抽出されました。 これは、サービスやデバイスでほぼすべての 128 ビット値を使用できることを意味します。 それでも、同じ UUID が見つかる確率はゼロになる傾向があります。

実際、短い 16 ビット UUID には 128 ビット値への拡張があります。 仕様では、この拡張子は Bluetooth Base UUID と呼ばれ、値は 00000000-0000-1000-8000-00805F9B34FB です。 たとえば、16 ビット属性 UUID の値が 0x1234 である場合、同等の 128 ビット UUID の値は 00001234-0000-1000-8000-00805F9B34FB になります。 そして、対応する式も与えられます。

                                128 ビット値 = 16 ビット値 * 2^96 + Bluetooth_Base_UUID

この魔法の数字がどこから来たのかはわかりません。 読者の中に知っている人がいたら、コメントに書き込んでください (Sinopteek というニックネームのユーザーがすでにこれを行っています。コメントを参照してください)。 128 ビット UUID の取得に関しては、原則として特別な UUID を使用できます。 発電機誰があなたのためにやってくれるのでしょう。

アッティガッティ...

実際、そこから楽しいことが始まります。 ATT はクライアントとサーバーの関係に基づいていることを思い出してください。 次に、サーバーデバイスに注目します。 センサー値、照明スイッチの状態、位置データなどの情報が含まれます。 すべての「パレードの参加者」に番号が付けられたので、何らかの方法でそれらをデバイスのメモリに配置する必要があります。 これを行うために、属性テーブルと呼ばれるテーブルにそれらを配置します。 これをよく覚えておいてください。 これはまさに BLE の核心です。 これについてはさらに検討していきます。 ここで、各行を属性と呼びます。 このテーブルはスタックの奥深くに位置しており、原則として、テーブルに直接アクセスすることはできません。 私たちはそれを初期化してアクセスしますが、内部で何が起こっているかは XNUMX つの封印の背後に隠されています。

仕様から全体像を見てみましょうが、その前に、用語、つまり記述子において頻繁に混同されている点にすぐに注意を喚起したいと思います。 記述子の役割は、特性の説明を補完することです。 機能を拡張する必要がある場合は、記述子が使用されます。 これらは属性でもあり、サービスや特性と同様に、属性テーブルに配置されます。 記事の後半で詳しく見ていきます。 ただし、記述子が属性テーブルの行番号を参照する場合があります。 このことを念頭に置いておかなければなりません。 混乱を避けるために、これらの目的には「属性ポインター」という用語を使用します。


したがって、属性は、次のプロパティが関連付けられた個別の値です。
1. 属性ハンドルは、属性に対応するテーブル インデックスです。
2. 属性タイプは、そのタイプを説明する UUID です。
3. 属性値は、属性ポインタによってインデックス付けされたデータです。
4. 属性パーミッションは属性の一部であり、属性プロトコルを使用して読み書きすることはできません。

これらすべてをどうやって理解すればよいでしょうか？ 属性ポインタは、相対的に言えば、テーブル内のその番号です。
これにより、クライアントは読み取りまたは書き込みリクエストで属性を参照できるようになります。 行 (属性) には 0x0001 から 0xFFFF までの番号を付けることができます。 本棚との関係では、これは紙のカタログのカード番号です。 同様に、図書館カタログと同様に、カードは番号の昇順に配置されます。 後続の各行の番号は、前の行の番号より大きくなければなりません。 図書館と同じように、時々カードが失われることがあるので、私たちの場合、行番号にギャップが生じる可能性があります。 これは許可されています。 重要なことは、それらは徐々に進むということです。

属性タイプによって、属性が何を表すかが決まります。 C言語から類推すると、
ここにはブール値、数値変数、文字列があるため、ここにあります。 認識される属性タイプごとに
私たちが何に取り組んでいるのか、そしてどのようにしてこの属性を扱い続けることができるのか。 以下では、いくつかの特定の種類の属性を見ていきます。 例えば、「サービス宣言」(0x2800)、「特性宣言」(0x2803)、「記述子宣言」(0x2902)。

属性の値は、同語反復を許してください、その実際の意味です。 属性タイプが文字列の場合、属性値は、たとえばスローガン「Hello World !!!」になります。 属性タイプが「サービス宣言」の場合、その値はサービス自体です。 また、これは他の属性とそのプロパティを見つける場所に関する情報である場合もあります。

属性のアクセス許可により、サーバーは読み取りまたは書き込みアクセスが許可されているかどうかを認識できます。
これらのアクセス許可は属性値にのみ適用され、ポインター、タイプ、またはアクセス許可フィールド自体には適用されないことに注意してください。 それらの。 属性の記録が許可されている場合は、たとえば「Hello World !!!」という行を変更できます。 「おはよう」のラインに。 ただし、改行を禁止したり、属性の型を変更してその行を「サービス宣言」とすることはできません。 クライアントがサーバーに接続すると、クライアントはその属性を要求します。 これにより、クライアントはサーバーが何を提供できるかを知ることができます。 ただし、値を読み書きする必要はありません。

それがどのようなものか

GATT の概念は、属性テーブル内の属性を非常に具体的かつ論理的な順序でグループ化することです。 以下の心拍数プロファイルを詳しく見てみましょう。 この表の左端の列はオプションです。 これは、この行 (属性) が何であるかを単に説明しているだけです。 他のすべての列はすでによく知られています。

各グループの先頭には常にサービス宣言属性があります。 そのタイプは常に 0x2800 で、ポインターはテーブル内にすでに存在する属性の数によって異なります。 その権限は常に読み取り専用であり、認証や許可はありません。 これらの概念については後ほど説明します。 値は、サービスが何であるかを識別する別の UUID です。 表では、値は 0x180D で、Bluetooth SIG によって心拍数サービスとして定義されています。

サービスの発表に続いて、特徴の発表。 形式的にはサービス宣言に似ています。 その UUID は常に 0x2803 で、そのアクセス許可は認証や承認なしで常に読み取り専用です。 いくつかのデータを含む属性値フィールドを見てみましょう。 これには常に、ポインター、UUID、および一連のプロパティが含まれます。 これら XNUMX つの要素は、その後の特性値の宣言を記述します。 ポインタは当然、属性テーブル内の特性値宣言の位置を示します。 UUID は、どのような種類の情報または値が期待できるかを示します。 たとえば、温度値、照明スイッチの状態、またはその他の任意の値です。 そして最後に、特性値をどのように操作できるかを記述するプロパティです。

ここでまた別の落とし穴が待っています。 これは、属性権限と特性プロパティに関連付けられています。 仕様のビット フィールド プロパティの図を見てみましょう。

ご覧のとおり、ここには読み取りおよび書き込み機能を提供するフィールドもあります。 なぜ属性とプロパティに対する読み取り/書き込み権限があるのか​​疑問に思われるかもしれません。
特性値の読み取り/書き込み? それらは常に同じであるべきではないでしょうか? 実際のところ、特性値のプロパティは、実際には GATT 層およびアプリケーション層で使用されるクライアントに対する推奨にすぎません。 これらは、クライアントが特性宣言属性から何を期待するかについての単なるヒントです。 これをさらに詳しく見てみましょう。 属性にはどのような種類の権限がありますか?

1. アクセス許可:
     - 読む
     - 記録
     - 読み書き
2. 認証許可:
     - 認証が必要です
     - 認証は必要ありません
3. 認可権限：
     - 認証が必要です
     - 許可は必要ありません

属性解決と特性プロパティの主な違いは、前者はサーバーに適用され、後者はクライアントに適用されることです。 サーバーは特性値の読み取りを許可されている場合がありますが、認証または許可が必要な場合があります。 したがって、クライアントが特性のプロパティをリクエストすると、読み取りが許可されることを受け取ります。 しかし、読み取ろうとするとエラーが発生します。 したがって、プロパティに対するアクセス許可の優先順位については、安全に議論できます。 クライアント側では、属性にどのような権限があるかについての情報を取得できません。

ディスクリプタ

テーブルに戻りましょう。 特性の値を宣言した後、次の属性宣言が可能になります。
1. 特性の新しい宣言 (サービスは多くの特性を持つことができます)
2. 新しいサービス宣言 (表には多数のサービス宣言が含まれる可能性があります)
3. ハンドルの宣言

心拍数測定特性の場合、この表では、特性値の宣言に記述子の宣言が伴います。 記述子は、特性に関する追加情報を含む属性です。 記述子にはいくつかの種類があります。 それらについては、この記事の後半で詳しく説明します。 ここでは、Client Characteristic Configuration Descriptor (CCCD) についてのみ触れます。 UUID は 0x2902 です。 この記述子を使用すると、クライアントはサーバー上での表示または通知を有効にすることができます。 それらの差は小さいですが、それでも存在します。 通知にはクライアントからの受信確認は必要ありません。 表示にはこれが必要ですが、GATT レベルで発生し、アプリケーション レベルには達しません。 なぜそうなるのですか？ ああ、これはわかりません。 北欧の専門家は通知の使用を推奨しているとだけ言っておきます。 さらに、どちらの場合でも、パッケージの整合性のチェック (CRC を使用) が行われます。

まとめ

記事の最後にこれを言いたいと思います。 最後の表は少しわかりにくいです。 しかし、与えられたのでそれを選びました статье私が頼りにしているもの。 記事の後半では、BlueTooth 4.0 仕様をさらに詳しく掘り下げる予定です。 そこではより正確な図や図面が私たちを待っています。 XNUMX 番目のパートでは、ガジェットの XNUMX つから Wireshark プログラムを使用して取得したログを解析し、研究しているすべての理論を「ライブ」で確認したいと思います。

グループ企業の従業員 「シーザーサテライト」
ペチェルスキフ・ウラジミール

出所： habr.com