首頁文章關於報價聯絡我們🌐 EN
← 返回首頁Cloud Native
5G Cloud Native Architecture：電信商如何實現雲原生 5G 核心網路【2025】

5G Cloud Native Architecture：電信商如何實現雲原生 5G 核心網路【2025】

📅 2026-04-16⏱ 14 min read
📑 目錄

5G 不只是「比 4G 更快」。5G 的設計從一開始就考慮了雲原生架構，讓電信網路變得更靈活、更有彈性。這也是為什麼 5G 和 Cloud Native 經常被放在一起討論。

這篇文章會解釋 5G 核心網路的雲原生架構，包括服務化架構（SBA）、網路功能虛擬化（NFV）、容器化網路功能（CNF），以及實際的電信商導入案例。

5G 與 Cloud Native 的關係

為什麼 5G 需要 Cloud Native？

傳統的 4G 網路架構是「垂直整合」的：硬體和軟體綁在一起，由同一家廠商提供。這種架構很穩定，但有幾個問題：

1. 擴展困難

需要更多容量？買更多專用硬體。這需要時間，而且成本高。

2. 功能更新緩慢

新功能要等硬體供應商開發，然後排時間升級。一個功能可能要等一年以上。

3. 廠商鎖定

一旦選了某家設備商，就很難換。這限制了議價能力和技術選擇。

5G 的 Cloud Native 架構解決這些問題：

面向傳統 4G5G Cloud Native
硬體專用硬體通用伺服器
軟體綁定硬體容器化、可移植
擴展買硬體自動擴展
更新停機維護滾動更新
廠商單一廠商多廠商整合

傳統電信架構 vs 雲原生架構

傳統架構：
┌─────────────────────────────────────┐
│  專用硬體設備 (Vendor A)             │
│  ┌─────────────────────────────┐   │
│  │  EPC (4G Core)               │   │
│  │  ├─ MME                      │   │
│  │  ├─ SGW                      │   │
│  │  └─ PGW                      │   │
│  └─────────────────────────────┘   │
└─────────────────────────────────────┘

雲原生架構：
┌─────────────────────────────────────┐
│  Kubernetes Cluster                  │
│  ┌─────────────────────────────┐   │
│  │  5G Core (CNF)               │   │
│  │  ├─ AMF (容器)               │   │
│  │  ├─ SMF (容器)               │   │
│  │  ├─ UPF (容器)               │   │
│  │  └─ 其他 NF...               │   │
│  └─────────────────────────────┘   │
│  ┌─────────────────────────────┐   │
│  │  通用伺服器硬體              │   │
│  └─────────────────────────────┘   │
└─────────────────────────────────────┘

5G 雲原生化的驅動因素

1. 3GPP 標準推動

3GPP 在 Release 15 開始定義 5G 核心網路，採用服務化架構（SBA），天然適合微服務和 Cloud Native。

2. 成本壓力

電信商面對 OTT 業者（Google、Netflix）的競爭，需要降低基礎設施成本。通用硬體比專用設備便宜。

3. 新業務需求

5G 要支援多種場景（eMBB、URLLC、mMTC），需要彈性的網路切片能力。這只有 Cloud Native 架構能做到。

4. 生態系成熟

Kubernetes 和 CNCF 生態系已經成熟，電信商可以利用現有的雲原生工具。

想了解 Cloud Native 基本概念？請參考 Cloud Native 完整指南。

5G Core Network 雲原生架構

5G Core（5GC）概述

5G Core（5GC）是 5G 網路的大腦，負責：

5GC 採用服務化架構（Service-Based Architecture, SBA），每個網路功能（Network Function）都是獨立的服務，透過 HTTP/2 和 JSON 通訊。

這和微服務架構非常相似——每個 NF 可以獨立開發、部署、擴展。

5GC 核心網路元件

元件全名功能
AMFAccess and Mobility Management Function處理使用者接入和移動性
SMFSession Management Function管理 PDU Session
UPFUser Plane Function處理使用者資料封包
PCFPolicy Control Function政策控制
UDMUnified Data Management使用者資料管理
AUSFAuthentication Server Function認證服務
NRFNetwork Repository Function服務註冊和發現
NSSFNetwork Slice Selection Function網路切片選擇

SBA 架構圖：

┌────────────────────────────────────────────────────────────┐
│                    Service-Based Interface                  │
├──────┬──────┬──────┬──────┬──────┬──────┬──────┬──────────┤
│ NSSF │ NEF  │ NRF  │ PCF  │ UDM  │ AUSF │ AMF  │   SMF    │
└──────┴──────┴──────┴──────┴──────┴──────┴──────┴────┬─────┘
                                                      │
                                                ┌─────▼─────┐
                                                │    UPF    │
                                                └───────────┘

每個 NF 都暴露 RESTful API，其他 NF 可以透過 NRF（服務發現）找到並呼叫。

網路功能虛擬化（NFV）

NFV（Network Functions Virtualization） 是把網路功能從專用硬體移到虛擬機器或容器的技術。

NFV 架構層次：

