BLEスタック実装の基礎、GATT・GAP・ATTプロファイルの設計と実装方法

Bluetooth Low Energy（BLE）を搭載した製品開発は、IoTデバイスの普及とともに一般的になりました。しかし、試作段階では動いたBLE通信が、いざ製品として量産しようとすると、安定性や消費電力、あるいは法規制への対応で壁にぶつかることは珍しくありません。特に、BLEの通信スタックは、多くの専門用語が並び、その全体像を掴むのが難しいと感じる方もいるでしょう。

このコラムでは、BLEスタックの基礎となるATT、GAP、GATTの各プロファイルの役割と、それらをどのように設計し実装していくかについて、実務的な視点から解説します。

BLE通信の基盤を理解する：ATT、GAP、GATT

BLE通信は、複数のプロトコルやプロファイルが階層的に連携することで成り立っています。その中でも、特に重要なのがATT（Attribute Protocol）、GAP（Generic Access Profile）、GATT（Generic Attribute Profile）の3つです。これらはBLEデバイスが互いに発見し、接続し、データを交換するための基本的な枠組みを提供します。

ATT（Attribute Protocol）の役割

ATTは、BLEデバイス間で属性（Attribute）と呼ばれるデータを読み書きするための基盤となるプロトコルです。すべてのデータは「属性」として表現され、それぞれがユニークなハンドル（識別子）、タイプ（UUID）、値、そしてパーミッション（読み書きの権限）を持ちます。GATTがデータを構造化する上で、ATTはその実体となるデータへのアクセス方法を定義していると理解してください。

GAP（Generic Access Profile）による接続確立

GAPは、BLEデバイスがどのように互いを認識し、通信を開始するかを定義するプロファイルです。デバイスの役割（Central/Peripheral、Observer/Broadcaster）や、アドバタイズ（デバイスの存在を周囲に知らせる）、スキャン（周囲のデバイスを探す）、接続の確立といった手順を定めます。

• Central（セントラル）：スマートフォンやPCなど、他のデバイスに接続を要求する側です。
• Peripheral（ペリフェラル）：センサーやIoTデバイスなど、セントラルからの接続を受け入れる側です。
• Broadcaster（ブロードキャスター）：一方的にデータをアドバタイズするだけで、接続は受け付けません。ビーコンなどがこの役割です。
• Observer（オブザーバー）：ブロードキャスターからのアドバタイズデータを一方的に受信する側です。

製品を開発する際は、まずこのGAPの役割を明確にすることが、その後の設計の出発点になります。

GATT（Generic Attribute Profile）によるデータ構造化

GATTは、ATTをベースとして、BLEデバイス間でデータをどのように構造化し、サービスとして提供するかを定義するプロファイルです。GATTでは、関連するデータの集合を「サービス（Service）」としてまとめ、各サービスの中に具体的なデータ項目である「キャラクタリスティック（Characteristic）」を配置します。例えば、心拍計であれば「心拍サービス」の中に「心拍数キャラクタリスティック」が存在する、といった具合です。

このGATTの設計が、アプリケーションからBLEデバイスのデータをどのように利用するかを決定づけるため、非常に重要になります。

GATTサービスとキャラクタリスティック設計の勘所

GATTプロファイルを設計する上で、サービスとキャラクタリスティックの構造をどう定義するかは、製品の使いやすさや拡張性に直結します。

サービスとキャラクタリスティックの階層構造

GATTのデータ構造は、基本的に「サービス」と「キャラクタリスティック」の階層で構成されます。

• サービス：特定の機能や情報のまとまりを示します。例えば、バッテリー情報を提供する「Battery Service」や、デバイス情報を提供する「Device Information Service」などがあります。
• キャラクタリスティック：サービスに含まれる具体的なデータ項目です。例えば、Battery Serviceには「Battery Level」キャラクタリスティックが含まれます。

サービスの内部には、さらに別のサービスへの参照（インクルードサービス）や、そのサービスに固有のキャラクタリスティックを複数定義できます。

UUIDの選び方：標準とカスタム

サービスやキャラクタリスティックは、それぞれUUID（Universally Unique Identifier）によって識別されます。

• 標準UUID：Bluetooth SIGが定義した標準サービスやキャラクタリスティックには、16ビットまたは32ビットの短いUUIDが割り当てられています。これらを使用することで、異なるメーカーのデバイス間でも互換性を保ちやすくなります。例えば、Battery ServiceのUUIDは0x180F、Battery Levelは0x2A19です。
• カスタムUUID：製品固有の機能やデータを扱う場合は、128ビットのカスタムUUIDを生成して使用します。カスタムUUIDを使う際は、他の製品との衝突を避けるために、UUID生成ツールなどを利用してユニークなものを発行することが一般的です。

可能な限り標準UUIDを利用し、どうしても必要な場合にのみカスタムUUIDを使うのが、GATT設計の基本的な考え方です。

キャラクタリスティックのプロパティと記述子

キャラクタリスティックには、そのデータのアクセス方法や振る舞いを定義する「プロパティ」を設定します。主なプロパティには以下のようなものがあります。

• Read：セントラルからキャラクタリスティックの値を読み出すことができます。
• Write：セントラルからキャラクタリスティックの値を書き込むことができます。
• Notify：ペリフェラルからセントラルへ、値が変更されたことを非同期に通知できます。セントラルからの確認応答は不要です。
• Indicate：Notifyと同様に非同期通知ですが、セントラルからの確認応答が必要です。

また、キャラクタリスティックには、その値に関する補足情報を提供する「記述子（Descriptor）」を追加できます。例えば、キャラクタリスティックの単位やフォーマット、説明などを記述子として定義することが可能です。

