見出し画像
Photo by 123ribbon

Wifiサイドバンド公共情報プロトコル仕様書

新井俊一ひよこ新聞

0. はじめに

OpenAtmos (仮称) は、公共 Wi‑Fi・機内 Wi‑Fi・街区メッシュなどの無線インフラに「暗号化されていないサイドバンド・ブロードキャスト」を設け、時刻・位置・気象等の公共データを誰でもパッシブ受信できるようにすることを目的とした軽量プロトコルである。

1. 背景と目的

  • GPS が届かない室内・機内・地下空間でも、正確な時刻・大まかな位置・気象補正値を取得したいユースケースが増加している。

  • IoT デバイスやセンサーノードの大量設置にともない、低コストかつ電力消費の少ない補正チャネルが求められている。

  • 政府・気象庁など信頼できるソースが署名付きでデータを流すことで、データ改ざんリスクを低減し、アプリ／機器側のクロスチェックにも利用できる。

2. 用語

  • Publisher — 公開ビーコンを送信する無線アクセスポイント運営者

  • Authority — データに電子署名を付与する行政機関または公的団体（例：気象庁）

  • Listener — Wi‑Fi スニファや端末側で OpenAtmos フレームを受信・検証する主体

  • OA-Frame — 本仕様で定義されるペイロード付き Beacon または Probe Response

3. システム概要

  1. Publisher は通常の Wi‑Fi Beacon フレームに Vendor Specific Information Element (IE) を追加し、OA‑Frame をブロードキャストする。

  2. OA‑Frame には「データ部」と「署名部」が含まれる。

  3. Listener は暗号化・認証なしでビーコンを受信し、署名を公開鍵で検証するだけでデータを利用できる。

  4. 高頻度更新が不要な項目（公開鍵ローテーションなど）は OTA または HTTPS 経由で定期取得する前提とし、OA‑Frame 自体は軽量のまま維持する。

4. ペイロード設計（概念図）

  • ヘッダ：バージョン、ペイロード長、CRC

  • データ部（可変長）

    • Unix Epoch 秒（32bit）

    • 緯度・経度（各 24bit 固定小数点、±90°/±180°範囲）

    • 高度 or 気圧（16bit）

    • 気温（8bit、−40〜+85℃ を 0.5℃ 刻み）

    • 湿度（8bit、0〜100%）

    • 風速・風向など拡張 TLV

  • 署名部

    • 署名アルゴリズム識別子（例：Ed25519=0x01）

    • 署名（固定長 64byte）

5. セキュリティモデル

  • 送信フレームは暗号化しない。

  • 改ざん防止は署名の検証によって担保。

  • 時刻や天候など、政府から発信されるデータを署名する。街区などに設置される公共Wifiでは、位置情報も署名する

  • テナントビルや自宅などでは、自分の公共鍵で署名したデータを配信し、署名のハッシュを検証して、信頼するかどうかを決めることができる

  • 署名されていないデータは参考情報として扱う

  • OA‑Frame による個人情報流出は想定しないが、位置精度は 3 桁目まで丸めるなどプライバシー配慮を推奨。

6. 運用シナリオ例

  • 機内 Wi‑Fi：航空会社が Publisher、データは GNSS／機体センサ連携

  • スマートビル：管理者の AP が室温・時刻を配信し、入居テナントの IoT が自動補正

  • 街区公共 Wi‑Fi：自治体が気温・PM2.5・防災情報をブロードキャスト

7. 実装ガイドライン

  1. Beacon Interval 内に収まるサイズを厳守（推奨最大 200byte）。

  2. 送信間隔は最低 1 秒、通常 5〜10 秒毎。

  3. ビーコンチャネルは現行運用を阻害しないよう AP 負荷を確認。

  4. Listener は取得データのキャッシュ有効期限を設け、古い値を破棄。

8. 拡張性

  • TLV（Type‑Length‑Value）方式でデータフィールドを拡張可能。

  • 将来の圧縮スキーム（CBOR・Zstandard 等）を Negotiation Bit で宣言可能。

ちなみに調べてもらったら以下のようなプロトコルが既にあるみたい。めっちゃ普及してほしいなー。

以下に Wi-Fiビーコンで「時刻」や「現在位置」を公開する既存／提案中の仕組みを調べた結果をまとめた。結論として すでに標準化済みの要素が複数存在 し、業界ごと・国ごとに実験／採用例も出ている――ただし普及はまだ限定的だ。

