コミッション対象の検出
コミッショニング可能の検出はコミッショニングの前に行われ、コミッショニング可能なノードの検出と識別のプロセスを指します。コミッション対象のノードは、次の 3 つの方法で自分自身を宣伝できます。
- Bluetooth 低エネルギー（BLE）
- Wi-Fi Soft AP
- IP ネットワーク上の DNS-SD（既存の IP ネットワークとも呼ばれます）
どちらの方法でも、コミッション対象ノードは 表 1 に示す情報をアドバタイズします。
| フィールド | 長さ | 必須 |
|---|---|---|
| 弁別子 | 12 ビット | はい |
| ベンダー ID | 16 ビット | いいえ |
| 商品 ID | 16 ビット | いいえ |
| 拡張データ | 可変 | いいえ |
Matter 仕様では、ベンダー ID と商品 ID は必須ではありませんが、含めることができます。識別子は必須であり、複数の同一デバイスが同時に接続されている場合に正しいデバイスをプロビジョニングするために、設置プロセス中に重要です。拡張データは、ベンダー固有のカスタム情報をエンコードするために使用できます。
多くのデバイスは、電源投入後、短時間（3 ～ 15 分程度）アドバタイズを行います。他のデバイスは、プライマリ コントロールがファブリックから発信されていないか、ロックなどのデバイスの自動プロビジョニングされていないアドバタイズが安全でないため、アドバタイズを開始してはなりません。表 2 に、この動作の概要を示します。
| デバイスの主な機能 | 自動通知 |
|---|---|
| ロックとバリアのアクセス デバイス | いいえ |
| ほとんどの制御は生地から行われます。たとえば、スイッチや電球などです。 | はい |
| ほとんどの制御は、ファブリックから発生するものではありません。（食器洗い機、冷蔵庫など）。 | いいえ |
Bluetooth Low Energy
この広告モードでは、コミッショナーに BLE 広告が表示されます。委任者は、汎用アクセス プロファイル（GAP）ペリフェラル インターフェースを実装し、委任されていない状態を定期的にアドバタイズする必要があります。デバイスの電源を入れた後の最初の 30 秒間は、広告の頻度を高くする必要があります（20 ～ 60 ミリ秒の間隔）。
30 秒経過すると、デバイスは 150 ～ 1,500 ミリ秒の間隔で低頻度でアドバタイズする必要があります。最初のファブリックに委任されると、デバイスは BLE アドバタイズを停止する必要があります。
コミッショナーはスキャン リクエストを発行する必要はありません。3 つの BLE アドバタイズ チャネル（37（2,402 MHz）、38（2,426 MHz）、39（2,480 MHz））でパッシブ スキャンを行う必要があります。これらのチャンネルは、Wi-Fi チャンネルとの重複を最小限に抑え、無線干渉を最小限に抑えるように、スペクトルの領域から選択されます。
BLE は運用上の検出には使用されません。
Wi-Fi Soft AP
Wi-Fi ソフト AP を使用する場合、委任先はアドホック ソフトアクセス ポイント（ソフト AP）ネットワークを介して検出されます。ネットワークの SSID（ネットワーク名）は MATTER-ddd-vvvv-pppp の形式です。ここで、
- ddd は 16 進数の 12 ビット識別子です。
- vvvv は 16 ビットのベンダー ID（16 進数）です。
- pppp は 16 ビットのプロダクト ID（HEX）です。
コミッショナーがコミッショネアに接続するたびに、両方で一意の IPv6 リンクローカル アドレスが構成され、Wi-Fi レイヤでの接続が可能になります。この時点で、次のセクションで説明する DNS-SD メソッドの場合と同様に、検出が続行されます。
さらに、Wi-Fi ソフト AP は、IPv4 用の DHCP と情報要素（IE）を実装して、ベンダー固有の追加情報を公開できます。IE は、802.11（Wi-Fi）管理フレーム内の可変長フィールドで、カスタム情報を他のシステムに転送できます。
コミッショナー スキャンでは Wi-Fi チャンネル 1、6、11 を優先する必要がありますが、現地のスペクトル規制で許可されているすべてのチャンネルをスキャンする必要があります。
Wi-Fi ソフト AP は運用上の検出には使用されません。
DNS-SD
この場合、委任先は、ノードによってレンダリングされるサービスに関する情報が含まれるドメイン名サービス - サービス ディスカバリ（DNS-SD）アドバタイズによって検出されます。DNS-SD の詳細については、RFC 6762 をご覧ください。これは、次の場合にデバイスを検出する一般的な方法です。
- 委任先はイーサネットに接続されているため、暗号化されていないネットワーク メディアに物理的にアクセスできます。
- 委託先が、帯域外の方法で Wi-Fi ネットワークまたは Thread ネットワークに参加している。
- 委任先はすでに別のファブリックに委任されており、Wi-Fi/Thread ネットワークに参加しています。この場合、委任先は BLE アドバタイズを使用したり、ソフト AP を作成したりできません。したがって、すべてのセカンダリ ファブリックはこの方法でプロビジョニングされます。
Thread デバイスは DNS-SD を直接使用せず、代わりに Thread 境界ルーターが提供するプロキシ メソッドを使用します。この方法は、DNS-SD サービス登録プロトコルとその広告プロキシによって定義されています。Thread デバイスは、通常は Thread 境界ルーターで提供される SRP サービスに登録します。このサービスは、登録された各 Thread ノードの代わりに mDNS トラフィックを処理します。これらのプロトコルによって生成された追加トラフィックを Thread ネットワークに負担をかけることなく処理します。
デバイス検出の DNS-SD インスタンス名は _matterc._udp で、ホスト名は 48 ビットの MAC アドレスまたは 64 ビットの MAC 拡張アドレス（A5F15790B0D15F32.local. などの 16 進数文字列で表されます）で作成されます。通常、このレコードは、委任者が委任される可能性がある場合にのみ公開されます。ただし、コミッショニング モード以外でも広告掲載が継続される場合があります。この動作は拡張検出と呼ばれます。
検出後、IPv6 アドレスは AAAA レコードで返され、キーと値のペアは DNS-SD TXT レコードで返されます。Key-Value ペアには、識別子、ベンダー ID、プロダクト ID などの情報が含まれます。このノードは、コミッション サブタイプもアドバタイズします。これにより、結果をフィルタして、特定の属性に一致するコミッショナーのみを検索できます。
運用上の検出
運用上の検出は、導入済みのノードを検出して識別するプロセスです。運用上の検出は、IP ベースの DNS-SD メソッドでのみ行われます。ノード インスタンス名は、64 ビットの圧縮された Fabric ID と 64 ビットのノード ID で構成されます。これらの ID は 16 進数でハイフンで連結されます（2906C908D115D362-8FC7772401CD0696.local. など）。運用上の検出は、DNS-SD デバイス検出と同じターゲット ホスト名を共有します。
DNS-SD サービスタイプは _matter._tcp です。_tcp という名前付けが使用されていますが、デバイスは UDP などの他のトランスポートを使用している場合があります。