リリース：	1.0.0
文書バージョン：	1.0
最終更新日：	2023年9月19日
著者：	マーティン・ウーリーBluetooth SIG Szymon Slupik, SILVAIR Inc. オムカー・クルカルニ、ノルディック・セミコンダクターハンヌ・マレット、シリコンラボデイモン・バーンズBluetooth SIG

改訂履歴

Version	Date	Author	Changes
1.0.0	September 19, 2023	Martin Woolley, Bluetooth SIG Szymon Slupik, SILVAIR Inc. Omkar Kulkarni, Nordic Semiconductor Hannu Mallet, Silicon Labs Damon Barnes, Bluetooth SIG	Initial version

注

Bluetooth Mesh プロファイル仕様は名称が変更され、現在は次のように呼ばれている。Bluetooth Mesh プロトコル仕様と呼ばれるようになった。本書と関連論文でバージョン1.1仕様を参照する場合はこの名称を使用するが，バージョン1.0仕様を参照する場合は引き続きBluetooth Mesh プロファイル仕様書仕様と呼ぶことにする。

1.はじめに

Bluetooth Special Interest Group (SIG) は、2023 年 9 月 19 日、Bluetooth^® Mesh テクノロジーの機能強化を発表した。プレスリリースでは、新しい主要機能、マイナーな機能強化、まったく新しいmesh デバイス・プロファイルが発表されている。本稿では、各変更点を要約し、主要な新機能をより詳細に検討した他の論文への参照を提供する。mesh のマイナーな機能強化については、本稿でレビューする。セクション 3 では、まったく新しいBluetooth^® Mesh デバイス・プロファイルを紹介する。第 4 章では、すべてのコンテンツ資産と仕様書の参考資料リストを示す。

Bluetooth Mesh を初めてご覧になる方は、まずBluetooth SIG ペーパーBluetooth Mesh Networking - An Introduction for Developers をお読みになることをお勧めします。

Mesh 1.1 またはBluetooth Mesh 1.1 という用語がBluetooth Mesh プロトコルまたはモデル仕様書バージョン 1.1 の略語として使われることがあり，同様にMesh 1.0 またはBluetooth Mesh 1.0 という用語がBluetooth Mesh プロファイル仕様書バージョン 1.0 の略語として使われることがあることに注意すること。

2.新しいBluetooth^® Mesh 特徴

2.1Bluetooth Mesh ダイレクトフォワーディング

Bluetooth Mesh Managed Floodingとして知られるメッセージ中継方法は、Bluetooth Mesh プロファイルのバージョン1.0で定義された。これは、Bluetooth Mesh ネットワークにおいて、複数のホップを経由して宛先までメッセージを配送するための、効果的で信頼性が高く、柔軟でメンテナンスの少ない方法を提供する。新しいBluetooth Mesh Directed Forwarding機能は、マルチホップのメッセージ配送方法を追加するもので、状況によってはBluetooth Mesh Managed Floodingよりも効率的である。

Bluetooth Mesh Directed Forwardingは、送信元アドレスから宛先アドレスへのメッセージのターゲット配送をサービスできる中継ノードの集合を確立する。メンバーシップパスは、意図した宛先に向けてメッセージを伝搬できるノードによってのみメッセージが中継されるように配置される。これにより、ネットワークと無線チャネルをより効率的に利用することができる。

自動化は、Bluetooth Mesh Directed Forwardingの重要な機能です。パスは必要なときに自動的に作成され、ネットワークでまだ必要とされ、必要なメッセージを配送できることを確認するために、一定期間ごとに自動的にチェックされる。後者の点は、ネットワークとそのデバイスが時間とともに変化する可能性があることを考えると、重要な機能である。

詳しくは、Bluetooth Mesh Directed Forwarding Technical Overview （英語）を参照のこと。 を参照のこと。

2.2Bluetooth Mesh デバイス・ファームウェアのアップデート

