ブルートゥース®メッシュ機能 強化の概要

ブルートゥース®メッシュ機能 強化の概要

リリース： 1.0.0
文書バージョン：   1.0
最終更新日： 2023年9月19日
著者：   

マーティン・ウーリー、BluetoothSIG
Szymon Slupik, SILVAIR Inc.
オムカー・クルカルニ、ノルディック・セミコンダクター
ハンヌ・マレット、シリコンラボ
デイモン・バーンズ、BluetoothSIG

改訂履歴

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 Profile Specificationは名称が変更され、Bluetooth Meshと呼ばれるようになりました。 プロトコル仕様と呼ばれるようになりました。本書および関連論文では、バージョン1.1仕様に言及する場合はこの名称を使用しますが、バージョン1.0仕様については引き続きBluetooth Mesh プロファイル仕様と呼びます。

 

1.はじめに

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

Bluetooth Meshに初めて触れる方は、まずBluetoothSIG 論文「Bluetooth Mesh Networking - An Introduction for Developers」をお読みください。

Mesh 1.1またはBluetooth Mesh 1.1という用語は、Bluetooth Mesh ProtocolまたはModel Specification Version 1.1の略称として使用されることがあり、同様にMesh 1.0またはBluetooth Mesh 1.0という用語は、Bluetooth Mesh Profile Specification Version 1.0の略称として使用されることに注意してください。

2.ブルートゥース® メッシュの新機能

2.1 ブルートゥース・メッシュ・ディレクテッド・フォワーディング

Bluetooth Mesh Managedフラッディング 知られるメッセージ中継方法は、Bluetooth Mesh プロファイルのバージョン 1.0 で定義されました。Bluetooth Meshマネージド・フラッディングは、Bluetooth Meshネットワークにおいて、マルチホップでのメッセージ宛先 効率的、高信頼、柔軟、かつ低メンテナンスで実現します。新しいBluetooth Mesh Directed Forwarding機能 、Bluetooth Mesh Managedフラッディング効率的なマルチホップ・メッセージ配信方法を提供します。

Bluetoothメッシュダイレクトフォワーディングは、ソースからのメッセージのターゲット配信をサービスできるリレーノードのコレクションを確立します。アドレス に宛先 アドレスこれらのリレーノードのセットは、ソースから宛先までのパスを確立します。メンバーシップ パスは、メッセージが意図した宛先に伝播できるノードによってのみ中継されるように配置されている。宛先これにより、ネットワークと無線チャネルをより効率的に利用できるようになります。

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

詳細はBluetooth Mesh Directed Forwarding Technical Overviewを ご参照ください。 を参照してください。

2.2 ブルートゥース・メッシュ・デバイスのファームウェア・アップデート

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

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

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

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

Bluetoothメッシュ・デバイス・ファームウェア・アップデート技術概要 をご参照ください。

2.3 ブルートゥース・メッシュ・リモート・プロビジョニング

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

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

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

Bluetoothメッシュ・リモート・プロビジョニング技術概要 を参照してください。

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

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

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

Bluetoothメッシュ証明書ベースのプロビジョニング技術概要 を参照してください。

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

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

Bluetoothメッシュ・プライベート・ビーコン技術概要 を参照してください。

2.6サブネット

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

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

サブネット 技術概要 を参照してください。

2.7 メッシュの改良

ブルートゥース® メッシュ・テクノロジーには、マイナー・メッシュの改良と総称される多くの小さな機能も追加されています。この見出しに記載されている変更は些細なものですが、場合によっては大きなメリットがあることにご留意ください。以下のセクションでは、各機能強化の概要を説明し、最後にBluetooth Meshの最新情報を記載します。

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

2.7.1.1 背景

プロキシノードは、ブルートゥース® LE （GAPおよびGATT付き）とBluetooth Meshの両方をサポートしています。プロキシは仲介役として機能し、スマートフォンなどのデバイス上のアプリケーションが、プロキシへのGATT接続を介してネットワークとの間でメッシュメッセージを送受信できるようにします。

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

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

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

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

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

2.7.2 パフォーマンスの向上

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

2.7.2.1.1 背景

ブルートゥース® メッシュスタックのアッパートランスポートレイヤー 、1回の送信では長すぎるメッシュAccessメッセージの分割と再組み立てを行うことができる。このようなメッセージはセグメントに分割され、各セグメントは12オクテット長である。個々のセグメントを受信すると、再組み立てプロセスによって元のアクセス メッセージ 再構成される。

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

2.7.2.1.2 SAR構成モデル

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

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

SAR設定サーバ モデルは、特に複数のメーカーのデバイスを含むネットワークにおいて、いくつかの設定タスクのパフォーマンスを向上させるのに役立ちます。

2.7.2.2 メッセージの集約

2.7.2.2.1 背景

一連の異なるタイプの確認応答付きアクセスメッセージが、あるシーケンスで 送信される状況がある。アクセス メッセージ 応答として動作し、通常ステータスコードを含む。例えば、新しいノードのコンフィギュレーション中、AppKeyをモデルにバインドする行為には、多くの確認応答メッセージとそれに関連するステータス応答メッセージが含まれる。

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

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

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

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

2.7.3 複雑なデバイス

