概要

本稿では、Bluetooth^® Low Energy（以下、BLE）スタックのアーキテクチャについて詳しく説明します。BLEは、低消費電力のワイヤレス通信アプリケーションの可能性を最大限に高める技術です。本稿では、BLEを採用するアプリケーションの設計、トラブルシューティング、最適化を、効率的かつ確実に実施するために不可欠な事柄について解説します。

はじめに

BLEは、IoT（Internet of Things）のエコシステムの中で非常に重要な役割を担う技術です。当初、BLEはコンスーマ向け製品で使われるケーブルを不要にするためのプロトコルとして開発されました。そのような製品の例としては、ワイヤレス・キーボード、マウス、ヘッドセットなどが挙げられます。ただ、現在では単にケーブルを置き換えるものではなく、様々な目的を達成するための有用な手段だと位置づけられています。実際、BLEはコンスーマ分野だけでなく、医療、小売、自動車など様々な分野で活用されるようになりました。また、産業分野でも、ロケーション・タグや計装制御システムなどにおいて重要な役割を果たしています。

「2023 Bluetooth Market Update」¹によると、2023年から2027年の間にワイヤレス技術としてBluetoothを使用する機器の出荷数は9%の年平均成長率（CAGR）で増加するといいます。この成長に伴い、BLEを使用する機器の出荷数は2027年までに2倍以上に増加し、Bluetooth技術に対応する機器のうち97%はBLEを採用したものになると予想されています¹。

BLEは、2010年7月にBluetooth 4.0の仕様に盛り込まれました。当初、Bluetooth Smartと呼ばれていたBLEは、消費電力を最小限に抑えることが求められる機器向けに特別に設計されています。

従来のBluetooth技術は、スマートフォンとヘッドセットのペアリング、音楽／画像といった大容量のデータの転送など、多くの人にとって馴染み深いアプリケーションで使われてきました。それに対し、BLEはそれらとは異なる目的で使用される傾向にあります。Bluetoothを使用すれば、大容量のデータの転送を実現できます。但し、そうするとバッテリの電力を大量に消費してしまいます。一方、BLEは大量のデータの転送を必要としないアプリケーション向けに設計されています。言い換えれば、消費電力を抑えることが重要なアプリケーションに対して最適化されているということです。旧来のBluetoothに関連する回路は、使用していないときにもアクティブなままで電力を無駄に消費していました。それに対し、BLEに関連する回路は、ほとんどの時間、スリープ・モードの状態になります。接続が開始されたときにだけウェイクアップして動作しますが、通常、接続時間は数ミリ秒程度しか継続しません。BLEでは、このような効率的なパワー・マネージメントが可能です。また、BLE 5.0では最高1Mbps、あるいは2Mbpsのデータ・レートを利用できます。BLEを採用した機器は、このようなパワー・マネージメント手法とデータ・レートを活用しつつ、最小限の消費電力で動作することが可能です。

Bluetoothの仕様

図1、図2をご覧ください。これらの図は、それぞれBluetooth ClassicとBLEの特徴について説明したものです。それぞれの概要をまとめると以下のようになります。

• Bluetooth Classic：Bluetoothの最も初期のバージョンであり、より高いデータ・レートに対応します。ストリーミング、広帯域幅のファイル転送、ヘッドセットといったアプリケーションに適した技術です。79 のRF チャンネルを備え、32 のチャンネルで発見（discover）／接続を実現します。
• BLE：狭帯域幅のデータ転送を行うセンサーなど、データ転送の頻度が少なく消費電力を抑えることが重要なアプリケーションを対象としています。40 のRF チャンネルを備え、3つのチャンネルで発見／接続を実現します。

BLEを使用するアプリケーションの概要

BLEを使用する一般的なアプリケーションは、ペリフェラル、セントラルと呼ばれる2つのデバイス（機器）で構成されます。ペリフェラルは、接続を確立するために、BLEアドバタイズ（通知）と呼ばれるプロセスによって自身の存在をブロードキャストします。一方、セントラルは利用可能なペリフェラルをスキャンします。対象とするペリフェラルをセントラルが発見したら、2つのデバイスの間の接続が確立されます。その後、各デバイスは、BLEスタックの様々なレイヤを介してデータをやり取りします（図3）。つまり、通信が実現されるということです。

