Header image

実運用に耐える非常時アドホックネットワーク

October 2025

非常時アドホックネットワーク(MANET)の研究は、携帯網や有線インフラが失われた際に端末が自律的に組織化されるという期待の下、2000年代初頭に加速した。試作は、再フラッシュした家庭用ルータ、ノートPC中継、Androidのルーティングデーモン、空中リピータに及んだ。AODV、OLSR、BATMAN、DYMOといった多様なプロトコルが提案されたが、人口規模での普及にはほとんど至らなかった。

制約の核心は展開の実現可能性にある。停電・通信断の状況で、誰が、どのハードウェアと権限で、運用できるのか。無線が自己組織化できることを示した研究は多いが、事前準備なしに一般住民が使える体系を提示した例は少ない。実プラットフォームは研究室の前提を阻む。市販スマートフォンはIBSS/802.11s1 2をアプリに公開せず、ベンダ製ルータの純正ファームウェアはOpenWrtやフルLinuxに置き換えない限りメッシュ機能を外すことが多い3。事前インストールアプリ、root化端末、事前フラッシュ済み機材に依存する設計は、利用者が未準備な非常時に破綻する。

IBSSは802.11のアドホックモード、802.11sはWi-Fi MAC層にHWMPルーティングを備えた標準メッシュを追加する。市販端末のAPIは一般に、いずれもアプリへ公開しない。

本稿はこの歴史から教訓を抽出し、アプリ要否独自性ブラウザ接続自律展開長距離の5軸で評価する実現可能性レンズを提示する。任意の端末がキャプティブポータル経由でHTTPを話す最小限のメッシュ基盤を重視する。ネットワークがキャプティブページを通知・提示する方法は標準化され、現行OSはすべて実装している4 5

各ノードはポケットWi-Fiのように振る舞い、端末は近距離で通常のWi-Fi接続を行う。一方、ノード同士のみが別系統の低帯域・長距離無線で相互接続される。

キャプティブポータル(capport)は、DHCP/RAのヒントによりWi-Fi接続時にOSが起動するミニブラウザで、内容はローカルノードのみで配信できる。

技術的成功が展開で失敗しがちな理由

スマートフォンのネットワークスタックはマルチホップに閉じている。 Androidは近距離接続向けにWi-Fi Direct(P2P)を公開するが、一般的なIBSS/802.11sを第三者アプリに提供しない。マルチグループ中継はアプリ層ゲートウェイを介する必要があり、オーバーヘッドが増える。iOSのMultipeer Connectivityも近距離共有向けで、マルチホップルーティングではない2 6。実測レビューでは、製品版Androidのカーネルに802.11sが有効化されていない例が大半と報告される1

制御できるルータではメッシュは機能する。 802.11sは標準化され、Linux/mac80211に実装されている。OpenWrtは対応チップセットでこれを露出する。課題はプロトコル設計より、調達、給電、設置といった運用面に移る3

無線の物理はWi-Fiをスケールで罰する。 屋内や都市峡谷では2.4/5 GHzの到達は1ホップ数十メートルに制限され、単一無線のメッシュはエアタイム競合によりホップごとに実効スループットが低下する。サブGHzはスループットを犠牲にして到達距離とリンクバジェットを得る。画像や音声ではなく、テキストやテレメトリに適合する7 8

利用者オンボーディングが欠けている。 非常時、住民は市販端末で1分以内に接続できなければならない。普遍的な手掛かりはキャプティブポータルのブラウザ起動であり、OSベンダとIETFがこの経路を標準化している4 9 10 5

実現可能性を評価する5軸

アプリ要否。 事前インストールアプリに依存すると、必要時に採用が崩れる。ローカルノードから配信するブラウザUIは、アプリストア、バックグラウンド制約、OS更新の影響を避ける4 9 5

独自性。 閉じた無線や独自プロトコルは単一機関には有用でも、修理、監査、ボランティア増設を妨げる。文書化された標準(802.11s/HWMP)と汎用ハードウェア上のオープンドライバを選ぶ3

ブラウザ接続。 認識しやすいSSIDがキャプティブポータルを起動することが参加への最短経路だ。ローカルページは、テキスト掲示板、SOS、安否報告、状態表示をインターネット不要で提供できる4 9 10 5

自律展開。 ハードウェアは市販部品(Raspberry Pi/OpenWrtクラス、またはLPWANモジュール)で組め、USB/太陽光で給電でき、オフライン設定が可能であるべきだ。ノードは自動的に近隣を発見し、無操作でポータルを提示する必要がある。

長距離。 疎な被覆にはサブGHzのバックホールが要る。LoRa系リンクは約0.3–50 kbpsで高感度を提供し、都市環境でもキロメートル級の到達が報告される。画像や音声は任意・局所に留め、ストア&フォワードのテキストを優先する11 7 8

「LoRa系」はサブGHzのCSS無線を指し、ペイロード速度は約0.3–50 kbpsで高リンクバジェットを持つ。遅延耐性のあるテキスト/テレメトリ向けで、リアルタイム媒体には不向き。

これらの軸で高得点の体系は、研究室外でも生き残る。最初の3軸で失点する体系は、利用者に届かないことが多い。

ブラウザ中心のメッシュ基盤