2.7.3.1 モデルのメタデータ

2.7.3.1.1 背景

ブルートゥース®メッシュ1.0は、設定サーバ モデルを定義しています。これはすべてのデバイスで実装されているモデルで、コンフィギュレーションと構成データ 多くの状態で含んでいます。

構成データ 構成データ状態は一連のページとして構成されており、それぞれのページは設定サーバ 対応するレスポンスを使って読むことができる。特定のページはページ番号で参照される。特に、コンポジションデータページ0 状態 、ノードが構成される要素を定義し、エレメント 定義は、エレメント サポートするモデルを示す。

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

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

2.7.3.1.2 モデルのメタデータ

ブルートゥース® メッシュには、モデル・メタデータの概念が追加されました。モデル・メタデータは、モデルまたはモデルが何らかの形でその一部であるエレメント 記述する、1つまたは複数のプロパティのシリーズです。メタデータ・アイテムには16ビットの識別子があり、これはBluetoothSIG 割当番号.

Bluetooth Meshに新しいモデルセット、Large構成データ Large構成データ クライアント追加された。サーバーモデルには、Models Metadata Page 0から始まる一連のページで構成されるModels Metadata 状態呼ばれる状態 含まれます。 設定サーバモデルを拡張し、一連のAccessメッセージを定義している。 デバイスキー.

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

2.7.3.1.3 大きな構成データ 値

構成データ 構成データの状態 設定サーバモデルでは、ノードの構成データ データを含む状態 あることに変わりはない。しかし、新しいラージ 構成データ 、オフセットのパラメータ使用して、このデータを一連のデータ部分としてアクセスできるようにするメッセージを定義している。これにより、DALIデバイスのような複雑なデバイスに必要な大規模な構成データ データに対応することができます。

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

2.7.4.1 背景

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

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

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

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

ブルートゥース®メッシュプロトコル仕様バージョン 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 を設定することで「Only OOB authenticated provisioning supported」を示す場合、このアルゴリズムを使用する必要があります。古いデバイスで使用される場合、古いAES-CMACベースのアルゴリズムは引き続きサポートされる。

ブルートゥース® メッシュ・プロトコルでは、プロビジョニング中に非プロビジョニング・デバイ スが認証 要求し、認証なしのプロビジョニング試行を拒否することができる。デバイスは、Provisioning Capabilities PDU の OOB Type フィールドのビット 1 を設定することで、このような認証 要件を示します。

2.7.5 健康障害コード

2.7.5.1 背景

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

2.7.5.2 健康障害コード割当番号移動

ヘルスサーバーモデルで使用されるBluetoothSIG 定義の故障コードは、次のように指定されています。 割当番号を指定しました。これは手続き上の変更であり、BluetoothSIG 製品で使用するための新しい標準フォールトコードを要求するメンバーに、より簡単かつ迅速に対応できるようにするものです。

2.7.6割当番号

BluetoothSIG 、以下のような標準識別番号のデータベースを管理しています。 割当番号.BluetoothSIG 割当番号全リスト。

割り当て番号リストへの追加は、すべてのBluetoothSIG メンバーが利用できる簡単な手続きです。

2.7.7.用語の変更

2.7.7.1 被提供者

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

2.7.7.2 用語

Mesh Protocol Specification 1.1では、デバイスのライフサイクル、構造、コンフィギュレーションを表す新しい正式名称が導入された。用語の概念は、仕様の中で次のように説明されている：

タームとは、ノードのライフタイムにおいて、ノードの構造（すなわち、フィーチャー、エレメント、モデル）とノードのエレメントのユニキャストアドレスが変更されない期間のことである。

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

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

ノードアドレス リフレッシュ手順またはノード・コンポジション・リフレッシュ手順が実行されると、タームが終了し、新しいタームが開始します（メッシュ・プロトコル仕様書1.1のセクション3.11.8を参照）。

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

 

2.7.7.3 モデル層

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

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

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

3.ブルートゥース® メッシュ・デバイス・プロファイル

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

この問題にアドレス するため、BluetoothSIG Bluetooth Mesh Device Profilesというコンセプトを打ち出しました。これらのプロファイルはメッシュ仕様の新しいクラスです。デバイス・プロファイルは、メッシュ仕様のどのオプションや機能がある種の最終製品必須であるかを定義します。メッシュ・デバイス・プロファイルの最初のスイートは、次のページで説明した照明システム・アーキテクチャに基づいています。 ブルートゥース・メッシュに基づくセンサー駆動型照明制御システムの構築ホワイトペーパー（2020年発行）に記載されている照明システム・アーキテクチャに基づいています。これらのプロファイルは総称してBluetoothネットワーク照明制御 （NLC）プロファイルと呼ばれ、以下のように定義されています：

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

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

4.結論

本稿で紹介する機能 強化は、ブルートゥース® メッシュ・テクノロジーによる幅広い実戦配備の経験から得られたものであり、非常に大きな価値を提供するものです。

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

本稿で説明するブルートゥース・メッシュ機能 強化は、非常に珍しいことを実現している。この新機能は、高いセキュリティと使いやすさ、低い所有コストを同時に実現します。Bluetooth Meshを導入するためのビジネスおよび技術的ケースは、かつてないほど強力なものとなっています。