例えば、ヘルスケア分野の典型的なアプリケーションでは、スマートフォンをセントラル・デバイスとして使用し、フィットネス・トラッカをペリフェラル・デバイスとして使用します。フィットネス・トラッカはサーバとして機能し、心拍数や血圧、心電図、歩数、睡眠パターンなどのデータを収集します。また、フィットネス・トラッカは、クライアントとして機能するスマートフォンを含めて、近くにあるデバイスに自身の存在をアドバタイズします。スマートフォンはフィットネス・トラッカからデータを取得し、ユーザが簡単にその内容を理解できるようアプリによって表示を行います。これは、BLEを使用して実現できるアプリケーションの一例にすぎません。そうしたアプリケーションについては、本稿の後半で改めて説明することにします。

BLEスタックのアーキテクチャ

図4に、BLEスタックのアーキテクチャの概要を示しました。このスタックは、BLEデバイス間で通信を行うための構造化されたソフトウェア・フレームワークとして機能します。Bluetoothを採用したデバイス間の接続の確立、維持、終了、データ交換に必要なレイヤとプロトコルが定義されています。

BLEスタックのアーキテクチャは3つの主要なレイヤ（層）から成ります。アプリケーション層、ホスト層、コントローラ層の3つです。アプリケーション層はスタックの最上位に位置します。この層は、BLEデバイスで実行されるアプリケーションにより、実際にデータが利用／処理される場所です。ホスト層は、アプリケーション層とコントローラ層の間に位置します。ホスト層には、BLEによる通信に必要な上位レベルのすべてのプロトコルとプロファイルが実装されます。また、アプリケーションがスタックの下位層との間でやり取りを行えるようにするために高レベルのAPI（Application Programming Interface）を提供します。コントローラ層は、BLEスタックに含まれるハードウェア・コンポーネントです。この層は、Bluetoothの信号の送受信に必要な処理を担います。具体的には、周波数ホッピング、信号の変調、復調などのタスクを処理します。上記の各層が連携して動作することにより、BLEデバイスの間で効率的かつ信頼性の高い通信が実現されます。

アプリケーション層

アプリケーション層には、BLEデバイスの特定の機能が実装されます。この層は、GATT（Generic Attribute Profile）を介してスタックの下位の層とやり取りします。また、この層にはサービス、キャラクタリスティック（Characteristic）、対応するデータを定義します。

デバイスの機能と動作に関する設計は、アプリケーション層に反映されます。例えば、サービスやキャラクタリスティックの定義、データの交換方法の指定、接続／切断／データ更新などのイベントを処理するロジックが実装されるといった具合です。BLEスタックは、デバイスの特定の要件やユース・ケースに応じ、基本的にアプリケーション層によってカスタマイズされることになります。

ホスト層

アプリケーション層の下位にあるのがホスト層です。ホスト層には、L2CAP（Logical Link Control and Adaptation Protocol）、SMP（Security Manager Protocol）、ATT（Attribute Protocol）、GATT、GAP（Generic Access Profile）が含まれています。L2CAPは、上位層のプロトコルと下位層の間のインターフェースとして機能します。アプリケーションで使用するデータのフラグメンテーションとデフラグメンテーションに対処し、ACL（Asynchronous Connection-Less）リンクを使用してパケットを転送します。また、L2CAPはCID（Channel Identifier）とチャンネルの多重化を使用し、デバイス上のエンドポイントを適切に特定します（図5）。

L2CAPシグナリング

BLEスタックにおいて、デバイス間ではリクエストとレスポンスの形でコマンドが交換されます。コマンドに関する重要なポイントを以下にまとめます。

• コマンドはリクエストとレスポンスの形で送信されます。
• PDU（Protocol Data Unit）ごとに1つのコマンドを送信できます。
• L2CAPシグナリングのメッセージを含む PDUはCフレーム（Control Frame）と呼ばれます。データ・フレームは、Bフレーム（Basic Information Frame）とLE フレーム（Low Energy Information Frame）に分類されます（図6）。

  



• コマンドの拒否
  • コマンドのコードが識別されなかった場合、またはコマンドの長さが間違っていた場合に送信されるレスポンス
  • 考えられる理由
    • コマンドを解釈できない
    • シグナリングのMTU（Maximum Transmission Unit）を超えている
    • リクエスト内のCIDが無効
• 接続パラメータの更新を求めるリクエスト
  • 新しい接続パラメータのセットの要求。LEのノードからLEのメインに送信される
  • 接続パラメータ
    • 最小間隔
    • 最大間隔
    • ノードのレイテンシ
    • タイムアウト・マルチプライヤ
