Meshtastic 網路頻道會不會太擠的估算

最近在某些討論中，有人問到一個「子網」要有多少節點才不會太擁擠。目前台灣 LoRa 鏈網（Meshtastic）的擁擠與被「濫用」程度有惡化的趨勢，因此部分人開始思考能否自己系統化建立「頻道」，與「公網」做些區隔。這個問題不容易回答，隨便給的數字通常只是權宜之計，所以我們針對這件事做一次估算。預設的讀者對象是自組網（mesh）的規劃和佈署者。

LoRa 無線電像一條大家共用的公共廣播頻道，同一時間只能有一個人講話，講的人太多就會互相蓋台、封包遺失。2026 年台灣首度的「降速演練」，應該讓許多人有體感。

模擬情境：台北某個很熱鬧的地方有 100 個 Meshtastic 節點，每個節點每 10 分鐘回報一次 Meshtastic 原生「位置封包」，看這條頻道會被佔用多少。

結論：用掉約 10％，離安全線還有明顯餘裕

頻道有約 10％ 的時間被佔用。模擬以 25％ 作為規劃目標，這是營運上常見的安全線。10％ 距離 25％ 還有約 15 個百分點，評級是「還有餘裕」：這個規模可以正常使用，也還有成長空間。

---

為什麼會用掉這些

每次傳送約 0.2 秒。Meshtastic 的位置資料約 40 bytes，加上封包標頭等約 20 bytes，總共 60 bytes。這裡用的是台灣 LoRa 鏈網的 MediumFast 預設頻道設定（SF9、250 kHz、CR 4/5），速度偏快，傳一次大約 201 毫秒。

每筆回報會被聽到約 3 次。這是 Meshtastic「洪泛式轉發」（flooding）的特性：節點聽到封包後會再轉發出去，讓更遠的節點也收得到。因此在最繁忙的地點，同一筆位置回報會聽到原始的一份，加上其他節點轉發的約兩份，共約 3 份。每一份都會佔用頻道時間，這是造成頻道負擔放大的主要因素之一。

這裡的 3 是一個假設值，不是固定常數，是較貼近實際的估計；更密集的環境可能更高（7 次可視為偏保守的最壞情況）。實際份數取決於附近節點數量、拓樸、角色設定與跳數（hop limit）。Meshtastic 也有轉發抑制機制：節點在隨機延遲期間若聽到別人已轉發同一封包，就會取消自己的轉發，所以多數地點的重複份數不會太高。另外要注意，這個 3 是「聽到幾份」，與預設的 hop limit 3（最多轉發幾層）是不同的概念，不要混為一談。

算式大致是：

100 個節點 × 3 次 × 0.201 秒 ÷ 600 秒（10 分鐘）≈ 10.05％

這個算式是把 10 分鐘內所有傳送的空中時間加總，再除以總時間。它同時也等於「平均每個封包時間內，頻道上有多少次傳送」，也就是下一節要用的 G 值（已包含轉發，暫稱頻道使用率）。

其他幾個數字的意思

• 25％ 以下最多容納約 248 個節點。 在 10 分鐘回報一次的條件下，節點數到約 248 個才會碰到 25％ 的線。現在 100 個，還有很大的成長空間。
• 25％ 以下最快回報間隔約 4 分 1 秒。 如果維持 100 個節點，回報間隔不能比這個更短。目前設 10 分鐘，比極限慢了將近 6 分鐘，有相當的餘裕。

---

回報間隔對比：5 分鐘、10 分鐘、15 分鐘

其他條件完全不變（100 個節點、每筆 201 ms、聽到 3 次），只改變每個節點的回報間隔：

*ALOHA 為最壞情況的保守參考值，說明見下節。

試算方式

• 使用率：100 個節點 × 3 次 × 0.201 秒 ÷ 間隔秒數。總空中時間為 60.3 秒，5 分鐘（300 秒）得 60.3 ÷ 300 ≈ 20.1％；15 分鐘（900 秒）得 60.3 ÷ 900 ≈ 6.7％。
• 最多節點數：每個節點每次回報佔用約 0.603 秒。25％ 的頻道時間在 5 分鐘內是 75 秒，75 ÷ 0.603 ≈ 124；10 分鐘是 150 秒，150 ÷ 0.603 ≈ 248；15 分鐘是 225 秒，225 ÷ 0.603 ≈ 373。
• 最快回報間隔：60.3 ÷ 0.25 ≈ 241 秒，約 4 分 1 秒。
• ALOHA 參考值：5 分鐘 G ≈ 0.201，e^(−0.402) ≈ 0.67；10 分鐘 G ≈ 0.1005，e^(−0.201) ≈ 0.82；15 分鐘 G ≈ 0.067，e^(−0.134) ≈ 0.87。