Bluetooth Mesh デバイスは、ハードウェアを制御し、製品の主要な動作を実装するソフトウェアであるファームウェアを実行する^。ファームウェアは常に最新の状態に保つ必要があり、の新しいデバイス・ファームウェア・アップデート機能は、ネットワーク上のデバイスのファームウェア・アップデートを検出し、適用することを可能にします。Bluetooth Mesh Bluetooth Mesh

ファームウェア・アップデートは、ネットワーク内のすべてのノードに大量のファームウェア・データを転送する必要があります。そのため、Bluetooth Mesh デバイス・ファームウェア・アップデート機能は、mesh ネットワーク上の他のアクティビティに影響を与えることなく、ファームウェアのバックグラウンド転送を可能にするために、ファームウェア・データを運ぶ個々のmesh メッセージのケイデンスとサイズを制御するためのいくつかのパラメータを提供する。

Bluetooth Mesh デバイス・ファームウェア・アップデートは、マルチキャストアップデートを可能にし、多数の同一デバイスで構成される照明ネットワークなどの設置に最適です。ファームウェアがターゲット・ノードに転送されると、例えば、営業時間外など、計画された時間にすべてのノードにアップデートを適用することができ、混乱を最小限に抑えることができます。

Bluetooth Mesh デバイス・ファームウェア・アップデート機能は、マルチベンダーmesh ネットワークのアップデートを簡単に行えるように設計されています。

詳しくは、Bluetooth Mesh デバイス・ファームウェア・アップデートの技術概要をご覧ください。 を参照してください。

2.3Bluetooth Mesh リモートプロビジョニング

Provisioningは、デバイスをmesh ネットワークに追加するために使用されるプロセスの名前です。Provisioner を使用して実行されます。従来は、Provisioner が新しいデバイスの直接の電波届く範囲にあり、Bluetooth リンクを介してそのデバイスと通信する必要があった。これは、固定された場所に設置されたデバイスにとっては問題であり、モバイルProvisionerのユーザーは、プロビジョニングのためにデバイスに向かって物理的に歩き、設置範囲をカバーする必要がある。新しいBluetooth Mesh リモートプロビジョニング機能には、mesh ネットワークを介してプロビジョニングを実行する機能が追加されています。プロビジョニングメッセージは、リモートの未プロビジョニングデバイスに到達するまでに 1 ホップ以上かかります。

新しいデバイスをプロビジョニングした後、コンフィギュレーションが行われる。一部のデバイスは複雑であり、それに応じて複雑な構成要件がある。また、新機能を追加するファームウェアの更新後に、デバイスを完全にまたは部分的に再構成する必要がある場合もある。Bluetooth Mesh リモート・プロビジョニングには、複雑なデバイスに対してプラグアンドプレイのデバイス構成更新機能を提供する手順も含まれる。

Bluetooth Mesh リモート・プロビジョニング機能は、Bluetooth Mesh ネットワークのライフサイクルにおける重要なイベントの処理を自動化する手順も提供する。たとえば、すべてのデバイスのデバイス・キーを再生成できるようにすることで、ネットワークが最初に作成された後の所有権の安全な移転が可能になる。

詳しくは、Bluetooth Mesh リモートプロビジョニング技術概要をご覧ください。 を参照してください。

2.4Bluetooth Mesh 証明書ベースのプロビジョニング

mesh ネットワークにプロビジョニングされるデバイスは、UUIDによって識別される。正当なデバイスのなりすましを防ぐため、帯域外で取得した公開鍵を使用してネットワークにデバイスをオンボーディングする場合、与えられた公開鍵が本当に特定のUUIDを持つデバイスに属しているかを確認する必要がある。

新しいBluetooth Mesh 証明書ベースのプロビジョニング機能では、公開鍵基盤（Public Key Infrastructure）を使用して、プロビジョニング対象外デバイスの公開鍵と UUID 情報を認証します。X.509 形式のデジタル証明書は、デバイス製造業者またはベンダーから提供され、プロビジョニングプロセスで使用されます。この機能により、Bluetooth Mesh プロビジョニングが以下の点で改善される：デバイスの帯域外（OOB）公開鍵の取得と相互運用可能な方法での認証が可能になり（デバイスは見えないまま）、優れた認証スキームによってセキュリティが向上し、同時に多数のデバイスの一括プロビジョニングに適しています。