• 接続パラメータの更新要求に対するレスポンス
  • 接続パラメータの更新を求めるリクエストに応じ、LEのメインからLEのノードに送信

SMPには、BLEデバイスの間のペアリング、認証、暗号化のプロシージャ（手順）が定義されます。SMPのコマンドは、L2CAPのサービスを使用することでそれらのプロシージャを実行します。SMPのコマンドのパケットは、コード・フィールドとデータ・フィールドから成ります。コード・フィールドは、コマンドの種類を識別するためのものです。データ・フィールドの長さとフォーマットは、コマンドの種類によって異なります。SMPに定義されたすべてのプロシージャは、30秒でタイムアウトするように実装されます。タイムアウトは、プロシージャの実行に失敗したことを通知するために使われます。SMPのコマンドについては表1をご覧ください。

表1. SMPのコマンドのコード

コード	説明	フェーズ
0x00	予約済み	—
0x01	ペアリングのリクエスト	フェーズ1
0x02	ペアリングのレスポンス	フェーズ1
0x03	ペアリングの確認	フェーズ2
0x04	ペアリング・ランダム	フェーズ2
0x05	ペアリングの失敗	フェーズ2
0x06	暗号化の情報	フェーズ3
0x07	マスタの識別	フェーズ3
0x08	識別情報	フェーズ3
0x09	識別アドレスの情報	フェーズ3
0x0A	署名の情報	フェーズ3
0x0B	セキュリティに関するリクエスト	フェーズ1
0x0C～0x0FF	予約済み	—

ATTには、デバイス上の属性（Attribute）またはデータにアクセスするためのルールを定義します。それにより、リモート・デバイスの属性の検出、読み出し、書き込みが可能になります。ATTは、クライアント‐サーバ・モデルをベースとしています。つまり、サーバが一連の属性を公開し、クライアントがそれらの属性の検出、読み出し、書き込みを行います。ATTの属性は、ハンドル、タイプ、値、パーミッション（Permission）で構成されます（図7）。これらのうち、ハンドルはサーバ上の各属性に割り当てられたゼロ以外の一意的な値です。属性のタイプはその属性が表す内容を指定するものであり、UUID（Universally Unique Identifier）によって識別されます。UUIDは、Bluetooth SIG（Special Interest Group）によって割り当てられた16ビットの値です。あるいは、UUIDとして128ビットのカスタムの値を使用することもできます。属性の値は実際のデータの値です。属性に許可されるアクセス・レベルは、属性とその属性のパーミッションによって決まります。

ATTには6種のPDUを定義します。リクエスト、レスポンス、コマンド、ノーティフィケーション（Notification）、インディケーション（Indication）、コンファメーション（Confirmation）の6つです（図8）。リクエストのPDUはクライアントからサーバに送信され、レスポンスを要求します。レスポンスのPDUは、レスポンスが要求されたときにサーバからクライアントに返されます。コマンドのPDUはクライアントからサーバに送信されますが、応答を必要としません。インディケーションのPDUはサーバからクライアントに送信され、応答を必要とします。コンファメーションのPDUは、インディケーションに対する応答としてクライアントからサーバに送信されます。ノーティフィケーションのPDUはサーバからクライアントに送信されますが、応答を必要としません。これらのPDUにより、BLEスタックのATT層においてクライアントとサーバの間の制御と情報交換を行うことが可能になります。

ATTのPDUのパケットは、オペコード、属性のパラメータ、認証用の署名で構成されます（図9）。オペコードのフィールドは、リクエストやレスポンスといったPDUのメソッド／タイプの識別に使われます。また、オペコードには、PDUがコマンドであるか否かを表すコマンド・フラグと、パケット内で認証用の署名が使用されることを表す認証用の署名のフラグが含まれます。

図10は、BLEスタックのアーキテクチャにおける各レイヤのパケットのフォーマットについてまとめたものです。これにより、データの基本的な構造について把握できるはずです。

ホスト層の上から2番目に位置するのがGATTです。GATTには、属性またはデータをフォーマットする方法、データをパッケージングする方法、接続されたデバイスの間でデータを交換する方法を定義します。GATTのプロシージャは、属性の検出、読み出し、書き込み、ノーティフィケーション、インディケーションで構成されます。これにより、BLEデバイスでデータを管理するための標準的なフレームワークが提供されることになります。

