📘 《AI 時代系列（6)：進階通訊工程——邁向2035年太空星鏈網路時代》
📘 第 6周 🚦 網路會塞車嗎？排隊理論 × 切片 × 資源管理
網路容量與壅塞控制的核心科學
58／150單元： URLLC 延遲極限：毫秒級任務的真正瓶頸
________________________________________
🎯 單元導讀
URLLC（Ultra-Reliable Low Latency Communications）最核心的 KPI：
• ✨ 端到端延遲 E2E < 1ms
• ✨ 可靠度 ≥ 99.999%（五個 9）
• ✨ 封包大小極小（20–100 bytes）
• ✨ 變異度（jitter）極低
但這個要求在工程上是非常接近「物理極限」的。
你會看到：
⭐ URLLC 的瓶頸不是無線電，而是排隊（queue）與處理延遲（processing）
⭐ URLLC 的敵人不是平均延遲，而是尾延遲（tail latency）
本單元會讓你知道：
• 為什麼 URLLC 幾乎無法在真實網路達成
• HARQ、調變、PRB、slot，都會壓縮到極限
• ρ（利用率）稍微升高就會瞬間爆炸
• LEO / GEO 永遠不可能做到 URLLC
• MEC edge 離 UE 多一跳就毀掉整個延遲預算
一句話：
⭐ URLLC 要挑戰的不是 1ms，而是宇宙中所有會造成等待的因素。
________________________________________
🧠 一、URLLC 延遲預算：毫秒級拆開會有多窮酸？
• UE processing（終端處理）
o 約 0.15 – 0.2 ms
• PHY 傳輸（mini-slot）
o 約 0.125 – 0.25 ms
• MAC 排程
o 約 0.1 – 0.25 ms
• HARQ / 回授
o 約 0 – 0.3 ms
• RLC / PDCP
o 約 0.05 – 0.1 ms
• gNodeB processing（基地台處理）
o 約 0.1 – 0.2 ms
• UPF / Core routing（核心網路）
o 約 0.05 – 0.2 ms
• Transport（光纖傳輸）
o 約 0.01 – 0.1 ms
把最理想值加起來：
⭐ 0.8–0.9 ms（極限狀態）
也就是：
任何一層只要比原本多「0.1ms」──整個 URLLC 直接失敗。
這是 URLLC 為什麼這麼「恐怖」的本質。
________________________________________
🧠 二、URLLC 三大延遲殺手
這三個因素只要一來，URLLC 馬上完蛋：
________________________________________
🔪 1. Queueing Delay（排隊延遲）
URLLC 幾乎不能容忍排隊，
只要 Wq > 0.2 ms 就接近死刑。
因為：
Wq = Little’s Law: Lq / λ
ρ increase → queue 瞬間暴增 → tail delay 爆炸
URLLC 最怕「偶發排隊」。
________________________________________
🔪 2. Processing Delay（處理延遲）
基站 / UPF / MEC 全部都摳到極限：
• 解調
• 編碼
• scheduler
• HARQ
• beamforming
• UPF NF chain
任何一個元件稍微忙一點點，延遲立刻破表。
________________________________________
🔪 3. Tail Latency（尾延遲）
URLLC 不看平均延遲（avg），
看的是：
⭐ 99.999% 延遲（P99.999）
哪怕：
• 1 萬個封包只有 1 個慢
• 也不合格
因為自動駕駛 / 遠距手術不能「偶爾慢一下」。
________________________________________
🧠 三、URLLC 與傳統無線通訊真正的差別
________________________________________
📌（1）URLLC 不是看「速度」，而是看「不變動」
eMBB 看吞吐（Mbps）
URLLC 看 jitter（變異度）
________________________________________
📌（2）URLLC 的目標是「完全避免排隊」
不是降低
不是縮短
是：
❗ 完全避免排隊發生
這也是為什麼前一單元（57）要用 queue slicing。
________________________________________
📌（3）URLLC 要用 mini-slot / HARQ-less / grant-free
因為：
• normal slot 要 1ms：太慢
• HARQ 重傳可能造成變動：太危險
• 事先 grant 才能避免排隊
________________________________________
🧠 四、LEO / GEO × URLLC？完全不可能
• GEO 衛星
o 單向延遲：約 250 ms
o 是否可做 URLLC：❌ 絕對不可能
o 原因：物理距離過長，延遲下限即遠超 URLLC 要求
• LEO 衛星
o 單向延遲：約 20–40 ms
o 是否可做 URLLC：❌ 一樣不可能
o 原因：即使距離較短，延遲仍高於 1 ms 等級需求
• 地面光纖（Fiber）
o 單向延遲：約 0.1–1 ms
o 是否可做 URLLC：✔ 可以
o 原因：傳輸穩定、延遲低，可配合切片與排程設計
• MEC（Multi-access Edge Computing）
o 單向延遲：約 0.1–0.5 ms
o 是否可做 URLLC：✔ 最佳方案
o 原因：計算與決策下沉到邊緣，幾乎消除核心網排隊與路由延遲
一句工程結論
URLLC 只能建立在「地面光纖＋邊緣計算」之上，任何衛星系統在物理延遲上都不具可行性。
________________________________________
原因：
⭐ URLLC 的延遲預算只有 1ms，而 LEO/GEO 光「距離」就超標 10～500 倍。
所以未來：
• 自動駕駛
• 遠距手術
• 智慧工廠
全部只能用：
⭐ 地端 + MEC edge
星鏈永遠只能做 eMBB / IoT / 回傳。
________________________________________
🧠 五、URLLC 與排隊理論：延遲極限推導
假設 URLLC 拿到：
• λ = 低
• μ = 高
• k = 多核心
• ρ = 必須 < 0.3 或 0.4
我們直接用 M/M/1 分析：
W = 1 / (μ - λ)
只要 λ 增加 10%，延遲會上升 2–10 倍。
換句話說：
⭐ URLLC 想要 W < 0.2 ms
→ 必須保持「大量剩餘容量」
這也是為什麼 URLLC 無法有效率地使用頻譜（效率 vs 延遲互斥）。
________________________________________
🧠 六、工程直觀圖（URLLC 延遲爆炸）
延遲 W
^
| ● ← ρ = 0.6：URLLC 已經快死
| ●
| ●
| ●
|● ← ρ = 0.3：URLLC 勉強OK
+---------------------------------> ρ 利用率
URLLC 不在乎平均延遲，而是怕：
⭐「突然」延遲跳高。
________________________________________
🧠 七、模擬題
**1️⃣ 專業題：
為什麼 URLLC 無法容忍 HARQ？**
📦 答案： 因為 HARQ 重傳會造成不可預測延遲（tail latency）。
________________________________________
**2️⃣ 應用題：
為什麼 URLLC 的 queue 必須獨立（queue slicing）？**
📦 答案： eMBB 的 burst 流量會瞬間讓 ρ→1，導致 URLLC 等待。
________________________________________
**3️⃣ 情境題：
LEO 星鏈為什麼永遠無法達成 URLLC？**
A. 頻寬不夠
B. 波束不夠
C. 距離造成 propagation delay 過大 ✔
D. 太貴
因為 LEO 衛星與地面之間的物理距離不可避免地造成數十毫秒的傳播延遲，遠高於 URLLC 所要求的 1 ms 等級延遲下限。
________________________________________
🛠 八、實務演練題（工程級）
1️⃣ 建立 URLLC → eMBB 同時負載時的 queue 行為曲線
2️⃣ 用 mini-slot 模擬 HARQ-less 傳輸
3️⃣ 模擬 ρ = 0.2, 0.4, 0.6 時 P99 延遲
4️⃣ 設計 MEC URLLC 任務排程
5️⃣ 計算傳輸 / 處理 / 排隊延遲的極限分配（最佳化）
________________________________________
✅ 九、小結：URLLC 是挑戰宇宙物理極限的工程
✔ 延遲預算不到 1ms，幾乎沒有餘裕
✔ 任意一層多 0.1ms URLLC 就失敗
✔ 排隊延遲是最大的敵人
✔ ρ（利用率）稍微升高 Tail latency 立刻爆炸
✔ HARQ / normal slot 都太慢
✔ LEO/GEO 根本不可能做 URLLC
✔ 唯一可行結構：RAN URLLC + MEC Edge
一句話：
⭐ URLLC 是全世界最嚴格的延遲挑戰。