実用的な構成は、端末のブラウザを中心に据え、複雑さを背後に隠す。

  • バックホール無線。 サブGHz(例: LoRa/LoRa系)で小さなパケットを堅牢に長距離ストア&フォワードする。遅延は秒〜分、デューティ制限があるため、メッセージサイズと送信間隔を設計に反映する11 8
  • アクセスエッジ。 各ノードは2.4 GHzのWi-Fi AP(例: SSID「Emergency-Local」)も提供する。関連付け時にキャプティブポータルを広告し、最小の単一ページアプリ(掲示板、短文、SOS、ローカル状態)を配信する。端末は通常のクライアントモードのまま4 9 5
  • 可能な範囲でのメッシュ容量。 固定ノード間では、ファームウェアとドライバを制御できる場合に、Ethernetや802.11sで高レートのローカルバックホールを用いる3
  • ルーティング規律。 単純で分断耐性のある方式(確認付きストア&フォワード、遅延耐性キュー)を選ぶ。端末OSの中継に依存しない。端末はクライアントとして扱い、メッシュルータにしない2 6
  • 運用。 印刷可能な手順を公開し、公共施設に少数のノードを事前配置する。BOMからボランティアが追加ユニットを組めるようにする。
「ストア&フォワード/遅延耐性」は、ノードがメッセージをキューし、機会的に中継、確認応答と再送を行うことを意味する。分断や分単位の遅延を前提とし、音声・映像のリアルタイム用途ではない。

この方法は、端末が一般的なメッシュモードをアプリに公開しないという制約を受け入れ、誰もが学習済みの操作——キャプティブポータルのブラウザ——を活用する。

設計判断を導くエビデンス

  • スマートフォンOSの制限は安定している。 Androidの公開APIはWi-Fi Directに限定され、マルチホップはアプリゲートウェイを要しオーバーヘッドが生じる。iOSのMultipeerも近距離交換に限定される2 6
  • スタックを所有すればルータのメッシュは成熟している。 Linux/mac80211は802.11s(HWMP)を実装し、OpenWrtは対応チップで利用可能3
  • キャプティブポータルのUXは標準化済み。 RFC 8952がアーキテクチャを定義し、RFC 8910と関連作業がDHCP/RAの通知を規定する。OS文書は検出と利用フローを説明する4 9 10 5
  • サブGHzのトレードオフは研究間で一貫する。 ベンダ資料と査読測定は、都市でもキロメートル級の到達と極低スループットに収束し、短文とテレメトリに適合する11 7 8

計画者・構築者への提言

エッジはインストール不要で設計し、端末はクライアントに留め、ペイロードはサブGHzの枠に合わせ、給電と設置を見積もり、コミュニティが自律展開できるようオープンなイメージ/BOMを公開する。評価指標は、市販端末を持つ未訓練の住民が最初のメッセージに到達するまでの時間とする。


  1. Soares, E., et al. Experimentation with MANETs of Smartphones. Wireless Days 2017, extended version (PDF). https://www.dcc.fc.up.pt/~rprior/homepage/pubs/WirelessDays2017.pdf  ↩︎ ↩︎

  2. Android Developers. Wi-Fi Direct (P2P) overview/APIs. https://developer.android.com/develop/connectivity/wifi/wifip2p  ↩︎ ↩︎ ↩︎ ↩︎

  3. Linux Wireless docs. IEEE 802.11s — mac80211 implementation (HWMP). https://wireless.docs.kernel.org/en/latest/en/developers/documentation/ieee80211/802.11s.html  ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. RFC 8952. Captive Portal Architecture. RFC Editor. https://www.rfc-editor.org/rfc/rfc8952  ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  5. Microsoft Learn. Captive Portal Detection and User Experience in Windows. https://learn.microsoft.com/en-us/windows-hardware/drivers/mobilebroadband/captive-portals  ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  6. Funai, C., Tapparello, C., Heinzelman, W. Enabling Multi-hop Ad Hoc Networks Through Wi-Fi Direct Multi-Group Networking. IEEE ICNC 2017 (PDF). https://www.hajim.rochester.edu/ece/sites/tapparello/papers/Tapparello_ICNC2017.pdf  ↩︎ ↩︎ ↩︎

  7. Griva, A. I., et al. LoRa-Based IoT Network Assessment in Rural and Urban Scenarios. Sensors 23(3):1695 (2023). https://www.mdpi.com/1424-8220/23/3/1695  ↩︎ ↩︎ ↩︎

  8. Semtech. Predicting LoRaWAN Capacity (technical note, PDF). https://www.semtech.com/uploads/technology/LoRa/predicting-lorawan-capacity.pdf  ↩︎ ↩︎ ↩︎ ↩︎

  9. RFC 8910. Captive-Portal Identification in DHCP and Router Advertisements. RFC Editor. https://www.rfc-editor.org/rfc/rfc8910  ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  10. IETF CAPPORT Working Group. Documents and status (includes RFC 8908, 8910, 8952). https://datatracker.ietf.org/group/capport/  ↩︎ ↩︎ ↩︎

  11. Semtech. LoRa® and LoRaWAN® (white paper, PDF). https://www.semtech.com/uploads/technology/LoRa/lora-and-lorawan.pdf  ↩︎ ↩︎ ↩︎