Meshtastic 災害行動協議：台日跨國作業指南

本協議目的在為東亞地區的 Meshtastic 使用者提供標準化的災時通訊架構。Meshtastic 在本協議中被定義為 「補充性通訊（AUXCOMM）」。其成功關鍵不在於設備或節點的多寡，而在於戰略節點和訊息生命線路徑的確保，以及操作人員是否熟悉這套「代碼-白話文」的轉換機制。

災害發生時，最常見的失敗之一就是試圖傳輸過多資訊。在災害剛發生後的瞬間，發送所有細節是沒有效率的。根據過去的經驗，我們要優先傳送與「拯救生命」直接相關的資訊。我們必須理解在不同階段中，哪些資訊才是該階段應傳輸的重點。

本協議所專注的救災階段就是72小時的黃金救援時期（編按：2014年文），當然在複合的大型災難，這72小時是會根據每一個事件的發生點不同，重複出現和循環。

一、 核心原則與法律架構

在正常的災害期間，通訊必須建立在合規與效率的平衡之上。以下僅舉例。

• 台灣規範： 遵循 NCC 的 LP0002 技術規範（PDF）。頻段需設定為 TW (920-925 MHz)，使用已認證之射頻模組，並在功率限值內進行部署。
• 日本規範： 嚴格遵循《電波法》與 ARIB STD-T108 標準。所有設備必須具備「技適認證」，嚴禁隨意更換高增益天線，並重視「占空比」以避免干擾公共頻率。
• 共同特點： 兩地均強調 「資訊最小化」，在公開頻道中僅傳輸必要代碼，保護個人隱私（詳參日本《個人情報保護法》與台灣《個資法》）。

二、 網路設計與頻寬保護

為了防止網路擁塞，協議對設備角色有明確定義。以下僅舉例。

1. 台灣模式： 考量多山地形，允許在策略性高點佈署中繼節點，但同樣需受控制站（NETCTL）監管，避免過度跳轉導致的封包傳遞效率低落。
2. 日本模式： 由於城市人口密度極高，嚴禁一般用戶開啟 ROUTER 模式。通訊骨幹由核心站點（CLIENT_BASE）構成，跳轉次數（Max Hops）固定為 3。
3. 節點設定： 兩地皆建議關閉 PRIMARY 頻道的自動位置更新，僅在需要定位救援時手動觸發。
4. MQTT 設定：禁止公開 MQTT / 地圖回報。

三、 案件管理與通訊語法（代碼化作業）

本協議採用 「序列號（SEQ）」 系統來克服離網通訊的混亂。以下僅是一種模式的舉例。

• 標語法：[優先級] [案件ID] [SEQ] [狀態] [行動] : [內容] [可靠度]
  • 範例一：
    • 內部 -> [[SOS]] TAIN-Q-20260429-1530 NEW REQ: COL TRP 2PAX 1RED 1YLW. B2 1438J
    • 白話 -> 2026/04/29 15:30，台南地區發生建築物坍塌，共有兩名人員受困。檢傷分類為一紅一黃。訊息可靠度評估等級為 B2。需派遣搜救隊並具備醫療轉運能力
  • 範例二：
    • 內部 -> [[SIT]] SND-S-20260329-1843 S02 RPT: MOB GATE-W GROW. C3 1845J
    • 白話 -> 2026/03/29 18:43 第二報：西門附近的群眾聚集人數正在增加，訊息可靠度評估等級為 C3。
• Liaison（聯絡員）的角色：
  • 台灣： 將代碼轉換為符合「災害應變中心（EOC）」慣用的白話報告，對接消防局、警察局或國軍救災兵力。
  • 日本： 將代碼轉換為符合日本官僚體系的標準公文語法，對接「市役所」與「消防本部」。

聯絡員角色的作業，或許可藉由使用人工智慧服務（如選單、罐頭訊息等）達到「代碼」「白話文」快速轉換，但在核實部分，仍須訓練有素的人員介入。傳統的「勤務指揮中心」有這方面的訓練，但若回報來源往外擴及一層（例如正式的後備、替代役、民防），目前看來是相當的不樂觀。

四、 針對特定災害的應變措施

• 地震與海嘯：
  • 台灣： 核心在於配合災防告警系統 (PWS)，並針對山區土石流風險區域建立中繼鏈路。
  • 日本： 核心在於與 J-Alert 聯動，執行垂直避難導引，且嚴格執行氣象廳解除令。
• 核生化與戰災：
  • 兩地均嚴禁描述軍隊、自衛隊或敏感設施的位置。
  • 通訊重點在於傳遞保護指令（如：SEAL 封閉門窗、HVAC OFF 關閉通風）。

五、 結語：通訊韌性在演練的培力

訓練重點：

1. 無預警演習： 模擬主要電訊中斷下的訊息接力。
2. 跨單位對接： 練習如何精確地將 Mesh 內部的碎片資訊彙整為外部機關可用的情報。
3. 隱私過濾： 確保在公開的無線電頻率中，不洩漏任何受災者的真實身分資訊。

五、 其他

1. 本協議為初步設想討論，未討論其他 Mesh 途徑。
2. 在「案件管理與通訊語法（代碼化作業）」篇幅，在台灣我覺得會遇到很多的問題，但在救災初始階段時必須要精簡正確的利用訊息管道，因此如何發報、核實、解譯和轉換，這要規劃，不能昧於目前台灣的救災作業現實。希望不要想想就不用再想下去了。
3. 另外一個方向是透過跨國合作的設想，發掘台灣在「民力運用」和「民力訓練」的嚴重不足。就算單純化來看台灣，那麼上面的框架發展也很有得想。
4. 這種編碼的方式要不要跟 ARES、ACS & RACES 的方向去靠攏？要討論。但我覺得台灣的公部門目前沒有意願去想這一塊。
5. 實務上在主要通訊途徑陸續恢復後，由於通訊頻寬突然暴增，通訊操作員使用簡潔代碼和透過控制站（NETCTL）監管的誘因會大幅降低。這一點也尚未去設想。