つれづれ日記
Networkカテゴリ 66/66
Bluetooth Core v5.0 - 2.3.2 Scanning PDUs。

AdverisingチャネルのPDUタイプ

  • SCAN_REQ
  • SCAN_RSP
  • AUX_SCAN_REQ
  • AUX_SCAN_RSP

SCAN_REQとAUX_SCAN_REQはまとめてスキャン要求PDUと呼び、PDU形式は同じ。SCAN_RSPとAUX_SCAN_RSPはまとめてスキャン応答PDUと呼び、PDU形式は異なる。

スキャン要求のペイロード

SCAN_REQとAUX_SCAN_REQはまとめてスキャン要求PDUと呼ぶ。
  • AdvertiseチャネルPDUヘッダーのTxAdd: ScanAフィールドにあるスキャン者のアドレスタイプがpublic (TxAdd = 0) か random (TxAdd = 1)かを示す
  • AdvertiseチャネルPDUヘッダーのRxAdd: AdvAフィールドにあるアドバイタイズ者のアドレスタイプがpublic (RxAdd = 0)かrandom (RxAdd = 1)を示す
  • ペイロードはScanAとAdvAからなる。どちらも6 オクテットの長さ
  • ScanAフィールドはスキャンする側のpublicまたはrandomデバイスアドレスである (shall)
  • AdvAフィールドは、このPDUが指定するデバイスのアドレスである (is)
  • AdvAフィールドは(スキャン要求に応答して)アドバタイズする側のpublicまたはrandomデバイスアドレスである (shall)

SCAN_RSP

  • SCAN_RSP PDUは2つのペイロードは2つのフィールドからなる
    • 1つめは6オクテットのAdvAフィールド
    • 2つめは0 - 31オクテットのScanRspDataフィールド
  • AdvertiseチャネルPDUヘッダーのTxAdd: AdvAフィールドのアドレスタイプがpulic (TxAdd = 0)か random (TxAdd = 1)かを示す
  • (AdvertiseチャネルPDUヘッダーの?)"長さフィールド"はペイロードの大きさをオクテット長で示す
  • AdvAフィールドはアドバタイズする側のpublicまたはrandomデバイスアドレスを含める (shall)
  • ScanRspDataフィールドはアドバタイズする側のホストデータを含めてよい (may)

AUX_SCAN_RSP

  • AUX_SCAN_RSP PDUはSection 2.3.4で説明する「共通アドバタイズ拡張ペイロード形式」を使う: Common Extentded Advertising Payload Format (CEAPF)
  • AdvModeはビット列で 00b にすること (shall)
  • AUX_SCAN_RSP PDUで使えるCAEPFのフィールドはTable 2.8にある (必須順)
    • AdvA: 必須 (M)
    • AdvData: 必須 (M)
    • AuxPtr: オプション(O)
    • TxPower: オプション (O)
    • ACAD: オプション (O)
    • TargetA: 禁止 (X)
    • ADI: 禁止 (X)
    • SyncInfo: 禁止 (X)

リアクションについてはBluetooth Speciffication Verion 5.0,Vol. 6, Part B, Link Layer Specification, Page 2608, 4. Air Interface Protocol,4.4 Non-Connected Statesにある。

非接続状態

非接続状態(Non Connected States)。ブロードキャストと、その応答は4つの状態からなる。
  • 4.4.1 スタンバイ状態: Standby State
  • 4.4.2 アドバタイズ中状態: Advertising State
  • 4.4.3 スキャン中状態: Scanning State
  • 4.4.4 開始中状態: Initiating State

... (中略) ...

4.4.3 スキャン中状態