BLEデバイスには複数のGATT（プロファイル）が存在するケースがあります（図11）。Bluetoothの仕様には、異なるメーカーが製造したBLEデバイスの間で相互運用性を確保するための標準のプロファイルが定義されています。ただ、特定のアプリケーションの要件に基づいてカスタムのプロファイルを実装することも可能です。その意味でも、GATTの構造について理解することは重要です。

GATTのプロファイルはサービスで構成されています。ここで言うサービスとは、ATTのプロトコルに定義された関連する属性の集合のことです。GATTでは、属性のことをキャラクタリスティックという用語で表すことがよくあります。ただ、キャラクタリスティックには属性そのものであるディスクリプタ（Descriptor）が含まれていることがあります。キャラクタリスティックは、ユーザのデータを格納する場所です。一方、ディスクリプタはユーザのデータに関する説明または追加情報を提供します。

ATTと同様に、GATTにはGATTクライアントとGATTサーバという2つの役割があります。GATTクライアントとは、リモートのGATTサーバ上で利用可能なデータにアクセスするデバイスのことです。一方、GATTサーバのデバイスは、リモートのGATTクライアントに対してデータへのアクセス手段を提供します。GATTにおけるデバイスの役割は、データにアクセスする方向によって決まります。

ホスト層の最上位に位置するのがGAPです。GAPには、BLEデバイスが互いにアクセス／通信する方法が定義されます。具体的には、動作モード、デバイスを発見するための一般的なプロシージャ、接続の確立、セキュリティなどについて定義します。GAPは、Bluetooth技術を使用するすべてのデバイスに実装しなければなりません。なぜなら、GAPはBLEデバイスを制御するための標準的なフレームワークを提供するものであるからです。

GAPは、BLEデバイスのアクティビティに応じて異なる機能を提供します。接続の必要がない場合、BLEデバイスはブロードキャスタまたはオブザーバとして機能することが可能です（図12）。ブロードキャスタというのは、自らを周辺にアドバタイズするデバイスのことです。ブロードキャスタは、主にリンク層のアドバタイザの機能を利用してアドバタイズメントを送信します。一方、オブザーバはブロードキャスタとは逆の機能を実行します。すなわち、リンク層のスキャナの機能を利用して近傍のエリアをスキャンし、検出したデバイスからアドバタイズメントを受信します。BLEを採用したビーコンはブロードキャスタの一例です。オブザーバの例としては、データの収集に使用するBLE対応のハブが挙げられます。

接続を確立できる場合、GAPによって、BLEデバイスに対してペリフェラルとセントラルという2つの役割が追加で提供されます（図13）。ペリフェラル・デバイスは、ブロードキャスタと同様に自らをアドバタイズします。そしてリモートのセントラル・デバイスからの接続リクエストを待ち受けます。一方、セントラル・デバイスはオブザーバとして機能します。つまりペリフェラルをスキャンし、対象となるペリフェラルに対して接続リクエストを送信します。先述したように、ペリフェラル・デバイスの例としてはスマートウォッチ、フィットネス・トラッカ、ホーム・オートメーション用のセンサーなどが挙げられます。セントラル・デバイスとしてはスマートフォン、タブレット端末、ノート型PCなどが使われます。

Bluetoothの仕様で規定されているように、プロファイルとしては、GATTサーバによってホストされるサービスがGAPに含まれます。また、GAPのサービスには様々なキャラクタリスティックが含まれています。それらは、デバイスに関する重要な情報を提供します。具体的には、デバイス名、デバイスの外観、ペリフェラルの接続の優先度に関するパラメータ、セントラルにおけるアドレスの解決手段、解決が可能なプライベート・アドレスだけが含まれています。

コントローラ層

コントローラ層には2つの層があります。リンク層と物理（PHY）層です。物理層は、BLEスタックの最下層に位置します。この層は、無線による実際の信号の送受信を担います。使用する周波数帯は2.4GHzのISM（Industrial, Scientific, and Medical）帯です。また、変調方式としてはGFSK（Gaussian Frequency-Shift Keying）変調を使用します。GFSKでは、キャリア信号の周波数をシフトすることで効率的なデータ伝送を実現します。

物理層は40のチャンネルで構成されます。また、各チャンネルは2MHzの間隔で配置されます。物理層のチャンネルには以下のような特徴があります。

• 短いデータ・パケットのブロードキャストに3つのアドバタイジング・チャンネルが使用されます。それにより、アドバタイザの存在、利用可能なサービス、情報が伝達されます。
• セントラル・デバイスとペリフェラル・デバイスの間で通信が確立すると、37 のデータ・チャンネルを使用できます。

