# [原文翻譯] 7 種私人 5G 網路的部屬情境 :::info 原文: [7 Deployment Scenarios of Private 5G Networks](https://www.netmanias.com/en/?m=view&id=blog&no=14500) ::: 原文對於如何建構私有的 5G 網路進行的深度剖析。 一般來說,私人的 5G 網路可以經由兩種管道實現: 1\. 部屬一個物理上獨立的私人 5G 網路,它完全獨立於一般電信商所提供的公用 5G 網路 (就像在企業中構建有線 LAN 或 Wi-Fi WLAN),在這個案例中,私人 5G 網路的布建可由企業或是電信商完成。 2\. 建構一個與公用 5G 網路共享資源的私人 5G 網路。 ![](https://i.imgur.com/V5QW17D.png) ## 進入正題 本文中,一共有 7 種情境,分別是: ### 1. Isolated 5G LAN built by the enterprises (Local 5G Frequency, Full Private, No-Sharing) ![](https://i.imgur.com/8yFOBBe.png) 企業部屬了完整的 5G 網路集合,該集合包含了: - gNB - UPF - 5GC CP (Control Plane) - UDM - MEC 該企業部屬的 5G 網路所採用的 5G 頻段並不是由電信商認證的頻段,對於私有頻段是由政府分配的國家 (日本、德國和美國等先進國家是可能的)的情況下,這是一種可構建的架構。 **誰來建構**: 在這個案例中,通常由企業來建構他們的私有 5G 網路,但根據不同國家的策略,也有可能會由第三方 (電信營運商) 負責企業私有 5G 網路的建置。 企業可以使用本地的 5G 頻段打造出他們的 5G LAN,以擺脫傳統有線 LAN 與無線 LAN 所帶來的煩惱 (有線 LAN 的佈線工作、距離短、無線 LAN 的安全問題和穩定性)。 **優點:** 由於企業內部有獨立的 5G 網絡環境, - Privacy and Security 私有網路與公用網路是在物理上被區隔開來的,所以能提供完整的資料安全性。 - Ultra-Low-Latency 由於設備和應用服務器之間的網絡延遲在幾毫秒內,因此可以實現 URLLC 應用服務。 - No optical fiber to the building - 即使營運商的 5G 網路出現問題,也不會影響到企業的私有 5G 網路。 **缺點:** - Deployment cost 對一般企業來說,自費購買和部署一套完整的 5G 網路並不容易。 - Operational personnel 了解 wired Ethernet LAN, wireless Wi-Fi LAN 的人才稀少,企業需要對的工程師才有辦法維護與建置 5G 網路。 ### 2. Isolated 5G LAN built by Mobile Operators (Licensed 5G Frequency, Full Private, No-Sharing) ![](https://i.imgur.com/T885KST.png) 在這個 Case 中,所有的架構都與 Case 1 相同。 唯一不同的地方是: 電信運營商使用自己的許可 5G 頻段在企業中構建和運營 5G LAN。 ### 3. RAN sharing between private network and public network ![](https://i.imgur.com/wVsuHhJ.png) UPF, 5GC CP, UDM 以及 MEC 由企業部屬,這些元件在物理層面上與公用網路是分開的,僅有位於企業內的 5G 基地台 (gNBs) 與公用網路共享。 在上圖中,標記為**黑色**的資料流屬於私有網路,用於傳遞資料到企業私有的 UPF 上。 標記為<b style="color: blue;">藍色</b>的資料流屬於公用網路,用於傳遞資料到電信營運商的邊緣雲中的 UPF 上。 換句話說,私人網路的資料流 (像是一些機房內資料的 video data) 以及公用網路的資料流 (像是 voice 以及 internet 封包,仍會傳送到電信商的 5G 網路中) 是完全區隔的,雖然在這個案例中他們共用了 5G 基地台,但是在私有網路的 RAN 層級上,有心人士仍非常難去蒐集重要資料。因此,可以確保私有網路的資料流安全無虞。 私有且特定的 5GC CP 以及 UDM 是建構在企業中的,因此,私有網路用戶的相關資訊是被存放與被管理在企業本地的,並不會洩漏到企業外部。 位於企業內的 UPF 以及 MEC,確保了以下路徑的 ultra low delay communication: ``` device - gNB - UPF - MEC ``` 使其適用於使用 URLLC 應用程序的企業,例如: 自動駕駛和即時機器人與無人機的控制。 ### 4. RAN and Control Plane Sharing between private and public network ![](https://i.imgur.com/peUeIYw.png) - 私有的 MEC 以及 UPF 被建置在企業中。 - 5G 基地台建置在企業中,但可供私有與公用網路共用。 - 電信營運商的邊緣雲中的 5GC CP 以及 UDM 同樣共享在私有與公用網路間。 在這個 Case 中,MEC 以及 UPF 為物理層面上的分離,其餘的原件為邏輯層面上的分離 (共用硬體資源,但資料流分開)。 在上圖中,標記為**黑色**的資料流屬於私有網路,用於傳遞資料到企業私有的 UPF 上。 標記為<b style="color: blue;">藍色</b>的資料流屬於公用網路,用於傳遞資料到電信營運商的邊緣雲中的 UPF 上。 換句話說,私人網路的資料流 (像是一些機房內資料的 video data) 以及公用網路的資料流 (像是 voice 以及 internet 封包,仍會傳送到電信商的 5G 網路中) 是完全區隔的,就像 Case 3 一樣,雖然在這個案例中他們共用了 5G 基地台,但是在私有網路的 RAN 層級上,有心人士仍非常難去蒐集重要資料。因此,我們同樣可以確保私有網路的資料流安全無虞。 私有網路設備與公有網路設備使用的 Control Plan functions (Authentication, mobility, etc.) 皆由電信營運商的 5GC CP 以及 UDM 處理。 也就是說,私有 (企業) 的網絡設備、gNB 和 UPF 與電信運營商的 公有網絡 (通過 N2、N4 接口) 互通並由其管理。 私有網絡設備的操作信息和訂閱信息存儲在移動運營商的服務器中而不非存放於企業內部,這可能會是潛在的問題。 位於企業內的 UPF 以及 MEC,確保了以下路徑的 ultra low delay communication: ``` device - gNB - UPF - MEC ``` 使其適用於使用 URLLC 應用程序的企業,例如: 自動駕駛和即時機器人與無人機的控制。 ### 5. RAN and Core Sharing (End-to-End Network Slicing) between private and public network ![](https://i.imgur.com/WytNhas.png) 在這個 Case 中,只有 gNB 部屬在企業之中,其餘的元件均與電信營運商共用,公有與私有網路僅在邏輯層面上分割: **logically separated 5G RAN and Core**。 不像是 Case 3 與 Case 4,UPF 與 MEC 也都改用電信營運商提供的元件,因此,私有 5G 設備與內部網 (LAN) 設備 (像是: PC 或本地內部網路伺服器) 間沒有本地路徑,導致所有的資料都須經過電信營運商的 UPF 再通過租借的線路回傳到企業內部的 LAN 設備。 此外,為企業中的 5G 設備提供 5G 網路服務的 MEC 位於遠離企業的電信運營商的邊緣雲中。 與 Case 4 一樣,企業將運營和訂閱訊息存放在電信運營商的網路上是令人不安的。 綜合上面所述,這可能會造成資料傳輸上的安全問題。 ### 6. N3 LBO (Local Breakout): Case of SK Telecom in Korea ![](https://i.imgur.com/93RRuUh.png) 在上圖的 (a) 中,gNB 被部屬在企業之中,當使用電信商網路的設備連上網路,N3 GTP 隧道會建立在 gNB 與 UPF 之間。 在上圖的 (b) 中,企業推出 MEC Data Plane (非 3GPP 認證的設備: **ETSI MEC**) 以及 MEC Applications。 電信運營商的 Orchestrator (編排器) 中的移動邊緣平台 (MEP) 通過 Mp2 接口向 MEC DP 發送 traffic rule。 MEC DP 檢查所有來自 gNB (GTP Decap) 的 GTP 隧道的資料封包,若其目標 IP 地址顯示其為本地流量,則將用戶 IP 數據封引導到內部專用網路。 雖然這種方法並不是 3GPP 所定義的標準方法,但可以將專用網路的流量與公共流量分開。 並且,由於 MEC DP 不是 3GPP UPF,因此 MEC DP 無法執行專網設備的移動管理和計費功能 (當然,MEC DP 可以實現一些基本功能,因為運營商可以自行實現這些功能的專有規範)。 ### 7. F1 LBO (Local Breakout): Case of KT in Korea ![](https://i.imgur.com/WPQts7m.png) Case 7 與 Case 6 沒有太大的差異,不同的地方在於只有 RU/DU 會被部屬在企業內,CU 則位於電信營運商的邊緣雲內。並且,私有網路的流量是從 F1 接口本地中斷的,而不是 Case6 中使用的 N3 接口。 > 延伸閱讀: [Open RAN之RU、DU、CU: Why?What?When? How?](https://www.sdnlab.com/24553.html) ## 總表 此表是我自行整理的,若比較有誤歡迎指正。 | / | Case 1 | Case 2 | Case 3 | Case 4 | Case 5 | Case 6 | Case 7 | | -------- | -------- | -------- | -------- | -------- | -------- | -------- | -------- | | 安全性 | 非常安全 | 非常安全 | 安全 | 有風險 | 有風險 | 安全 | 安全 | | 成本 | 極高 | 極高 | 高 | 中 | 低 | 低 | 低 | | 傳輸效率 | 高 | 高 | 高 | 高 | 低 | 高 | 高 |