📘 《AI 時代系列（6）：進階通訊工程——邁向2035年太空星鏈網路時代》
📘 第 6周 🚦 網路會塞車嗎？排隊理論 × 切片 × 資源管理
網路容量與壅塞控制的核心科學
56／150單元： 排隊理論 × URLLC：超低延遲的最後一道關卡
________________________________________
🎯 單元導讀
URLLC（Ultra-Reliable Low Latency Communications）超高可靠度低延遲通訊是：
• 1ms 等級的端到端延遲
• 99.999% 可靠度
• 極小封包、極快反應
• 工控、自動駕駛、遠距手術的命脈
但現實殘酷：
⭐ 只要延遲中出現「排隊」──URRLC 立刻失敗。
所以，URLLC 的最大敵人不是無線電波、不是 OFDM、不是編碼……
而是：
⭐ 排隊理論（Queueing Theory）本身。
本章會讓你看懂：
• URLLC 為什麼無法忍受 Wq
• 排隊理論如何「限制」URRLC 的最低延遲
• ρ 為何比 SNR 還重要
• 為什麼 URLLC 要用「排隊切片（Queue Slicing）」
• URLLC 的兩大延遲殺手：Tail Delay 與 Jitter
• 6G URLLC 如何使用 AI 排程避免排隊爆炸
一句話：
⭐ URLLC 是與排隊賽跑的技術。
________________________________________
🧠 一、URLLC 延遲拆解：你不能掉以輕心
URLLC 的延遲目標通常是：
⭐ E2E < 1ms
但排隊理論會讓你不得不面對現實：
🧩 延遲 = 傳輸 + 處理 + 排隊 + MAC 時延 + 回授遲滯
其中最可怕的是：
Wq（排隊等待時間）→ 任何可變動皆會破功
URLLC 的限制：
❌ 不能排隊
❌ 不能 burst
❌ 不能等回合（如 HARQ）
❌ 不能有尾延遲（Tail Delay）
❌ 不能讓 ρ 接近 1
原因很簡單：
⭐ 一旦等待 Wq > 0.5ms，URLLC 直接 FAIL。
________________________________________
🧠 二、URLLC 的最大敵人：利用率 ρ
利用率：
⭐ ρ = λ / (kμ)
URLLC 的目標不是讓 ρ 高，而是：
⭐ 強迫 ρ 保持低於 0.3 左右
因為：
• ρ < 0.3 → 幾乎不排隊
• ρ 0.4–0.6 → 低 jitter，但不適合 URLLC
• ρ > 0.7 → 延遲急速上升
• ρ → 1 → 絕對爆炸
URLLC 必須：
⭐ 留大量空白（slack capacity）換取超低延遲。
所以 URLLC 與 eMBB 最大差異在於：
• eMBB 想跑到 ρ=0.9（高利用率）
• URLLC 只能跑 ρ<0.5（確保不排隊）
________________________________________
🧠 三、URLLC 之死：Tail Delay（延遲尾部）
URLLC 不是看「平均延遲」，
URLLC 要看：
⭐ 99.999% Percentile Delay（尾延遲）
因為只要 1/100,000 個封包延遲太久，
遠距手術就可能失敗、自動駕駛就可能撞車。
排隊理論的特性（殘酷真相）：
只要 λ 有波動，尾延遲會被瞬間放大。
哪怕 ρ 只有 0.5～0.6，burst traffic 依然會造成 tail delay。
URLLC 的世界只有一句話：
⭐ 平均延遲不重要，尾延遲才讓人死亡。
________________________________________
🧠 四、排隊模型如何限制 URLLC？
📌（1）M/M/1：只要 ρ 上升，延遲急速爆炸
W = 1 / (μ - λ)
URLLC 幾乎無法接受 M/M/1 的 tail behavior。
________________________________________
📌（2）M/M/k：多伺服器未必能救 URLLC
因為：
• M/M/k 只有在 ρ 很低時延遲改善
• 高 ρ 時 tail delay 一樣爆
________________________________________
📌（3）M/G/1：現實世界服務時間更複雜
服務時間變動（如 scheduler、beamforming）
會造成更大 tail delay。
________________________________________
📌（4）實務結論：
⭐ "排隊 = URLLC 的天然敵人"
要做到 1ms，你必須避免排隊而不是壓縮排隊。
________________________________________
🧠 五、URLLC 必須使用「排隊切片（Queue Slicing）」
為什麼 URLLC 不與 eMBB、mMTC 共用排隊佇列？
因為一旦共用佇列：
• burst 流量（video/game/AI traffic）
會瞬間讓 URLLC ρ → 1
導致 waiting time Wq暴增
👉 URLLC 95% 是流量隔離問題，不是無線問題。
這也是 5G / 6G 要做：
• Dedicated Queue
• Network Slicing
• Priority Queue
• Preemption（搶佔）
因為 URLLC 只要等「0.1ms」就會失敗。
________________________________________
🧠 六、LEO 衛星 × URLLC？基本上不可能
LEO 的延遲雖然低（20–40 ms），
但 URLLC 需要 1ms。
LEO 的致命問題：
• 多跳 routing
• RF chain 數量有限
• 城市重負載（λ 過大）
• 排隊延遲 unpredictable
所以：
⭐ LEO 不可能做 URLLC，只能做 eMBB / FWA。
________________________________________
🧠 七、URLLC 與 Base Station 的關鍵機制
URLLC 要做到 1ms，必須：
✔ MAC 層 mini-slot（2 OFDM symbol）
✔ HARQ-less（無重傳）
✔ Grant-free（不等排程 grant）
✔ Preemptive Scheduling（直接搶佔 eMBB slot）
✔ Priority Queue（高優先級隊列）
✔ 控制 ρ < 0.3
也就是：
⭐ 通訊工程的所有層級，都在「盡量讓封包不等待」。
________________________________________
🧠 八、三大模擬與計算題
**1️⃣ 專業題：
為何 URLLC 不能忍受排隊？**
📦 答案：
因為排隊延遲 Wq 的尾延遲不可預測，
即使 ρ=0.6 也會出現爆跳（queue burst）。
________________________________________
**2️⃣ 應用題：
基地台共用佇列時，URLLC 失敗的原因？**
A. SNR 不夠
B. eMBB 流量 burst 導致 ρ → 1 ✔
C. 調變方式不對
D. 波束錯誤
因為 eMBB 的突發流量使系統利用率 ρ 接近 1，排隊延遲急遽上升，導致 URLLC 無法滿足嚴格的低延遲與高可靠度需求。
________________________________________
**3️⃣ 情境題：
UPF 在高負載時 16 核仍延遲暴增原因？**
📦 答案：
因為 ρ → 1，排隊延遲暴增（M/M/k 特性）
________________________________________
🛠 九、工程實務演練題
1️⃣ 設計一種「URLLC Priority Queue」演算法
2️⃣ 模擬 ρ=0.2、0.4、0.6、0.8 時的 tail delay
3️⃣ 分析 eMBB burst 對 URLLC 的影響
4️⃣ 將 Little’s Law 應用於 URLLC queue occupancy
5️⃣ 設計排隊切片圖（Queue Slicing）
________________________________________
✅ 十、小結：URLLC 是與排隊理論的決戰
✔ URLLC 不能排隊
✔ ρ 是 URLLC 的決定因子
✔ 平均延遲不重要，尾延遲才是致命
✔ 多伺服器（M/M/k）不能保證低延遲
✔ 必須使用排隊切片 / preemption
✔ LEO 無法支援 URLLC（延遲無法達成）
一句話：
⭐ **URLLC 想活下來，唯一方法是：
把排隊徹底從系統裡消滅。**