詳しくは、Bluetooth Mesh Certificate-based Provisioning Technical Overview （英語）を参照のこと。 を参照のこと。

2.5 プライベート・ビーコン

Bluetooth^® Mesh は、多くの手順でビーコンの技術を使用し、ネットワーク・ビーコン・メッセージを定義している。新しいプライベート・ビーコン機能は、ビーコン・メッセージの静的情報がネットワーク外のデバイスから見えないようにすることで、セキュリティを向上させます。これにより、ウェアラブル・デバイスのように、ネットワーク内外を移動する可能性があり、mesh ネットワーク・ビーコン内のプレーン・テキスト・データを観察することで追跡可能であったかもしれないケースにおいて、プライバシーが向上します。

Bluetooth Mesh プライベート・ビーコン技術概要を参照。 を参照のこと。

2.6Bluetooth Mesh サブネット・ブリッジング

Bluetooth^® Mesh ネットワークは、1つ以上のサブネットを含むことができる。サブネットは多くの場合、ネットワークの部分ごとに異なるネットワーク・セキュリティー・キーを使用して、ネットワークの部分を互いに安全に分離するために使用される。

これまでは、異なるサブネットのデバイスが共通のサブネットに属し、メッセージを交換する際にそのサブネットのものを使用しない限り、通信する方法はありませんでした。新しいBluetooth Mesh サブネット・ブリッジ機能は、この機能を実装した中間ブリッジ・ノードの助けを借りて、共通のサブネットとそのNetKeyを事前に知らなくても、異なるサブネットのデバイス間の通信を可能にします。さらに、同じサブネットの別々の部分をブリッジすることで、ホテルの宿泊客がホテルのロビーに座っていても、自分の部屋のスマートデバイスを制御できるといったユースケースをサポートすることができます。

詳しくは、Bluetooth Mesh サブネット・ブリッジングの技術概要をご覧ください。 を参照のこと。

2.7Mesh 軽微な改良

Bluetooth^® Mesh テクノロジーには、 mesh のマイナー機能強化と総称される数多くの小さな機能も追加されています。この見出しで扱われている変更は些細なものかもしれませんが、場合によっては大きな利点があることに留意してください。以下のセクションでは、各機能強化の概要を説明し、最後にBluetooth Mesh の最新情報を掲載する。

2.7.1 オンデマンド・プライベートGATTプロキシ

2.7.1.1 背景

プロキシノードはBluetooth^®LE（GAP と GATT を使用）とBluetooth Mesh の両方をサポートする。プロキシは仲介役として機能し、スマートフォンなどのデバイス上のアプリケーションが、プロキシへの GATT 接続を介してネットワークとmesh メッセージを送受信することを可能にする。

Bluetooth Mesh 1.0プロキシノードを設定するとき、コミッショナーにある唯一のオプションは、プロキシ広告を有効または無効にすることである。ユーザーエクスペリエンスの観点からは、すべてのノードでプロキシを有効にすることが望ましいが、利用可能な帯域幅に影響を与え、結果としてmesh ネットワークのパフォーマンスに悪影響を与える可能性がある。

2.7.1.2 オンデマンド・プライベートGATTプロキシの強化

プロキシクライアント(スマートフォンのような)は、プロキシノードに広告を開始するべきであることをシグナリングできるようになった。これは、プロキシクライアントが、接続不可能なスキャン不可能な指向性のない広告Solicitation PDUをブロードキャストすることで実現される。

プロキシノードは、Bluetooth Mesh 1.0の動作に従って継続的に広告する必要はなくなった。その代わりにパッシブスキャンを実行し、プロキシノードのネットワークにマッチするネットワークIDデータを含むプロキシクライアントからのSolicitation PDUを受信すると、Private Network Identityタイプを使用して広告を開始する。その後、プロキシクライアントはプロキシに接続できる。