Bluetooth 5 Core Specificationが策定されるまで、BLEにおけるアドバタイズメント専用のチャンネルは3つだけでした（図14）。しかし、拡張アドバタイズメント（Extended Advertisement）の導入に伴い、補助的なアドバタイジング・チャンネルとして残りの37チャンネルを使用できるようになりました。この拡張により、Bluetooth 5の新機能を活用することが可能になりました。例えば、物理チャンネルについて様々なコーディング方式を採用できるといった具合です。

Bluetooth 5が導入されたことにより、BLEは3種類の変調方式と4種類のデータ・レートを提供する様々なPHYをサポートすることになりました（表2）。デフォルトのPHYは、LE 1Mとして知られているものです。LE 1Mは1メガシンボル／秒（Msymps）の変調方式で動作し、1Mbpsのデータ・レートを達成します。また、最長100mの範囲でワイヤレス通信を行うことが可能です。2つ目のPHYはLE 2Mと呼ばれています。こちらは2Msympsの変調方式を使用し、2Mbpsという2倍のデータ・レートをサポートします。3つ目のPHYは、LE Codedと呼ばれています。LE Codedでは125kbpsと500kbpsのデータ・レートを使用できます。また、LE 1Mと同様に1Msympsの変調方式を採用しています。但し、LE Codedの変調方式には次のようなコーディング方式が追加されています。すなわち、125kbpsのデータ・レートを使用する場合、8つのシンボルを使って1つのビットをエンコードします。500kbpsのデータ・レートを使用する場合には、1つのビットを2つのシンボルで表します。このコーディング方式により、LE CodedのPHYは長距離の通信に対応できるようになりました。具体的には、自由空間において最長1000mの通信距離を実現可能です。

表2. BLEのPHYの種類

PHY	変調方式	コーディング方式		データ・レート
		アクセス・ヘッダ	ペイロード
LE 1M	1Msympsの変調	コーディングなし	コーディングなし	1Mbps
LE 2M	ペアリングのリクエスト	コーディングなし	コーディングなし	2Mbps
LE Coded	ペアリングのレスポンス	S = 8	S = 8 S = 2	125kbps 500kbps

物理層の上位に位置するのがリンク層です。リンク層は、スキャン、アドバタイジング、作成（Creating）、デバイス間のリンクまたは接続の維持を担います。また、リンク層では、干渉を軽減するために周波数ホッピング・スペクトラム拡散を利用してデータ伝送に用いる周波数を管理します。リンク層には、スタンバイ、アドバタイジング、スキャン、イニシエーティング（Initiating）、コネクションという状態が存在します（図15）。各状態の概要は以下のようになります。

• アイドル状態において、リンク層はスタンバイの状態に移行します。このとき、パケットの送受信は行われません。
• アドバタイジングの状態において、リンク層（アドバタイザとして機能）はアドバタイジングのパケットを送信します。それと同時に、追加の情報をリクエストするデバイスのリッスンも実行します。
• スキャンの状態において、リンク層（スキャナとして機能）はアドバタイザをリッスンします。アドバタイザからの追加の情報をリクエストする場合もあります。
• イニシエーティングの状態において、リンク層（イニシエータとして機能）はアドバタイザからのパケットをリッスンします。接続を開始することで、それらのパケットに応答します。
• リンク層が別のBLEデバイスのリンク層に接続されている場合、コネクションの状態になります。

上記の様々な状態に加え、リンク層には2種類のイベントも定義します。アドバタイジング・イベントとコネクション・イベントの2つです。アドバタイジング・イベントには、アドバタイジング・チャンネルを使用したパケットの送信が含まれます。一方、コネクション・イベントには、コネクションの状態におけるデータ・チャンネルを介したパケットの送信が含まれます。

また、リンク層には、物理層によって送信されるBLEパケットのフォーマットも定義します。そのパケットのフォーマットは2つに分類されることがあります。1つは、Coded PHY（符号化PHY）に使用されるフォーマット、もう1つはUncoded PHY（非符号化PHY）に使用されるフォーマットです。

図16に示すように、Uncoded PHYのBLEパケットは、プリアンブルから始まります。その後に、アクセス・アドレス、PDU、CRC（Cyclic Redundancy Check）などが続きます。

図17に、Coded PHYのBLEパケットの構造を示しました。ご覧のように、プリアンブル、FEC（Forward Error Correction）ブロック1、FECブロック2で構成されています。以下、それぞれの概要について説明します。