NotifyとIndicate：データ送信方式の使い分け

GATTキャラクタリスティックのプロパティとして重要なNotifyとIndicateは、どちらもペリフェラルからセントラルへデータを非同期に通知する機能ですが、その振る舞いには大きな違いがあります。

Notify：迅速性と効率性を重視

Notifyは、ペリフェラルがセントラルに対して、キャラクタリスティックの値が更新されたことを一方的に通知する方式です。セントラルからの確認応答（ACK）を待ちません。

• 特徴：高速なデータ送信に適しています。リアルタイム性の高いセンサーデータ（例：加速度センサー、ジャイロセンサー）など、多少のパケットロスが許容され、最新の値が次々と送られてくることが重要な場合に有効です。
• 注意点：確認応答がないため、パケットロスが発生した場合、セントラル側はデータの受信に失敗したことを認識できません。

Indicate：信頼性と確実性を重視

IndicateもNotifyと同様に非同期通知ですが、こちらはセントラルからの確認応答を必要とします。ペリフェラルは、セントラルからACKが返ってくるまで、次のIndicateパケットを送信しません。

• 特徴：データが確実にセントラルに届いたことを保証したい場合に適しています。デバイスの設定値の変更や、重要なコマンドの実行結果など、信頼性が求められる通信で利用されます。
• 注意点：ACKを待つため、Notifyに比べてスループットは低下します。ACKがタイムアウトした場合、再送処理が必要になることもあります。

どちらの方式を選ぶかは、データの種類とアプリケーションが求める信頼性によって判断します。

主要な開発環境でのBLE実装例

BLEスタックの実装は、使用するマイコンや開発キットによって手順が異なります。ここでは、代表的な開発環境であるNordic nRF5 SDKとEspressif ESP-IDFでの実装の考え方を概説します。

Nordic nRF5 SDKでの実装概要

Nordic SemiconductorのnRFシリーズは、BLE通信に特化した高性能なマイコンであり、NRF5 SDKはその開発を強力にサポートします。SDKには豊富なサンプルコードが含まれており、これをベースに開発を進めるのが一般的です。

• GATTサービスの定義：SDKが提供するAPIを使用して、サービスとキャラクタリスティックのUUID、プロパティ、パーミッションなどを構造体として定義します。
• イベントハンドリング：BLEスタックからのイベント（接続、切断、データ受信、Notify/Indicateの有効化など）は、コールバック関数として登録し処理します。
• データ送信：NotifyやIndicateでデータを送信する際は、対応するAPIを呼び出し、更新されたデータを渡します。

NordicのBLEスタックは安定しており、ドキュメントも充実しているため、BLE開発の初心者でも比較的取り組みやすいでしょう。

Espressif ESP-IDFでの実装概要

Espressif SystemsのESP32は、Wi-FiとBLEを統合したSoCとして人気があります。ESP-IDFは、ESP32向けの公式開発フレームワークで、BLEスタックも提供しています。

• GATTサービスの定義：ESP-IDFでは、GATTサーバー（ペリフェラル側）およびGATTクライアント（セントラル側）のAPIが提供されており、これらを用いてサービスとキャラクタリスティックを登録します。
• イベントドリブン：Nordicと同様に、BLEスタックからの各種イベントは、イベントループとハンドラ関数によって処理されます。
• 柔軟な構成：ESP-IDFはRTOS（FreeRTOS）上で動作し、比較的低レベルなAPIも提供されるため、より柔軟なBLEアプリケーションを構築できます。

ESP32はWi-Fiとの連携が容易なため、BLEで収集したデータをクラウドにアップロードするようなIoTゲートウェイ的な用途で強みを発揮します。

製品化を見据えたBLE実装の重要ポイント

試作段階では動くBLE通信も、製品として市場に出すには様々な考慮が必要です。

消費電力と安定性

BLEデバイスの多くはバッテリー駆動であるため、消費電力の最適化は極めて重要です。アドバタイズ間隔や接続間隔、送信電力の設定、スリープモードの活用など、ハードウェアとソフトウェアの両面から徹底した最適化が求められます。また、電波環境の変化や複数デバイスが接続される状況でも、安定した通信を維持できる設計が必要です。

認証取得への配慮

BLEは無線通信機能を持つため、各国・地域の電波法規に基づいた認証取得が必須です。日本では技適（技術基準適合証明）がこれに該当します。技適は設計段階から考慮する必要があり、安易な部品選定や回路設計は認証取得を困難にする可能性があります。特に、アンテナ設計や高周波回路のレイアウトは、認証の合否に直結するため、専門的な知識と経験が求められます。最新の情報は総務省など所管機関で確認してください。

ファームウェアアップデート（OTA）

製品出荷後に機能追加や不具合修正が必要になることは珍しくありません。BLE経由でファームウェアを無線で更新するOTA（Over-The-Air）機能は、IoTデバイスの運用において非常に重要です。OTA機能の実装には、安全なブートローダーの設計や、アップデート中の通信断に対するリカバリ機能など、高度な組み込みソフトウェア技術が求められます。

サイコス・ジャパンの製品開発支援

当社では、これまで多くのIoTデバイス開発においてBLE通信の設計・実装を手がけてきました。特に、試作から量産まで一貫して支援する中で、安定したBLE通信を実現するためのノウハウを蓄積しています。技適などの認証取得も設計段階から支援しており、お客様が安心して製品を市場に出せるようサポートしています。

BLE通信を搭載した製品開発でお困りの際は、ぜひ一度ご相談ください。初回相談は無料です。