白話解讀

• 5 分鐘仍在安全線內，但已接近上限。回報頻率加倍，頻道負擔也跟著加倍，從約 10％ 升到約 20％，只剩約 5 個百分點的緩衝。100 個節點可以撐住，但不太適合再繼續成長。
• 5 分鐘下最多容納約 124 個節點。要維持 5 分鐘回報，節點數就不能超過這個規模，除非同時減少轉發次數或換更快的頻道設定。
• ALOHA 單次傳送成功率在三種間隔下都在 67％ 以上。最壞情況下仍有約三分之二的傳送不被撞掉，頻道壓力屬於可控範圍。
• 15 分鐘則更輕鬆。使用率降到約 7％，100 個節點可以長到三百多個仍在安全線內。
• 「最快回報間隔」三欄都一樣。因為它是頻道本身的極限，回答的是「100 個節點最快能多頻繁回報」，和現在設定幾分鐘無關。5 分鐘與 10 分鐘都比這個極限慢，所以都在安全線內。
• 取捨是位置更新速度。5 分鐘一次，地圖上的移動軌跡最細緻，但頻道最擁擠；15 分鐘一次，頻道最輕鬆，但位置更新較稀疏，常移動的成員可能感覺位置落後。

---

純 ALOHA 參考值：82％（基準試算 10 分鐘）

ALOHA 是什麼

一種「想講就講、不先確認有沒有人在講」的通訊方式。可以想像一間房間裡大家都想說話，但沒有人會先聽一下別人有沒有在說，想到就開口。兩個人剛好同時講，就會互相蓋過，這叫「碰撞」，兩邊的封包都會損失。人越多、講得越頻繁，碰撞機率就越高。

82％ 是怎麼來的

純 ALOHA 有個固定規律：一個封包要成功，它傳送前後各一個封包長度的時間內，都不能有別人在傳，所以「危險時間窗」是封包長度的 2 倍。

在傳送次數服從卜瓦松分佈（Poisson Distribution）的假設下（使用者很多、各自獨立），單次傳送的成功率為 e 的 (−2G) 次方。其中 G 是每個封包時間內，頻道上平均出現的傳送次數，包含轉發與重送。一般情況下 G 可以大於 1；這份模擬沒有既有負載、也沒有額外重送，所以 G 的數值剛好等於頻道使用率。

套用這份模擬的數字（G ≈ 0.10），e^(−0.20) ≈ 0.82，也就是約 82％。

這個數字代表什麼

82％ 是「單次傳送不被撞掉的機率」。它容易和另外兩個數字混淆：

• 並非吞吐量。吞吐量公式是 S = G·e^(−2G)，這裡約為 0.10 × 0.82 ≈ 0.082，意思是約 8.2％ 的頻道時間用在成功的傳送上。順帶一提，純 ALOHA 的吞吐量最大值只有 1/(2e) ≈ 18.4％，出現在 G = 0.5。
• 並非「一筆回報」的送達率。一筆回報最多有 3 份拷貝，只要其中一份被收到就算送達，所以整體送達率會比 82％ 高。不過這 3 份是由同一筆封包觸發轉發的，彼此並不獨立，無法簡單用機率相乘估算。

白話意思：如果所有 Meshtastic 節點完全不管別人有沒有在講，大約八成二的單次傳送能成功，其餘不到兩成會被撞掉。

這僅是保守的參考

• Meshtastic 發送前會先偵測頻道是否忙碌（先聽再講），轉發時也會隨機延遲，能避開不少碰撞。
• LoRa 有捕獲效應：兩個訊號撞在一起時，若其中一個明顯較強，仍可能被正確接收。
• 同一筆回報有多份拷貝，只要其中一份成功收到就夠了。
• 卜瓦松假設只是近似：轉發封包是被原始封包觸發的，不是完全獨立的隨機到達。
• 算式假設 100 個節點彼此都聽得到，這是最壞情況。節點分散時，實際互相干擾的只會是一部分。