スキャン中状態: Scanning State。スキャンする側をスキャナー (scanner)と呼ぶ。
  • ホストから指示された (directed)とき、リンクレイヤはスキャン中状態 (Scanning State)に入る (shall)
  • スキャン中状態ではリンクレイヤはまず、プライマリアドバタイズチャネルを聞く (listen, shall)
  • スキャンには2つのタイプがあり、ホストが指定する
  • スキャンの2タイプはパッシブ (passive)とアクティブ (active) である

  • スキャンにはタイミングの制限はない
  • スキャンにはアドバタイズチャネルインデックスの選択ルールはない

  • スキャン中、リンクレイヤはプライマリアドバタイズチャネルインデックスを聞き(listen)、scanWindowの間スキャンする
  • スキャン間隔時間のscanIntervalは2つのスキャンウィンドウの開始の間隔として定義されている

  • リンクレイヤはホストから指示があると、scanInterval間隔でscanWindowの間すべてで聞く(listen, shall)。ただしスケジューリングに競合があれば聞かなくてよい
  • 各スキャンウィンドウ内では、リンクレイヤは異なるプライマリアドバタイズチャネルインデックス上でスキャンする (should)
  • リンクレイヤはすべてのプライマリアドバタイズチャネルインデックスを使う (shal)

  • scanWindowとscanIntervalパラメーターは40.96 秒未満である (shall)
  • scanWindowはscanInterval以下である (shall)
  • scanWindowとscanIntervalをホストが同じ値に設定したとき、リンクレイヤは継続的にスキャンする (should)

  • スキャナーフィルタポリシー (scanner filter policy)を適用するのは(shall)、スキャン中にアドバタイズPDUかスキャンPDUを受信したときである

  • AuxPtrフィールドがあるPDUを受信したときは、スキャナ― (scanner)はAuxPtrで指定された補助(auxiliary)PDUを聞く (listen, should)
  • AuxPtrフィールドで指定されたPHY (物理層)で、動作対応するPHY

  • スキャナーがADV_EXT_IND PDUを受信し、AuxPtrフィールドが含まれているときは、スキャナ―は常に補助パケットを聞いてよく(listen, may)、場合によって聞かずに飛ばしてよい (skip, may)。
  • 聞かずに飛ばすときは以下の要件に従うこと (shall)。アドバタイズ中SID値を受信するごとに:
    • コントローラー (Controller)は 1つ以上の直近のAdvertising DID値のキャッシュを保持する (shall)。Advertising DID値はアドバタイズするデバイスごとに利用される値である。
    • この目的のため、すべての「匿名アドバタイズ (anonymous advertising)」は単一のデバイスからすべての実デバイスへのものとして扱われる
    • コントローラーがキャッシュを更新するのは受信したPDUにADIフィールドが含まれているときである (shall)
    • コントローラーはいつでも、どのキャッシュを削除してもよい (may)
    • コントローラーはADV_EXT_IND PDUの完全な受信に失敗したときは、このPDUに関連したキャッシュエントリを削除しなければならない (should)
    • コントローラーが補助パケットを聞くのをスキップしてよい(may)のは、キャッシュにアドバタイジングDID値が指定されているときである。アドバタイジングDID値は、デバイスによって使われるADIフィールドにある
    • ADV_EXT_IND PDUがAdvAフィールドを含むときは、その(cache の?)エントリはそのデバイスのためのものである (shall)
    • 上記以外では、コントローラーが聞くのをスキップしない (shall)
    • コントローラーがAUX_ADV_IND PDUを聞く条件は、他のアドバタイズ者が同じAdvertising DID値を使い始めたときである (should)
  • リンクレイヤプライバシーが有効であるときは、Section 6.3の要求も満たすこと (shall)

4.4.3.1 パッシブスキャン中

  • パッシブスキャン中は(passive scanning)、リンクレイヤはパケットの受信だけを行うはず(? 受信しなくてもパッシブスキャン?) (will)
  • リンクレイヤはどのパケットも送信しない (shall)

4.4.3.2 アクティブスキャン中

  • アクティブスキャン中、リンクレイヤはアドバタイズPDUを聞き(shall)、(受信した)アドバタイズPDUタイプによってアドバタイズ者に追加の情報を送信するようリクエストしてよい (may)

  • スキャン中状態に入ったあと、リンクレイヤがスキャナフィルターポリシーで許可されたアドバタイズ者からスキャンPDU (scannable PDU)を受信したときは、リンクレイヤはスキャンリクエストPDUを応答し(shall)、スキャン応答PDUを聞く (listne に助詞なし)
  • スキャンPDU (scannable PDU)とは、ADV_IND, ADV_SCAN_INDまたはscannableな AUX_ADV_IND PDUのどれかである
  • (スキャンリクエストを応答した)リンクレイヤはスキャン応答PDUを受信成功するまで、同じアドバタイズ者に応答を継続する (shall)
  • 同じアドバタイズ者からの後続のscannable PDUについては、(スキャンリクエストを応答した)リンクレイヤは応答しても無視してもよい (may)
  • (スキャンリクエストを応答した)リンクレイヤはレガシーPDUを無視する (should)
  • (スキャンリクエストを応答した)リンクレイヤは、同じアドバタイズ者から同じAdvertising SIDフィールドで最後のアドバタイズAdvertising DIDフィールドに変更がないときは無視する (should)
  • 上記以外はリンクレイヤは無視しない (should)

  • リンクレイヤがアドバタイズ者にスキャン要求 PDU (SCAN_REQ PDU)を送ってよいのは、ADV_IND PDUかADV_SCAN_IND PDUを受信した相手だけである (shall)
  • リンクレイヤがアドバタイズ者に補助スキャン要求 (AUX_SCAN_REQ PDU)を送ってよいのは、scannableな AUX_ADV_INDを受信した相手だけである (shall)
  • リンクレイヤがscannableなADV_EXT_INDかAUX_ADV_IND PDUを無視してよいのは、TargetAフィールドがあり、TargetAフィールドがリンクレイヤのデバイスアドレスと異なるときだけである (shall)

  • スキャン者はバックオフ手順(backoff procedure)を実行して(shall)、複数のスキャン者からのスキャン要求PDUの衝突を小さくする
  • このような手順の例を、以降の節で説明する
  • バックオフ手順は2つのパラメーター、backoffCountとupperLimitを使い、スキャン応答PDUの衝突時に、送信するスキャン要求PDUの数を制限する
  • スキャン中状態に入る際は、upperLimitとbackoffCountは1にセットされる (例のため助詞なし)

    スキャナフィルターポリシーで許>可されたアドバタイズ者からADV_IND, ADV_SCAN_IND, scannable AUX_ADV_IND PDUを受信するごとに、またはスキャン要求PDUが送信されるごとに、backoffCountは1減算され、0になるまで続ける

  • スキャン要求PDUが送信されるのは、backoffCountがゼロになったときだけである

  • スキャン要求PDUを送信したあとリンクレイヤはアドバタイズ者からのスキャン応答PDUを聞く (実装例のため助詞なし)
  • アドバタイズ者からスキャン応答PDUが受信されないときは(詳細なし)、失敗したとみなす
  • そうでないときは成功したとみなす
  • 2回連続で失敗するごとに、upperLimitを倍にして値が256になるまで続ける
  • 2回連続で成功するごとに、upperLimitを半分にして1になるまで続ける
  • スキャン応答PDUの受信成功または受信失敗のあと、リンクレイヤはbackoffCountを新しい疑似乱数整数で1からupperLimitの範囲内に設定する

  • あるデバイスが異なるバックオフアルゴリズム (procedureではなく?)を使う場合、(異なるバックオフアルゴリズムを使うデバイスは?) it shall share the medium responsibly

  • アドバタイズイベントの2つの図、Figure 4.8と Figure 4.9は、すべてのアドバタイズチャネルインデックスを使って、SCAN_REQ PDUを受信、SCAN_RSP PDUを送信している。

