CloudInsight Logo
CloudInsight
返回首頁Cloud Native

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

14 min 分鐘閱讀
#5g#cloud-native#telecom#nfv#kubernetes

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

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

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

台灣電信機房內部，工程師在伺服器機櫃前檢視 5G 核心網路設備，螢幕顯示網路拓撲圖

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，有自己的：

  • 資源配額（CPU、記憶體）
  • 網路政策
  • 服務品質設定
# 網路切片的 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

電腦螢幕顯示 5G 網路切片管理介面，呈現三種切片類型及其資源配置

3GPP 標準與 Cloud Native

3GPP 如何定義 Cloud Native 5G

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

Release 15（2018）：

  • 定義 SBA（服務化架構）
  • NF 透過 HTTP/2 通訊
  • 引入 NRF（服務發現）

Release 16（2020）：

  • 增強網路切片
  • 邊緣運算整合（MEC）
  • 改進服務通訊

Release 17（2022）：

ETSI NFV 與 Kubernetes

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

  • ETSI GS NFV-IFA 029：定義容器化 VNF 的需求
  • ETSI GR NFV-IFA 047：Kubernetes 與 NFV 的整合指南

關鍵變化：

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

5G Cloud Native 技術棧

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

容器編排：

  • Kubernetes（業界標準）
  • OpenShift（Red Hat 企業版）

服務網格：

  • Istio（最常用）
  • Linkerd

可觀測性：

  • Prometheus + Grafana（監控）
  • Jaeger（追蹤）
  • Fluentd + Elasticsearch（日誌）

CI/CD：

  • GitLab CI / Jenkins
  • Argo CD（GitOps）

網路：

  • Calico / Cilium（CNI）
  • Multus（多網路支援）
  • SR-IOV（高效能網路）

儲存：

  • Rook-Ceph
  • 雲端儲存服務

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

電信商導入案例

Rakuten Mobile（日本）

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

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

架構特色：

  • 100% 軟體定義網路
  • 全部 NF 容器化
  • 多廠商整合（Cisco、Nokia、NEC 等）
  • 自建 Rakuten Communications Platform

成效：

  • 建設成本降低 40%
  • 營運成本降低 30%
  • 新功能部署時間從月縮短到天

Dish Network（美國）

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

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

  • AWS 為主要雲端基礎設施
  • 完全開放式 RAN（O-RAN）
  • 多雲策略

中華電信（台灣）

台灣領先的 5G 服務商。

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

  • 混合架構（部分雲原生）
  • 多廠商策略（Ericsson、Nokia）
  • 逐步容器化

技術挑戰與解決方案

挑戰 1：電信級可靠性

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

解決方案：

  • 多 AZ（可用區域）部署
  • 自動故障轉移
  • 混沌工程測試

挑戰 2：低延遲需求

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

解決方案：

  • 邊緣部署（MEC）
  • 高效能 CNI（SR-IOV、DPDK）
  • 資源預留

挑戰 3：高效能網路

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

解決方案：

  • SR-IOV 直接存取網卡
  • DPDK 用戶空間網路
  • eBPF 網路加速

挑戰 4：安全合規

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

解決方案：

  • 零信任架構
  • 端到端加密
  • 完整的稽核日誌

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

挑戰 5：技術人才

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

解決方案：

  • 內部培訓計畫
  • 與雲端廠商合作
  • 招募 DevOps 人才

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 Native

Cloud Native AI：如何在雲原生環境中建構 AI/ML 工作流程【2025】

如何在 Cloud Native 環境建構 AI/ML 工作流程？本文介紹 MLOps 與雲原生整合、Kubeflow 平台、GPU 資源管理，以及 AI 模型在 Kubernetes 上的部署與擴展策略。

Cloud Native

Cloud Native Database 選型指南：PostgreSQL、NoSQL 與雲原生資料庫比較【2025】

Cloud Native Database 是什麼？本文介紹 CloudNativePG（雲原生 PostgreSQL）、傳統資料庫 vs 雲原生資料庫差異、主流雲原生資料庫比較，以及選型決策指南。

Cloud Native

Cloud Native 完整指南：雲原生是什麼？架構、原則與實戰入門【2025】

Cloud Native 是什麼？完整解析雲原生定義、12 Factor 原則、CNCF 生態系、K8s 容器化架構。從入門到實戰，一篇搞懂 Cloud Native 雲原生架構！