• プリアンブルは1と0が交互に続くシーケンスです。これは周波数の同期に使用されます。LE 1M では1 バイト長、LE2M では2 バイト長です。
• アクセス・アドレスは、物理チャンネルに対して調整されたデバイスによって相関コードとして使用されます。その長さは4バイト長です。物理的なアドバタイジング・チャンネルにおいて、アクセス・アドレスは0x8E89BED6 という固定値になります。
• PDUには、BLEスタックの上位層からのペイロードが含まれます。その実体は、アドバタイジングのPDU またはデータのPDU です。後者は、センサーあるいは通信に必要なデバイスからの重要な情報を含んでいる可能性があります。詳細については後述します。
• CRCは誤り検出に使用します。
• コンスタント・トーンの延長（CTE：Constant Tone Extension）は、常に変調された一連の白色化されていない1s で構成されます。これは通常はオプションです。CTE は、BLE の方向検知と呼ばれる機能で重要な意味を持ちます。
• FECブロック1には、アクセス・アドレス、コーディング・インジケータ（CI：Coding Indicator）、ブロック・ターミネータ1（Term 1）が含まれています。CI は、FEC ブロック2 で使用するコーディング方式を指定します。Term 1 は3 ビットのブロック・ターミネータです。
• FECブロック2には、PDU、CRC、Term 2が含まれています。FEC ブロック1 のCI のフィールドで指定されたコーディングが行われます。

BLEパケットのPDUの中には、Uncoded PHYとCoded PHYの両方で使用されるものがあります。それらは、アドバタイジング・チャンネルのPDUとデータ・チャンネルのPDUに分類されます（図18～図21）。

図18に示したアドバタイジング・チャンネルのPDUは、アドバタイジングのイベントに使用されます。ご覧のように、2バイトのヘッダと最大255バイトのペイロードで構成されます。

図19に示したように、そのヘッダにはPDUのタイプ、RFU（Reserved for Future Use）、ChSel、TxAdd、RxAdd、長さを表すフィールドが含まれています。ChSel、TxAdd、RxAddの値はPDUのタイプによって異なります。長さはペイロードの長さをバイト単位で表したものです。

図20に示したデータ・チャンネルのPDUは、コネクションのイベントに使用されます。ご覧のように、2バイトまたは3バイトから成るヘッダ、ペイロード、暗号化されたリンクで使用されるMIC（Message Integrity Check）で構成されます。図21には、そのヘッダの詳細を示しました。

こちらは、LLID、NESN、SN、MD、CP、長さ、CTEInfoなどのフィールドから成ります。それぞれの概要を以下に示します。

• LLID（Link Layer Identifier）は、リンク層のデータのPDUがどのタイプのものであるのかを表します。
• NESN（Next Expected Sequence Number）は、ピア・デバイスから次にどのパケットが届くのかという予想を表します。
• SN（Sequence Number）は、現在のパケットを表します。
• CP（CTEInfo Present）は、CTEInfoの追加のフィールドが存在することを表します。
• 長さは、ペイロードの長さをバイト単位で表します。
• CTEInfoは、CTEのタイプと長さを表します。

ホスト・コントローラ・インターフェース

ホスト・コントローラ・インターフェース（HCI：Host Controller Interface）は、ホストとコントローラの仲介役として機能します。具体的には、両者の間のやり取りを可能にする標準化された一連のコマンドとイベントを提供します。

HCIは、UAR T（Universal Asynchronous Receiver Transmitter）、USB、SD（Secure Digital）、3線式のUARTなど、複数種のトランスポート層をサポートします。各トランスポート層には独自の仕様と要件がありますが、以下ではUARTのトランスポート層に焦点を絞って解説を進めることにします。

Bluetooth 5.2の仕様では、UARTのトランスポート層に対応するために、コマンド、イベント、ACLデータ、SCO（Synchronous）データ、ISO（Isochronous）データの各パケットをサポートしています。以下、それぞれの概要を説明します。

• コマンドのパケットは、ホストがコントローラにコマンドを送信するために使用されます。コマンドは、コントローラに特定の操作または構成を実行するよう指示します。
• イベントのパケットは、発生したイベントについてコントローラがホストに通知するために使用します。イベントには、接続状態の変化、データの受信といった関連情報が含まれることがあります。
• ACLデータのパケットは、ホストとコントローラの間でデータを交換するために使用されます。センサーからの情報やユーザが入力した情報など、非同期のデータの送信を可能にします。
• SCOデータのパケットは、ホストとコントローラの間で同期データを交換するために使用されます。ただ、このパケットはBLE ではサポートされていません。主にBluetooth Classicで音声／オーディオのデータを送信するために使用されることに注意してください。
• ISOデータのパケットは新たに追加されたものです。BLEデバイスの間で、時間的な制約のあるデータを伝送できるようにするために使用されます。ISO データのパケットは、オーディオのストリーミングやリアルタイム制御など、正確なタイミングが必要なアプリケーション向けに設計されています。