4.4.3.3 アドバタイズデータセット

  • ADV_EXT_IND PDUには、ADIフィールドを含めてもよい (may)
  • ADV_EXT_IND PDUにADIフィールドがあるとき、ADIフィールドを同じセットに属するアドバタイズデータを識別するために利用できる
  • (同じセットは)ADIの中のAdvertising SIDサブフィールドで指定される
  • Advertise SIDはアドバタイズ者のホストから指定される

4.4.3.4 周期アドバタイズ

  • AUX_ADV_IND PDUにSyncInfoフィールドがあるとき、(それを受信した)スキャン者 (scanner)はホストから指示があれば、SyncFieldフィールドに指定されたAUX_SYNC_IND PDUを聞く(listen, 助詞なし)
  • その後スキャン者 (scanner)はAUX_SYNC_IND PDUを聞き続け(should)、チャネルはSection 4.4.2.1で指定されるセカンダリアドバタイズチャネルインデックスである

  • スリープクロックの精度のため(Section 4.2.2参照)、スキャン者(scanner)はSection 4.5.7で指定されたウィンドウ拡幅を実行する(should)
  • ... AUX_SYNC_IND PDUを含むパケットによって置き換えられた接続イベントによって

  • SyncInfoの同期パケットオフセット (Sync Packet Offset)がゼロのとき、スキャン者(scanner)は後続のアドバタイズを聞き(should)、周期アドバタイズ (periodic advertisement)を特定(locate)する
  • スキャン者(scanner)のリンクレイヤは、周期アドバタイズで受信したアドバタイズデータをホストに報告 (report)する (shall)
  • スキャン者(scanner)はすでに同期している周期アドバタイズには同期しようとしない(shall)

4.4.3.5 アドバタイズレポート

  • アドバタイズ者 (advertiser)からのおのおのの複製ではないアドバタイズとスキャン応答 PDUについては、リンクレイヤはアドバタイズレポートをホストに送信(send)する (shall)
  • しかし、コントローラーがADV_EXT_IND PDUをAuxPtrフィールドつきで受信したとき、(コントローラーは)レポートを遅らせて、(AuxPtrに)対応するAUX_ADV_IND PDUの受信を待ち、そ(れら?)のPDU内の情報を結合して(combine)(ホストに)レポートする(shall)
  • コントローラーが聞かない(listen)か、AUX_ADV_IND PDUを受信しなかったときは、(最初のADV_EXT_IND PDUを含めて)レポートを生成しない (shall)
  • アドバタイズレポートは少なくともアドバタイズ者(advertiser)のデバイスアドレスを含み(shall)、(少なくともの範囲外?)アドバタイズデータか、あればスキャン応答データを含む。
  • ホストはフィルタされたアドバタイズレポートとして重複したものを要求してよい (may)

  • 受信されたADV_EXT_IND PDUがADIフィールドを含むとき、ある重複したアドバタイズレポートは同じデバイスアドレスに対する、前回のレポートと同じAdvertising SIDのADI値を含み、同じAdvertising DIDのものである。
  • そのため、すべての匿名アドバタイズ (anonymouse advertising)はある一つのデバイスからすべての非匿名デバイスへのアドバタイズとして扱われる

  • ADV_EXT_IND PDUがADIフィールドを含まないかレガシーPDUが受信された場合、ある重複したアドバタイズレポートは同じデバイスアドレスについてリンクレイヤがスキャン中状態 (Scanning State)のままのアドバタイズレポートである(助詞なし)

  • (どの?)どちらの場合も、実際のデータは変わるかもしれない (may)
  • アドバタイズデータまたはスキャン応答データは重複したアドバタイズレポートだと判定された場合は特段の意味はなくなる
Networkカテゴリ 66/66