📘 《AI 時代系列（6）：進階通訊工程——邁向2035年太空星鏈網路時代》
📘 第 6周 🚦 網路會塞車嗎？排隊理論 × 切片 × 資源管理
網路容量與壅塞控制的核心科學
57／150單元： 切片資源分配：為每種服務開車道（Network Slicing）
________________________________________
🎯 單元導讀:
5G / 6G 最革命性的概念之一就是：
⭐ Network Slicing（網路切片）＝為不同服務開不同車道。
因為現代網路已經變成：
• eMBB：看 4K 串流
• URLLC：1ms 命脈通訊
• mMTC：大量 IoT
• AI Traffic：雲端推論資料流
• 車聯網：低延遲 + 高可靠
• LEO × 地面：多路徑混合負載
所有這些 traffic 混在一起就會：
• 阻塞
• 延遲跳高
• 排隊爆炸
• URLLC 失敗
• eMBB 卡頓
• IoT 上報延遲
所以 5G / 6G 的核心解法就是：
⭐ 「切開來」分配資源（RAN + Core + Transport 全分開）
本章就是要讓你搞懂：
• 為什麼要切片？
• 切片如何分配資源？
• 為什麼 URLLC 和 eMBB 絕對不能混？
• RAN、核心網、MEC 如何做切片？
• AI Scheduler 如何管理切片？
• 切片如何避免壅塞？
一句話：
⭐ 切片，就是把馬路分成多條專用車道，確保每種交通不互相撞。
________________________________________
🧠 一、什麼是 Network Slicing？
一句話：
⭐ 把整張網路「分割」成獨立、隔離、可控的虛擬網路。
每一條切片擁有自己的：
• 頻譜 / PRB
• Scheduler
• Queue
• UPF / SMF
• Policy
• QoS
• 安全
• SLA
• Transport bandwidth
• MEC 計算資源
有點像：
⭐ 在同一條高速公路上，畫出不同車種的專屬車道：
• 🚗 eMBB 車道（高速、大車流）
• 🏎 URLLC 車道（特快、禁止阻塞）
• 🚚 IoT 慢速車道
• 🛰 Edge / AI Traffic 高頻率車道
________________________________________
🧠 二、為什麼一定要切片？（工程實話）
因為不同 traffic 的本質完全不同，混在同一個佇列一定出事。
• eMBB（Enhanced Mobile Broadband）
o 特性：高吞吐量、可容忍延遲
o 不能混的原因：突發流量（burst）容易把佇列塞滿，直接壅塞 URLLC
• URLLC（Ultra-Reliable Low Latency Communications）
o 特性：超低延遲（~1 ms）、幾乎不能排隊
o 不能混的原因：必須獨立 Queue 與最高優先級，否則延遲必爆
• IoT / mMTC（Massive Machine Type Communications）
o 特性：週期性上報、裝置數量極大
o 不能混的原因：同步上報時會造成排隊峰值（queue spike）
• AI Traffic（模型更新、資料同步）
o 特性：大批量、強 burst、尾延遲敏感
o 不能混的原因：尾延遲巨大，會拖垮即時服務
• 車聯網（V2X）
o 特性：高可靠、低延遲、即時反應
o 不能混的原因：必須搭配 edge 計算與高優先權排程
如果混在一起：
• eMBB burst → URLLC queue 直接爆
• AI 流量 → 用完 MEC 資源
• IoT 大批同步上報 → 造成 signaling storm
• LEO burst → 擠爆 uplink chain
所以切片的目的就是：
⭐ 誰也不打擾誰。誰也不害死誰。
________________________________________
🧠 三、切片的三大層級（RAN / Transport / Core）
① RAN 切片（基地台資源切片）
要切：
• PRB 區塊
• Beam 資源
• Scheduling priority
• HARQ 資源
• Queue
例：
URLLC 用 mini-slot + priority queue
eMBB 用 normal slot + best effort
________________________________________
② Transport 切片（X-Haul）
要切：
• VLAN
• VRF
• SR-TE（Segment Routing Traffic Engineering）
• 保留頻寬
例：
• URLLC → 低延遲路徑
• eMBB → 高吞吐路徑
• AI Traffic → 背後高容量路徑
________________________________________
③ Core 切片（UPF / SMF / AMF）
要切：
• UPF 多實例
• SMF 多策略
• PCF QoS 分級
• Dedicated PQ（Priority Queue）
________________________________________
🧠 四、切片如何分配資源？
切片的核心公式只有一個：
⭐ 每個切片 = 頻寬 B + CPU C + Queue Q + SLA P
並且是「硬切」或「軟切」：
🎛 1. Hard Slicing（硬切片）
像高速公路的實體車道。
• 保留固定 PRB
• 保留固定 uplink / downlink
• 保留 CPU / buffer
• 任何人不能搶
→ 適用 URLLC。
________________________________________
🎛 2. Soft Slicing（軟切片）
資源可共享，但有最低保證。
→ 適合 eMBB、AI traffic。
________________________________________
🎛 3. Hybrid（混合切片）
URLLC 狀態時 → 硬切片
非尖峰時 → 軟切共用
→ 6G AI-Native Scheduler 常用
________________________________________
🧠 五、切片與排隊（Queue Slicing）
每一個切片都有自己的 queue：
• URLLC Queue
• eMBB Queue
• IoT Queue
• Edge / AI Queue
因為：
⭐ 排隊混合 = 所有切片延遲爆炸。
URLLC 的 Queue 特性：
• 不允許排長
• 不允許 burst
• 不允許 sharing
• 必須 priority
eMBB 的 Queue：
• Best effort
• 可以長
• 可以 burst
IoT 的 Queue：
• 同步時會瞬間爆量
• 必須 rate control
________________________________________
🧠 六、AI Scheduler × 切片：6G 的靈魂
6G 必須使用 AI scheduler，因為人工 policy 無法處理：
• 每毫秒 PRB 動態分配
• 依據負載預測調整切片比例
• 在 10ms 內重新分配 Queue
• 動態控制 ρ（利用率）
• 動態切換 Hard / Soft slicing
• 基於 traffic burst 預測提前加車道
AI Scheduler 會根據：
• λ（到達率）
• μ（服務率）
• CV（突發度）
• H（自相似度）
• UE 類型
• Priority class
• SLAs
來分配資源。
________________________________________
🧠 七、ASCII 圖：切片概念
=== 基地台 RAN 資源 ===
╔══════════════════════════════════╗
║ [URLLC 車道] | [eMBB 車道] | [IoT 車道] ║
║ PRB 固定 PRB 共享 低速區 ║
║ Queue 專用 Queue BE 週期上報 ║
╚══════════════════════════════════╝
此示意圖說明 Network Slicing 在 RAN 層的核心概念：
基地台的無線資源（如 PRB、排程與佇列）會依不同服務需求被邏輯切分成多條「車道」。URLLC 車道配置固定且專用的 PRB 與獨立 Queue，以確保超低延遲與高可靠度；eMBB 車道採共享 PRB 與 Best-Effort 佇列，以換取高吞吐量但可容忍延遲；IoT 車道則位於低速區，適合大量裝置的週期性上報。透過這種資源與佇列的隔離設計，不同本質的流量得以互不干擾，避免彼此造成壅塞或延遲失控。
________________________________________
🧠 八、模擬題
**1️⃣ 專業題：
為何 URLLC 必須用獨立切片？**
📦 答案： 因為共用 queue 會讓 eMBB burst 導致 ρ→1，URLLC 延遲直接爆炸。
________________________________________
**2️⃣ 應用題：
IoT 為什麼不能與 AI traffic 混切片？**
📦 答案： IoT 同步上報會造成 peak burst，壅塞 AI queue。
________________________________________
**3️⃣ 情境題：
eMBB + URLLC 混在同一 PRB pool 會？**
A. 提高總吞吐
B. URLLC 失敗 ✔
C. eMBB 增加
D. PRB 更公平
因為 eMBB 的突發高流量會佔滿 PRB 與佇列，導致 URLLC 無法取得即時資源而違反其嚴格的低延遲與高可靠度需求。
________________________________________
🛠 九、實務演練題
1️⃣ 設計一個基地台 3 個切片的 PRB 分配方式
2️⃣ 模擬 URLLC ρ<0.3 時延遲行為
3️⃣ 根據 λ 做動態切片（AIML 驅動）
4️⃣ 對比 Hard Slice vs Soft Slice 的 Queue behavior
5️⃣ 設計車聯網的 Edge 切片架構
________________________________________
✅ 十、小結：切片是 6G 的高速公路工程
✔ 切片＝不同服務分不同車道
✔ URLLC 必須完全隔離
✔ eMBB / AI traffic 可以共享
✔ IoT 需要 rate control + queue slicing
✔ RAN / Transport / Core 都要切
✔ AI Scheduler 是 6G 切片的靈魂
✔ 切片不只是 QoS，而是完整的 SLA、排隊、頻寬、CPU 的隔離
一句話：
⭐ 6G = 用切片把天下萬物的流量分車道，避免互相撞死。