なぜBLEは重要なのか？

コンスーマ製品から産業用のシステムまで、BLEは様々なアプリケーションで広く使用されています。その理由は何なのでしょうか。実際、BLEとその重要性について理解するのは有益なことです。BLEは常に進化しており、プロトコルの改良が図られています。そのため、BLEを採用することで多彩なアプリケーションを実現できる可能性があります。

ユース・ケースの例

BLEは広範な分野で使われており、気づかないうちに人々の日常生活にも影響を与えています（図22）。BLEに精通していれば、その機能を理解して様々な領域で活用できるようになります。以下では、BLEによって既知のプロセスが大きく変革された例をいくつか紹介します。

医療分野

医療分野ではBLEが重要な役割を果たしています。BLEを採用することで、ワイヤレスの血糖値計や血圧モニタの設計が容易になります。また、ペースメーカなど、消費電力を極めて少なく抑えることが求められる埋め込み型のデバイスを実現することが可能になります。そうしたBLE対応の機器を使用すれば、様々なデータを収集し、患者や医療機関に対してリアルタイムにレポートを送信することができます。また、BLEは、患者の追跡、部屋番号や階数の特定、医療関係者に対する情報の送信といった用途でも活用されています。

位置の追跡

BLEは、高度なトラッカやスマート・タグでも利用されています。それらのデバイスを、鞄、鍵などの物品、更にはペットに装着すれば、それらの位置を追跡することができます。その場合に重要なのは、非常に小型かつ低消費電力なデバイスを設計することです。そのためのソリューションとして、消費電力の削減に役立つBLEの機能は不可欠なものになります。また、産業分野でも、物品を保管する倉庫の監視、食料品店における管理、屋内のナビゲーションといった用途でBLEが活用されています。

ウェアラブル機器

ウェアラブル機器では、小さなフォーム・ファクタと長いバッテリ寿命を実現する必要があります。このことから、BLEはウェアラブル機器にとって理想的な技術となります。スマートウォッチ、フィットネス用のベルト、スマート・グラスといった機器ではBLEが広く採用されています。なぜなら、少ない消費電力でワイヤレス接続を実現できるからです。

オーディオのストリーミング

オーディオのストリーミングでも、BLEは重要な役割を果たしています。LE Audioが導入されたことにより、BLEを使用してレイテンシの小さいオーディオのストリーミングを実現することが可能になりました。また、音質の向上も図られています。LE Audioには、LC3（Low Complexity Communications Codec）が盛り込まれています。これを利用すれば、オーディオ品質を損なうことなく低いデータ・レートをサポートできます。それにより、消費電力の面でワイヤレス・オーディオの新たな可能性が切り開かれます。

ホーム・オートメーション

ホーム・オートメーションの分野において、BLEはスマート・ホームを構築するための基盤技術として活用されています。スマート・ホームにはIoTが広く導入されています。そして、BLEにより、様々なスマート・デバイスの間のシームレスな接続が実現されています。ホーム・オートメーション用製品の市場では、BLEを採用した様々なスマート・デバイスを入手できます。キー・フォブ、家庭用ビーコン、スイッチなどがその例です。BLEを使用することで、自宅の様々なものを制御／監視できるようになります。例えば、スマート照明、効率的な家庭用エネルギー管理システム、スマート・ドア・ロック、ワイヤレス・スピーカ・システム、家庭用ロボット、セキュリティ・システムなどが実用化されています。

まとめ

BLEを採用したアプリケーションにおいて、データは様々なレイヤを通過してから、独自のBLEスタックを備える別のデバイス上のリモート・アプリケーションに到達します。そのプロセスは以下のようなものになります。