オンデマンドプライベートGATTプロキシ機能は、RFの利用をより効率的にし、その結果、スケーラビリティを向上させる。未承諾のGATTプロキシサービス広告がなく、有効な勧誘リクエストを送信するにはNetKeyの知識が必要であるため、攻撃者がネットワーク内のプロキシノードを特定することも難しくなる。

2.7.2 パフォーマンスの向上

2.7.2.1 セグメンテーションと再アセンブリ（SAR）の強化

2.7.2.1.1 背景

Bluetooth^® Mesh スタックの上位トランスポートレイヤーは、1回の送信では長すぎるmesh Accessメッセージのセグメンテーションと再アセンブリーを実行できる。このようなメッセージはセグメントに分割され、各セグメントは12オクテットの長さになる。個々のセグメントを受信すると、再組み立て処理によって元の Accessメッセージが再構成される。

これは、異なるベンダーのデバイスがSARの動作に異なるデフォルト値を使用している場合、mesh ネットワーク内で非効率なmesh メッセージ転送を引き起こす可能性がある。

2.7.2.1.2 SAR構成モデル

セグメンテーションと再アセンブリ（SAR）プロセスの主要な側面を制御するパラメータは、新しいSAR コンフィギュレーション・クライアント・モデルを使用して、新しいSARコンフィギュレーション・サーバー・モデル内で設定することができます。このモデルには、SARトランスミッターと SARレシーバーという2つの複合状態が含まれます。

SAR送信ステートには、セグメント化されたメッセージの送信者として動作するときに使用されるパラメータが含まれる。また、セグメント送信間のタイミング間隔や、ユニキャストアドレスやマルチキャストアドレスへのセグメントの再送に関するパラメータも含まれる。

SARコンフィギュレーション・サーバー・モデルは、特に複数のメーカーのデバイスを含むネットワークにおいて、コンフィギュレーション・タスクのパフォーマンスを向上させるのに役立ちます。

2.7.2.2 メッセージの集約

2.7.2.2.1 背景

一連の異なるタイプの確認済みAccessメッセージが、ある順序で送信される状況がある。各Accessメッセージの結果、応答として機能するステータスメッセージが生成され、通常、ステータスコードが含まれる。たとえば、新しいノードのコンフィギュレーション中、AppKeyをモデルにバインドする行為には、多くの確認応答メッセージとそれに関連するステータス応答メッセージが含まれる。

2.7.2.2.2 オプコード・アグリゲータ・モデル

Opcodes Aggregator ServerモデルとOpcodes Aggregator Clientモデルと呼ばれる新しいモデルと、Message Request List Processingプロシージャーと呼ばれる関連プロシージャーが導入されました。この手順により、異なる Access メッセージのシーケンスを、OPCODES_AGGREGATOR_SEQUENCEメッセージと呼ばれるタイプの単一の Access メッセージにまとめることができます。このメッセージ・タイプには、Access メッセージのオペコードと関連するパラメータ値の配列が含まれています。配列内のすべてのメッセージ・オプコードは、同じサーバー・モデルで処理されるメッセージ・タイプを識別する必要があります。これはセキュリティ機能であり、OPCODES_AGGREGATOR_SEQUENCE のアクセスレイヤーフィールドが暗号化される AppKey が、サーバーモデルにバインドされているものであることが必要です。

メッセージ・リクエスト・リスト処理手順は、含まれるアクセス・コードとパラメータで示される各アクションが実行され、応答として1つのOPCODES_AGGREGATOR_STATUSメッセージが返される。

メッセージ・オプコード・アグリゲーションは、一連のアクセス・メッセージとレスポンスに関わるデータ量と時間を圧縮し、その一連のやり取りを単一のリクエストとレスポンスに削減する。

2.7.3 複雑なデバイス

2.7.3.1 モデルのメタデータ

2.7.3.1.1 背景

Bluetooth^® Mesh 1.0は、コンフィギュレーション・サーバー・モデルを定義している。これは、すべてのデバイスによって実装されるモデルであり、コンフィギュレーションとコンポジション・データを多くの状態で含んでいます。