1. 時刻を載せる仕組み

1-1 TSF (Timing Synchronization Function)

  • 802.11 AP はビ―コンに TSF タイムスタンプ を常時載せ、同一 BSS 内でマイクロ秒精度の時刻同期をとる仕組みを持つ。(ウィキペディア)

1-2 Timing Advertisement Frame & IE

  • 802.11p-2010／11-2012 で Timing Advertisement (TA) フレームと Time Advertisement IE が追加。AP が UTC/TAI など外部基準時刻を TSF と併せて配信できる。(How I WI-FI, TUM Info VIII)

  • TA フレームは管理フレームの一種で、標準上は「必須だが送信するのは一部の AP のみ」という扱いになっており、実運用例は少ない。(IEEE 802)

  • 論文・実験では TA を使い 10 ns〜µs級のクロック同期が報告されている。(ResearchGate)

  • Wireshark でも TA 含むビ―コンを解析可能（timestamp フィールドはビ―コン／プローブレスポンス／TA にのみ存在）。(Wireshark Q&A)

2. 位置を載せる仕組み

2-1 LCI / LCR 情報要素

  • 802.11mc（FTM）や 802.11-2016 では LCI (Location Configuration Information) と LCR (Location Civic Report) IE を定義。AP が緯度経度・高度や住所要素を配信できる。商用 AP（Zebra など）が設定項目として実装済み。(Zebra TechDocs)

2-2 ANQP での配信（Hotspot 2.0 / 802.11u）

  • 802.11u/Hotspot 2.0 では GAS/ANQP を使い、接続前に AP へ問い合わせて位置・施設情報を取得できる。多くのエンタープライズ AP が対応。(ウィキペディア, CommScope)

  • ただし ANQP はアクティブ問い合わせ型で、サイドバンドの「常時ブロードキャスト」ではない。

2-3 ベンダー固有 IE での実装例

  • フランスのドローン遠隔識別規制では、GPS 座標・速度などを Wi-Fi ビーコンのベンダー IE に載せて常時送信する方式を法制化。技適不要な読取りが可能で、固定 AP への転用も技術的には容易。(ウィキペディア)

3. 既存仕組みの課題とギャップ

観点 現状課題 普及度 TA フレームや LCI/LCR は標準化済みだが、デフォルト有効の AP は少なくエコシステムが限定的。 セキュリティ ビーコンは暗号化されないため改ざん耐性が弱い。署名付き配信は標準外アプローチが必要。 粒度 位置 IE は固定座標前提。移動体（機内 Wi-Fi 等）では更新頻度・正確性の課題。 データ量 ビーコン IE は 255 B×複数まで拡張できるが、過剰に積むと断片化や消費電力増大が懸念。

4. OpenAtmos への示唆

  1. 標準 IE を再利用／拡張

    • 時刻 ⇒ TA IE を活用し、UTC + 署名フィールド拡張。

    • 位置 ⇒ LCI/LCR + 動的更新拡張（移動体向け）。

  2. 署名フィールドの設計

    • 政府・気象庁 OID でベンダー IE を確保し、Ed25519 など軽量署名を付与。

  3. ビーコン vs. GAS 併用

    • 即時取得が必要な最小データをビーコンに、詳細は暗号化 GAS で配信する二層構造が現実的。

  4. 省電力／混雑対策

    • ビーコン間隔ごとにデータをローテーションしてフレーム肥大を抑制。

参考にした主な情報源

(Time Advertisement: (How I WI-FI, TUM Info VIII, IEEE 802, ResearchGate))
(TSF 基本動作: (ウィキペディア))
(ビーコン timestamp 用途: (Wireshark Q&A))
(位置 IE/LCI/LCR: (Zebra TechDocs))
(ドローン用 GPS ビーコン: (ウィキペディア))
(802.11u/Hotspot 2.0 概要: (ウィキペディア, CommScope))
(802.11p TA 解説: (wiki.freebsd.org))

これらを見る限り、「時刻・位置をサイドバンドで配信する」という発想は既存規格のピースが揃っているが、統一プロファイルがなく普及も限定的。OpenAtmos ではこれらをまとめ上げ、署名とユースケース定義を足すことで“一段上の公共データ放送”として成立しそうや。

いいなと思ったら応援しよう！