1. アプリケーション層では、送信するデータを保持する適切な属性が選択されます。
2. ATT層ではパケットが生成されます。そのパケットには、リモート・デバイス上で選択された属性に対応する情報が含まれています。
3. ATT層から送られてきたパケットはL2CAP層を通過します。その際、L2CAP層は必要に応じてデータのフラグメンテーションとデフラグメンテーションを処理します。また、すべてのL2CAP層のパケットにL2CAPのヘッダを追加します。
4.  L2CAP層のパケットはリンク層に引き渡されます。リンク層はそのパケットを無線で送信するために物理層に引き渡します。また、リンク層はパケットにリンク層のヘッダを追加します。それらはPDUと総称されます。
5. 物理層はパケットを送信する前に、必要なプリアンブル、アクセス・アドレス、CRCをPDUに追加します。その後、無線によってパケットが送信されます。

受信側では、リモートのBLEデバイスがパケットを受け取ります。そして、上記のプロセスとは逆のプロセスを実行することによりデータを抽出します。

アプリケーションでBLEを使用する際には、優れた効率と最適化を実現するために適切なハードウェアを選択することが重要です。アナログ・デバイセズは、様々なアプリケーションや要件に適したBLE対応のマイクロコントローラを数多く提供しています。

DARWINファミリの「MAX32665」と「MAX32666」は低消費電力のマイクロコントローラです。これらの製品は、現実の多様なアプリケーションに対応できるように設計されています。また、いずれもBluetooth 5 Low Energyの無線接続をサポートしています。そのため、IoTアプリケーションにおいて多様なデバイスに対するワイヤレス・インターフェースを実現することが可能です。しかも、アクティブ時の消費電力とリテンション電力が可能な限り少なく抑えられています³。加えて、DARWINファミリのマイクロコントローラは、このクラスのものとしては最大レベルの容量のメモリを内蔵しています。そのため、より規模の大きいアプリケーションやより多くのスタックをサポートすることが可能です。これらのマイクロコントローラは、高い柔軟性と高度な機能を備えています。そのため、IoT分野のあらゆる課題に対処可能な設計を実現することができます。これらのマイクロコントローラを採用すれば、最新のIoTソリューションの基盤を構築しつつ、進化への道を切り開くことが可能になります。

関連資料

¹ 2023 Bluetooth Market Update（Bluetoothの市場動向2023年版）、Bluetooth、2023年

² Bluetooth Technology Overview（Bluetooth技術の概要）、Bluetooth

³ Meet DARWIN: A New Breed of Low Power IoT MCUs（DARWINのご紹介：IoTに最適な低消費電力のMCU）、Analog Devices、 2022年10月

Madhur Bhargava「IoT Projects with Bluetooth Low Energy（Bluetooth Low Energyを活用したIoTのプロジェクト）」Packt Publishing, Limited、2017年

Bluetooth Core Specification Version 5.2 Feature Overview（Bluetooth Core Specification Version 5.2の機能の概要）、Bluetooth

Core Specification 5.4.、Bluetooth

Naresh Gupta「Inside Bluetooth Low Energy（Bluetooth Low Energyの内側）」Artech House、2013年

Stack Architecture（スタックのアーキテクチャ）、Zephyr Project

Bluetooth^®のワード・マークとロゴは、Bluetooth SIG, Inc.の登録商標です。Analog Devices, Inc.はこれらのマークをライセンスに基づいて使用しています。その他の商標および商号は、それぞれの所有者に帰属します。

著者について

Erick Reyes

Erick Reyesは、アナログ・デバイセズのシニア・ファームウェア・エンジニアです。ソフトウェア／セキュリティ・グループで、自動車、エネルギー、通信、航空宇宙の各ビジネス・ユニットをサポートしています。2019年に入社した当初は、プロダクト・アプリケーション・エンジニアとして高精度のコンバータとRF対応のワイヤレス・トランシーバーを担当していました。マプア大学（マニラ）で電子工学の学士号を取得しています。

Mary Grace Legaspi

Mary Grace Legaspiは、アナログ・デバイセズのファームウェア・エンジニアです。2018年9月にフィリピンのカビテ支社に入社しました。ソフトウェア／セキュリティ・グループで、コンスーマ・ビジネス・ユニットのサポートを担当。タルラック州立大学で電子工学の学士号、フィリピン大学で経営学の修士号を取得しています。

Eric Peňa

Eric Peñaは、アナログ・デバイセズの組み込みソフトウェア・アーキテクトです。2019年4月にフィリピンのカビテ支社に入社しました。ソフトウェア／セキュリティ・グループで、産業用オートメーション・ビジネス・ユニットのサポートを担当。それ以前は、Technology Enabler Designerでファームウェア・エンジニア、Fujitsu Ten Solutions Philippinesでシステム・エンジニアを務めていました。アダ...