┌─────────────────────────────────────────────┐
│  VNF / CNF (虛擬/容器化網路功能)            │
├─────────────────────────────────────────────┤
│  NFVI (NFV 基礎設施)                        │
│  ├─ 虛擬化層 (VM / Container)              │
│  ├─ 虛擬運算、儲存、網路                   │
│  └─ 硬體資源                               │
├─────────────────────────────────────────────┤
│  MANO (管理和編排)                          │
│  ├─ NFVO (編排器)                          │
│  ├─ VNFM (VNF 管理)                        │
│  └─ VIM (基礎設施管理)                     │
└─────────────────────────────────────────────┘

VNF vs CNF：

面向VNF (虛擬機器)CNF (容器)
啟動時間分鐘級秒級
資源效率中等高
密度一台主機 10-20 VNF一台主機 100+ CNF
編排工具OpenStackKubernetes

5G 的趨勢是從 VNF 轉向 CNF，用 Kubernetes 取代 OpenStack。

網路切片（Network Slicing）

網路切片是 5G 的核心功能之一。它讓電信商可以在同一個實體網路上，虛擬出多個「邏輯網路」，每個都有不同的特性。

典型的網路切片：

切片類型用途特性
eMBB高速寬頻高頻寬、中延遲
URLLC超低延遲低延遲、高可靠
mMTC物聯網低功耗、大量連接

Cloud Native 如何支援網路切片：

每個切片可以部署成獨立的 Kubernetes Namespace，有自己的：

# 網路切片的 Namespace 範例
apiVersion: v1
kind: Namespace
metadata:
  name: slice-urllc
  labels:
    slice-type: urllc
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: urllc-quota
  namespace: slice-urllc
spec:
  hard:
    requests.cpu: "100"
    requests.memory: 200Gi
    limits.cpu: "200"
    limits.memory: 400Gi

3GPP 標準與 Cloud Native

3GPP 如何定義 Cloud Native 5G

3GPP 是制定行動通訊標準的組織。從 Release 15 開始，3GPP 定義的 5G 架構就考慮了 Cloud Native：

Release 15（2018）：

Release 16（2020）：

Release 17（2022）：

ETSI NFV 與 Kubernetes

ETSI（歐洲電信標準協會） 定義了 NFV 的參考架構。隨著容器化趨勢，ETSI 也在調整其架構以支援 Kubernetes：

關鍵變化：

傳統 NFV容器化 NFV
OpenStack (VIM)Kubernetes
VM 編排Container 編排
Heat TemplatesHelm Charts
重量級輕量級

5G Cloud Native 技術棧

電信商的 5G Cloud Native 技術棧通常包含：

容器編排：

服務網格：

可觀測性：

CI/CD：

網路：

儲存：

了解更多 Kubernetes 技術棧？請參考 Cloud Native 技術棧入門。

電信商導入案例

Rakuten Mobile（日本）

全球第一個完全雲原生的 5G 網路。

Rakuten Mobile 在 2020 年推出 5G 服務，從一開始就採用全雲原生架構：

架構特色：

成效：

Dish Network（美國）

美國首個雲原生 5G 網路。

Dish 在 2022 年推出 5G 服務，架構特色：

中華電信（台灣）

台灣領先的 5G 服務商。

中華電信的 5G 架構採用：

技術挑戰與解決方案

挑戰 1：電信級可靠性

電信網路要求 99.999%（五個九）的可用性，相當於一年只能停機 5 分鐘。

解決方案：

挑戰 2：低延遲需求

5G URLLC 場景要求端到端延遲低於 1 毫秒。

解決方案：

挑戰 3：高效能網路

電信工作負載需要極高的封包處理效能。

解決方案：

挑戰 4：安全合規

電信網路受到嚴格的法規監管。

解決方案：

了解更多安全議題？請參考 Cloud Native Security 完整指南。

挑戰 5：技術人才

傳統電信工程師需要學習 Cloud Native 技術。

解決方案：

FAQ

Q1: 5G 一定要用 Cloud Native 架構嗎？

不是強制的，但 3GPP 標準的設計讓 Cloud Native 成為最自然的選擇。傳統架構也可以實現 5G，但會失去彈性和成本優勢。

Q2: 電信商可以用公有雲嗎？

可以。Dish 就是用 AWS。但大多數電信商選擇私有雲或混合雲，因為資料主權和法規要求。

Q3: CNF 和一般的容器應用有什麼不同？

CNF 有更嚴格的效能和可靠性要求。需要特殊的網路配置（SR-IOV）、資源隔離、實時性保證。

Q4: 現有的 4G 網路可以升級到 Cloud Native 嗎？

可以逐步升級。通常的路徑是先虛擬化（VNF），再容器化（CNF）。但這需要時間和投資。

Q5: 5G Cloud Native 需要什麼技術背景？

需要結合電信和 IT 技術：了解 3GPP 標準、Kubernetes、網路虛擬化、高效能網路。這也是為什麼人才短缺是一大挑戰。

下一步

5G Cloud Native 是電信產業的重大轉型。如果你的企業正在評估或導入相關技術：

  1. 先了解 3GPP 和 ETSI 的標準要求
  2. 評估現有基礎設施的雲原生成熟度
  3. 規劃分階段的遷移路徑
  4. 建立跨領域的技術團隊

延伸閱讀：

電信級架構設計需要專業協助？預約架構諮詢，讓我們幫你評估現況，規劃最適合的 5G Cloud Native 策略。

參考資料

Cloud NativeAzureKubernetesDocker
← 上一篇
AI Agent 企業應用指南：導入策略、實際案例與 ROI 評估完整攻略