コンポジション・データの状態は一連のページとして構造化されており、各ページはコンフィギュレーション・サーバー・モデルのリクエストと対応するレスポンスを使って読むことができる。特定のページはページ番号で参照されます。特に、コンポジションデータのページ0ステートは、ノードが構成されるエレメントを定義し、各エレメント定義はエレメントがサポートするモデルを示します。

デバイスの中には、その構成や設定データ、その他の属性を記述するために、広範で可変的なデータを必要とするものがある。例えば、DALI（Digital Addressable Lighting Interface）デバイスは通信バスを中心に構築されており、最大128個のコンポーネントを簡単にプラグインまたはアンプラグすることができる。mesh ネットワークの一部である場合、DALI コンポーネントは、DALI デバイス全体を表す複雑なmesh ノードの要素となります。DALIノードは大規模で複雑な構成を持ち、そのメタデータ要件は、DALIメッセージ・バスに接続されるコンポーネントの特定のタイプによって異なります。

このような大規模で複雑なデバイスに関連するコンポジションとメタデータは、コンフィギュレーション・サーバー・モデルで定義されたメッセージでは対応できない場合がある。

2.7.3.1.2 モデルのメタデータ

Bluetooth^® Mesh には、モデル・メタデータの概念が含まれるようになった。モデル・メタデータは、モデルや、モデルがその一部となっている要素を何らかの形で記述する、1つ以上のプロパティーからなる一連のものです。メタデータ・アイテムには16ビットの識別子があり、Bluetooth SIG 番号が割り当てられています。

Bluetooth Meshサーバーモデルには、Models MetadataStateと呼ばれる状態が含まれ、Models Metadata Page 0から始まる一連のページとして構造化されている。Large Composition Data Serverモデルは、Configuration Serverモデルを拡張し、一連のAccessメッセージを定義しており、これらはすべてDevKeyで保護されている。

mesh の一部のモデル Bluetooth Mesh モデル S仕様v1.1のいくつかのモデルは、それらがサポートする1つ以上のメタデータタイプの表示を可能にするように拡張された。クライアントの実装は、Large Composition Data ServerモデルのModels Metadata Page 0状態からメタデータの値を取得することができます。例えば、Light Lightness ServerモデルはLight_Purposeメタデータタイプをサポートしています。Light_Purposeメタデータには、ライトの目的（アップライト、ダウンライト、ナイトライトなど）を示す 16 ビットの割り当て番号が含まれます。

2.7.3.1.3 大きな組成データ値

コンフィギュレーション・サーバー・モデルの コンポジション・データ（Composition Data）ステートは、ノードのコンポジション・データ（Composition Data）を含むステートであり続け、ノードが含む要素とそのモデルを示します。しかし、新しいラージ・コンポジション・データ・サーバー・モデルでは、オフセット・パラメータを使用して、このデータを一連のデータ部分としてアクセスできるメッセージを定義しています。これにより、DALIデバイスのような複雑なデバイスに必要な大きなComposition Dataに対応することができます。

2.7.4 認証アルゴリズムとプロビジョニング

2.7.4.1 背景

デバイスをネットワークにプロビジョニングするとき、Unprovisioned Device は Algorithms フィールドを含む Provisioning Capabilities PDU をプロビジョナに送信する。このフィールドは、プロビジョニングプロセスの認証ステップ中に確認値を計算するためにデバイスが使用できるアルゴリズムを示す。

以前は1つのアルゴリズムのみがサポートされていた。FIPS P-256 Elliptic Curveという短い名前で呼ばれるこのアルゴリズムは、RFC 4493で定義されているAES-CMAC関数を使用する。FIPS P-256 Elliptic Curveアルゴリズムは、128ビットの確認値を生成する。

さらに、古いmesh デバイスは、認証を使用せずにプロビジョニングされる可能性がある。これにより、たとえば、公式のプロビジョナがネットワークの試運転に到着する前に、ローカルのルージュ・プロビジョナが高い天井に取り付けられたすべての照明をプロビジョニングしてしまうという保守リスクが発生する。このような場合、高天井の照明を「プロビジョニングされていない」状態にリセットするために、手作業が必要になる可能性があります。