所以 82％ 是「最壞情況的比較基準」，不是「實際會掉 18％ 封包」的意思。

為什麼負載不宜太高

純 ALOHA 的成功率會隨負載上升快速下降。例如 G 到 0.5 時，成功率只剩約 37％。這也是規劃時要設 25％ 左右安全線的原因。

---

前提與限制

• 只看「最繁忙的那一塊區域」，不是把整個台北的 Meshtastic 網路當成一條頻道，並假設區內節點彼此都聽得到。
• 假設頻道原本沒有其他人在用（既有負載 0％），也沒有額外重送（容許倍數 1.0×）。實際上如果附近還有別的網路、干擾，或封包要重送，使用率會比上述數字更高。
• 「聽到 3 次」是假設值。若實際環境的轉發更密集，使用率會隨之上升（例如換成 7 次，10 分鐘情境會升到約 23％）。有實測數據時，建議直接代入實測值。
• 純 ALOHA 公式假設傳送為獨立的卜瓦松到達，而轉發封包彼此相關，所以 82％ 等數字是近似值，不是精確預測。
• 沒有考慮地形、天線、訊號衰落、大家同時發送等現實因素。
• 這是規劃估算，不是涵蓋範圍或通訊品質的保證。

實務上如何改善的方向

以原本 10 分鐘的設定，這個區域大約能撐到 248 個節點。現在的 100 個節點還有明顯的餘裕。若想讓網路調整或成長，可以考慮：

1. 維持或適度放寬位置回報頻率。10 分鐘一次已相當舒適；改成 15 分鐘一次，使用率降到約 7％，可容納約 373 個節點。反過來，若縮短到 5 分鐘，使用率升到約 20％，100 個節點仍可行，但只剩約 5 個百分點的緩衝，不適合再成長。
2. 控制轉發倍數，避免它悄悄變大。洪泛式轉發是放大流量的來源。可以檢視各節點的角色設定與跳數（hop limit）是否過度寬鬆，讓 3× 不要在節點變多後膨脹成 5× 或 7×。
3. 視需要換成更快的預設頻道設定，縮短每次傳輸的空中時間。不過速度越快，通常涵蓋距離越短，需要取捨。

現實中會讓數字更差的幾件事

1. 背景流量還在。位置、節點資訊、遙測不會因為大家在聊天就消失。若位置回報仍維持 10％ 的使用率，聊天只剩約 15 個百分點可用，約 15 則/分。前面「沒有既有負載」的假設，在聊天情境下是最不站得住腳的一條。
2. 沒有訓練的志工聊天是突發的，不是均勻的。一則訊息常引來幾則回覆，尖峰幾分鐘的流量可能是平均值的數倍。位置回報可以用平均值規劃，聊天要用尖峰值規劃。
3. 訊息長度不固定。這裡的 201 ms 約等於 40 bytes 內容，中文每字 3 bytes，約 13 個字。若是 50 個字（約 150 bytes），單次傳送約 0.52 秒，是位置封包的 2.6 倍，容量會跟著縮水。
4. 確認與重送會加倍。若訊息要求確認（私訊尤其常見），會多一個回覆封包，沒收到確認時還會重送，實際倍數可能比 3 更高。這點我對各韌體版本與 App 預設值沒有十足把握，建議以實際環境確認。
5. 聊天對遺失更敏感。位置掉一筆，下一筆會補上；聊天掉一則，對話就斷了。所以聊天情境的安全線可能要設得比 25％ 更低。
6. 不明究裡的回覆機器人。尤其是把 LoRa 無線電頻道的資源和特性當成是 internet 的初心開發者。

---

參考資料（英文）

純 ALOHA 公式與基礎

LoRa 脈絡下的 ALOHA

---

關於本文

• 問題意識來源：（1）2026年降速演練經驗（2）某次多方討論
  
• 使用人工智慧（排版、查詢、文獻摘要）：Claude, Gemini
  
• 使用工人智慧（文本結構處理、修正、編輯）：T.H. Schee