📘 《AI 時代系列（6）：進階通訊工程——邁向2035年太空星鏈網路時代》
📘 第 6周 🚦 網路會塞車嗎？排隊理論 × 切片 × 資源管理
網路容量與壅塞控制的核心科學
52／150單元： M/M/k 多通道 👥 複雜網路的排隊
—— 多核心、多天線、多伺服器系統的真實模型**
________________________________________
🎯 單元導讀
上一單元我們看到最基本的 M/M/1：
「一個伺服器 + Poisson 到達 + exponential 服務」。
但真實世界中：
• gNodeB 有多條排程鏈路
• UPF 有多核
• Firewall 有多個 worker
• MEC 有多個 CPU thread
• LEO 衛星有多個 RF chain
• 資料中心擁有數十甚至上百台伺服器
它們的共同點就是：
⭐ 系統不是一條隊伍，而是「k 個伺服器」並行工作。
這就是 M/M/k 多通道排隊模型。
M/M/1 是玩具世界；
M/M/k 才是工程世界。
________________________________________
🧠 一、M/M/k 是什麼？一句話版
⭐ 具有 Poisson 到達、exponential 服務、k 個伺服器 的排隊系統
• 到達過程 = Poisson（λ）
• 每個伺服器的服務率 = μ
• 一共有 k 個伺服器
整體服務能力 = kμ。
但壅塞情況不是線性，而是「極度非線性」。
________________________________________
🧠 二、系統參數（務必記住）
參數 意義
λ 到達率（封包/秒）
μ 單一伺服器服務率
k 伺服器個數（核心數、天線數、worker 數）
ρ = λ / (kμ) 系統利用率
📌 與 M/M/1 最大不同：
利用率 ρ 是「平均分攤到所有伺服器」。
________________________________________
🧠 三、核心現象：伺服器越多 ≠ 延遲越短
直覺會以為：
「我開多幾台伺服器就會變快」
❌ 錯。
多通道排隊系統有兩個殘酷事實：
________________________________________
⭐（1）只要 ρ → 1，延遲依然會爆炸
k 再多也救不了。
________________________________________
⭐（2）增加 k 有效，但邊際效益快速遞減
例如：
k 延遲改善
1 → 2 明顯改善
2 → 3 小幅改善
10 → 11 幾乎沒差
📌 這是 MEC、UPF、虛擬化核心中最現實的問題：
一直加 CPU 並不等於延遲改善。
________________________________________
🧠 四、M/M/k 的最重要公式（需要背）
⭐ Erlang C Formula（排隊機率）
Erlang C 用來計算 到達的客戶需要排隊等待的機率：
Pqueue =
[(k·ρ)^k / ( k! · (1 − ρ) )]
[ Σ (i = 0 到 k−1) (k·ρ)^i / i! + (k·ρ)^k / ( k! · (1 − ρ) ) ]
________________________________________
參數說明
• k：服務台數（servers）
• λ：到達率
• μ：單一服務台服務率
• ρ = λ / (k·μ)：系統利用率（必須 < 1）
• Pqueue：客戶到達後需要等待的機率
使用重點（考試一定會考）
• ρ ≥ 1 → 系統不穩定（無解）
• k 增加 → Pqueue 下降
• λ 增加 → Pqueue 上升
這個值代表：
⭐「封包到達時，k 個伺服器都忙的機率」
→ 也就是封包被迫排隊的機率。
________________________________________
⭐ 平均等待時間 Wq（排隊延遲）
在 M/M/k 排隊模型中，平均等待時間（不含服務時間）為：
Wq = Pqueue / (k·μ − λ)
等待時間 = 排隊機率 ÷ 系統剩餘能力
📌 與 M/M/1 最大差別：機率因素出現。
________________________________________
⭐ 系統總延遲 W
在 M/M/k 排隊模型中，系統的平均總延遲為：
W = Wq + 1 / μ
總延遲 = 排隊延遲 + 服務延遲
這個公式常用於電信容量規劃、系統效能分析與考試計算。
________________________________________
🧠 五、M/M/k 在基地台/核心網的工程意義
________________________________________
📡（1）Massive MIMO：k = 天線群並行服務
k ↑ → 分集增益 ↑ → 派發封包更快
但：
❗ 若 λ 太高（高負載基地台）
→ k 再多也救不了延遲爆炸（ρ → 1）。
________________________________________
🛰（2）LEO 星鏈：多 RF chain、多波束
每個波束 = 一個 server
多波束星鏈 = 典型的 M/M/k 排隊模型
✔ 晴天 → λ 分散 → 延遲低
✘ 城市高峰 → λ 高 → 仍然壅塞
________________________________________
🧱（3）核心網 UPF：多核併發
UPF 的 CPU core = k
QUIC/TCP 封包 = λ
每個 core 處理率 = μ
→ 若 λ 接近 kμ，延遲立即爆炸。
________________________________________
☁（4）MEC：多伺服器邊緣運算
你多人流量場景（演唱會、球場）
只要 λ 大於 kμ 就會瞬間延遲飆升。
________________________________________
🧠 六、ASCII 圖：增加 k 的邊際效益
平均延遲 W
^ |
| | ● k = 1 ← 延遲最高
| |
| | ● k = 2
| |
| | ● k = 4
| |
| | ● k = 8
| |
+-----------------------------------> λ (流量)
低 中 高
此示意圖顯示在固定到達率 λ 條件下，隨著服務台數 k 的增加，系統平均延遲 W 會明顯下降，但下降幅度具有「遞減效果」。當 k 很小時（如 k = 1），系統容易接近滿載，平均延遲急遽上升；隨著 k 增加到 2、4，延遲可大幅改善。然而當 k 已足夠大（如 k = 8），再繼續增加服務台，延遲的改善幅度逐漸變小，顯示增加資源存在邊際效益遞減。這也是實務中容量規劃需在效能改善與成本之間取得平衡的原因。
📌 多伺服器只在中低流量顯著改善，
高流量時仍會爆炸。
________________________________________
🧠 七、模擬題
________________________________________
**1️⃣ 專業題：
M/M/k 與 M/M/1 最大差異是什麼？**
📜 答案：
M/M/k 有 k 個平行伺服器，因此需用 Erlang C 計算排隊概率；
延遲不再僅由 μ−λ 決定，而需考慮 k 與 ρ。
________________________________________
**2️⃣ 應用題：
UPF 有 8 核（k=8），假設 λ 接近 8μ，延遲會如何？**
A. 延遲下降
B. 延遲保持穩定
C. 延遲仍會爆炸
D. 轉成 M/G/1
📦 答案：C
因為 ρ → 1 時，M/M/k 仍會爆炸。
________________________________________
**3️⃣ 情境題：
星鏈地面端同時支援多波束，為什麼仍可能壅塞？**
A. 因為 μ 太高
B. 因為每個波束被分擔後 λ 仍過大
C. 因為 LEO 沒有排隊
D. 因為天線是固定的
📡 答案：B
因為即使有多波束分流，只要單一波束承擔的到達率 λ 仍接近或超過其服務能力 μ，系統利用率過高就會導致壅塞。
________________________________________
🛠 八、實務演練題
1️⃣ 計算不同 k 對延遲 W 的改善
2️⃣ 用 Python 模擬 gNodeB 在 k = 1,2,4,8 下的排隊情形
3️⃣ 分析 UPF 8-core 與 16-core 差異
4️⃣ 模擬星鏈多波束（multi-beam）的壅塞程度
5️⃣ 設計一個「動態 k」系統（auto-scaling）
________________________________________
✅ 九、小結與啟示
✔ M/M/k 是基地台、UPF、MEC、星鏈的真實延遲模型
✔ 多伺服器不代表不會壅塞
✔ ρ → 1 時，延遲依然爆炸（多核心救不了）
✔ Erlang C formula 描述「伺服器皆忙」的現象
✔ k 增加的邊際效益快速遞減
✔ 6G 須用 AI-Scheduler、動態切片等方式控制 λ、μ、k
一句話：
⭐ 未來 6G 想做到穩定、低延遲，不能靠硬塞伺服器，而是要控制 ρ。