2.7.4.2 新しい認証アルゴリズムとプロビジョニングの改善

Bluetooth^® Mesh プロトコル仕様バージョン1.1では、AES-CMACを使用するアルゴリズムをBTM_ECDH_P256_CMAC_AES128_AES_CCMに改名し、BTM_ECDH_P256_HMAC_SHA256_AES_CCMという新しいアルゴリズムを導入した。この新しいアルゴリズムは HMAC-SHA-256 関数を使用し、256 ビットの確認値を生成する。

Bluetooth Mesh 準拠デバイスは、新しいBTM_ECDH_P256_HMAC_SHA256_AES_CCM アルゴリズムをサポートし、OOB Type フィールドがビット1を設定することで「OOB 認証プロビジョニングのみサポート」を示す場合、このアルゴリズムを使用しなければならない。古いデバイスで使用される場合、古いAES-CMACベースのアルゴリズムは引き続きサポートされる。

Bluetooth^® Mesh プロトコルでは、プロビジョニング中に非プロビジョニングデバイスに認証を義務付け、認証なしのプロビジョニング試行を拒否することができる。デバイスは、Provisioning Capabilities PDU の OOB Type フィールドのビット 1 を設定することで、このような認証要件を示す。

2.7.5 健康障害コード

2.7.5.1 背景

ヘルス・クライアントとサーバー・モデルは、障害報告と診断に関係する。Bluetooth^® Mesh ネットワークのすべてのノードのプライマリ・エレメントには、ヘルス・サーバー・モデルを含める必要があります。他のエレメントは、ヘルスサーバーモデルに障害を通知することができる。ヘルスサーバーモデルには、電流障害などの一連の障害関連状態が定義されている。フォルトは単一オクテットコードで表現される。利用可能な範囲内のいくつかの値は、Bluetooth SIG 使用のために予約されており、他の値はベンダー固有のコードである。

2.7.5.2 割り当て番号に移動した健康障害コード

健康サーバーモデルで使用されるBluetooth SIG 定義された故障コードは、本リリースで番号の割り当てが指定された。これは手続き上の変更であり、Bluetooth SIG 、会員がその製品で使用するための新しい標準故障コードを要求した場合に、より簡単かつ迅速に対応できるようにするものである。

2.7.6 割り当て番号

Bluetooth SIG 割り当て番号として知られる標準識別番号のデータベースを管理している。Bluetooth SIG 割り当て番号の全リスト。

割り当て番号リストへの追加リクエストは、Bluetooth SIG 、すべての会員が利用できる簡単な手続きである。

2.7.7.用語の変更

2.7.7.1 被提供者

未提供デバイスがプロビジョニングされるデバイスまたはアプリケーションは、「Provisioner」と呼ばれます。Bluetooth Mesh 1.1 では、プロビジョニング行為を説明する際に使用される言語をさらに正式なものにするため、プロビジョニングプロトコル PDU の交換を通じてプロビジョニングが行われている間、「Provisionee」という用語を使用して「Unprovisioned Device（プロビジョニングされていないデバイス）」を指すようになりました。

2.7.7.2 用語

Mesh プロトコル仕様書1.1では、デバイスのライフサイクル、その構造、構成を表す新しい正式名称が導入された。Termの概念は、仕様書では以下のように記述されている：

期間とは、ノードの寿命のうち、ノードの構造（すなわち、機能、エレメント、モデル）およびノードのエレメントのユニキャストアドレスが変更されない期間のことである。

新しいタームの開始は、補助センサの取り付けなど、物理デバイスのハードウェア構成の変更をサポートするため、または照明器具内ネットワークへの新しいギアの取り付けなど、ノード上のサブシステム構成の変更をサポートするために必要な場合がある。この変更は、ノードがコンポジション・データ・ページ 128（Mesh プロトコル仕様書 1.1、セクション 4.2.2.4 を参照）に入力することで示され、新しい期間が開始されたときに有効になります。

ネットワーク上のノードの初期期間は、そのノードがネットワーク上にプロビジョニングされたときに始まる。

ノード・アドレス・リフレッシュ（Node Address Refresh）手順またはノード構成リフレッシュ（Node Composition Refresh）手順が実行されると、期間が終了し、新しい期間が開始する（Mesh Protocol Specification 1.1、セクション3.11.8を参照）。

ネットワーク上のノードの最終期間は、そのノードがネットワークから削除された時点で終了する。

2.7.7.3 モデル層

Bluetooth Mesh 1.1 プロトコル仕様のセクション3が拡張され、モデルレイヤーとモデルの使用に関する規則と推奨事項を定義するセクション3.8が追加された。

2.7.7.4 IV インデックス回復手順とサブネット

IVインデックス回復手順を説明する文言が改善され、サブネットを明示的にカバーするようになった。

3.Bluetooth Mesh デバイスプロファイル

Bluetooth^® Mesh テクノロジーは、多くの照明およびセンシング・アプリケーションを実装するための豊富な機能とオプションを提供します。このため、Bluetooth Mesh は、スケーラブルな業務用および産業用アプリケーションに好まれる技術としての地位を確立しています。しかし、Bluetooth Mesh の機能はオプションであるため、実装者が選択した製品セグメントに対してどのオプションを選択するかを決定しなければならない場合、実装者にとって課題となることがあります。同じ製品セグメントで活動するベンダーが、他の同業他社の製品とうまく機能しない異なるオプションのセットを選択した場合（たとえば、電球用に選択されたmesh 機能は、照明スイッチ用に選択された機能とは互換性がない）、製品のエコシステムが相互運用されない状況が生じ、ユーザーエクスペリエンスが低下する可能性がある。

この問題に対処するため、Bluetooth SIG は、Bluetooth Mesh デバイス・プロファイルという概念を導入した。これらのプロファイルは、mesh 仕様の新しいクラスである。デバイスプロファイルは、mesh 仕様のどのオプションや機能がある種の最終製品に必須であるかを定義する。mesh デバイス・プロファイルの最初のスイートは、以下で説明する照明システム・アーキテクチャに基づいています。 センサー駆動型照明制御システムの構築Bluetooth Meshホワイトペーパーに記載されている照明システム・アーキテクチャに基づいている。これらのプロファイルはまとめてBluetooth Networked Lighting Control (NLC) Profilesと呼ばれ、以下のように定義されている：

Ambient Light Sensor NLC Profile (ALS) 1.0- 環境光レベルセンサー。
ベーシック・ライトネス・コントローラ NLC プロファイル（BLC）1.0- コントローラ内蔵の照明器具を表す。
ベーシックシーンセレクターNLCプロファイル（BSS）1.0- 照明シーンの選択や照明のオン／オフを行う壁スイッチまたは壁ステーションを表します。
調光コントロールNLCプロファイル（DIC）1.0- 壁面のスライダー、ダイヤル、またはスイッチの長押し機能を表し、照明を上下に調光します。
Energy Monitor NLC Profile (ENM) 1.0- エネルギー消費量を報告するセンサー。
占有センサ NLC プロファイル（OCS）1.0- 占有センサを表す。

このトピックの詳細については、Bluetooth Networked Lighting Control（NLC）のウェブページを参照してください。

4.結論

本稿で説明する機能強化は、Bluetooth^® Mesh テクノロジーを実世界に幅広く展開した経験から得られたものであり、非常に大きな価値を提供するものである。

Bluetooth Mesh は6年前にリリースされて以来、数多くのプロジェクトが完了し、世界中のビルをよりスマートでエネルギー効率の高いものにしてきた。開発者、メーカー、インテグレーター、設置者、メンテナンス・チーム、ビル運営者は貴重な経験を積み、Bluetooth Mesh テクノロジーの改善に貢献してきた。

本稿で紹介するBluetooth Mesh の機能強化は、異例のことを実現している。この新機能は、使いやすさと低所有コストで高いセキュリティを実現する。Bluetooth Mesh を導入するビジネス・ケースと技術ケースは、かつてないほど強力になった。

Bluetooth Mesh 機能強化の概要