基于云協同的聯通MEC邊緣網絡架構

江雪蓮

摘要：現行的聯通MEC邊緣網絡架構在實際中服務響應延時較長，且網絡帶寬利用率較低，整體缺乏協同性。文章提出一種基于云協同的聯通MEC邊緣網絡架構方案，對網絡架構邊緣云開通、行業云開通、共享邊緣云開通、行業云開通以及云網協同開通等功能進行設計，由數據層與控制層搭建網絡服務架構，利用模型對網絡服務標識與描述，通過網絡服務云協同計算，對邊緣網絡資源協同分配，將功能映射到網絡服務架構上，實現了基于云協同的聯通MEC邊緣網絡架構搭建。經實驗證明，文章構建的網絡架構服務響應延時較短，并且帶寬利用率較低，具有良好的應用前景。

關鍵詞：云協同；聯通MEC；網絡架構；帶寬利用率；服務標識

中圖分類號：TN929.5

文獻標志碼：A

0 引言

大型2B客戶往往節點遍布全國，存在邊緣與中心互聯、邊緣與邊緣互聯的需求，邊緣云可以滿足客戶對實時性、安全性要求較高的應用需求^［1］。云網一體給邊緣云提供敏捷供給與服務，邊緣云作為創新產品，需要與中心云（公有云、行業云等）打通生態，互利多贏。作為創新產品，邊緣云需要適配云網一體的框架，實現一體化供給、運營及服務，提升客戶感知，持續打造領先口碑。傳統網絡架構存在網絡服務延時較長、網絡帶寬利用率較低等缺陷，已經無法滿足實際需求。為此，文章提出基于云協同的聯通MEC邊緣網絡架構。

1 網絡架構功能需求

本次設計的聯通MEC邊緣網絡架構功能需求主要包括邊緣云開通、行業云開通、共享邊緣云開通、行業云開通以及云網協同開通。其中邊緣云開通下單渠道為政企中臺，主要受理無云主機相關信息，開通流程：客戶經理在政企中臺下單；平臺將訂單轉發給創新融合平臺；創新融合平臺運維人員聯系客戶獲取資源的信息；網絡人員規劃VPC ID、子網信息，配置網絡；通知運維人員人工先創建租戶，再創建云主機，采用默認安全組，針對該類業務根據用戶、資源池和云主機IP定位云主機；運維人員反饋云主機賬號和云主機IP^［2］。網絡開通包含以下4種場景：云主機內網自動化開通、云主機訪問公網權限自動化開通、云主機訪問5G網絡權限自動化開通、云主機訪問專線權限自動化開通；實現云邊協同產品的同開同停；實現云邊網絡的可視化運維^［3］。共享邊緣云開通功能需求主要為解析MEC訂單，按照《20220401中國聯通MEC邊緣云Edge-OSS與政企中臺接口規范v1.0》規范解析訂購、變更、銷戶業務訂單數據；訂單展示，支持在界面查詢訂單云主機信息^［5］。訂單狀態轉換如圖1所示。

2 邊緣網絡服務架構搭建

根據網絡架構功能需求，搭建聯通MEC邊緣網絡服務架構。服務架構由數據層與控制層組成，其中數據層由無線接入點、接口以及SDN協議組成，接口包括解析邊緣mec訂購業務接口、解析mec修改業務接口、解析mec刪除業務接口、邊緣節點查詢接口、訂單進度查詢接口等應用程序接口，通過接口與控制層中控制器、云服務器等設備連接，接收控制層中的網絡信息。控制層由SDN控制器、云服務器、邊緣服務器組成，采用集中式部署方式部署各個控制設備、服務設備。控制器是網絡架構的核心，主要用于對整個聯通MEC邊緣網絡集中控制和資源調度。

3 網絡服務標識

為了實現網絡服務架構中海量服務/資源的動態發現定位以及網絡服務信息的云同步下發，利用全維可定義的服務標識模型對網絡服務信息標識與描述。將聯通MEC邊緣網絡服務標識定義為一組多維數組，其用公式表示如下：

W=｛C，X，Z，H｝（1）

式中，W表示邊緣網絡服務獲取所需的全維參數；C表示服務位置信息維度；X表示服務類型信息維度；Z表示服務性能信息維度；H表示服務安全信息維度。利用模型對全維參數表示，其用公式表示為：

式中，SID表示邊緣網絡服務標識；a₁表示位置信息維度中自治系統（AS）號；a₂表示客戶端經緯度；a₃表示移動位置；a₄表示衛星軌道；b₁表示類型信息維度中的視頻服務；b₂表示應用服務；b₃表示網絡傳輸服務；c₁表示性能信息維度中的質量要求/性能；c₂表示帶寬要求/性能；c₃表示時延要求/性能；c₄表示分組丟失要求/性能；d₁表示安全信息維度中的信譽等級；d₂表示保密系數；d₃表示安全等級；d₄表示完整性。利用上述公式對邊緣網絡服務標識，為后續邊緣網絡資源云協同計算奠定基礎。

4 基于云協同的網絡架構搭建

利用云協同技術與邊緣計算技術對網絡資源協同分配，將功能映射到服務架構上，從而搭建一個完整的聯通MEC邊緣網絡架構。用戶應用服務被標識后，通過云協同計算，將標識后的服務協同分配到邊緣服務器上，由邊緣服務器對服務做出響應。服務協同分配過程分為服務上傳、處理、下載3個部分，根據移動設備下行鏈路傳輸速率，服務分配到各個邊緣服務器所需的時延為：

式中，T表示應用服務分配到邊緣服務器所需的時延；t₁表示服務上傳時延；t₂表示服務處理時延；V表示移動設備的計算任務數據大小；q表示移動設備下行鏈路傳輸速率；S表示移動設備應用服務的計算需求；p表示應用服務的計算資源分配變量。

5 實驗論證

5.1 實驗準備與設計

為了驗證本次提出的基于云協同的聯通MEC邊緣網絡架構搭建方案的合理性與可行性，選擇某兩個傳統網絡架構為對比，分別為基于SDN與基于PTN技術，以下用傳統架構1與傳統架構2表示。實驗使用Python程序設計實驗模型，模擬邊緣云開通、行業云開通、共享邊緣云開通、行業云開通以及云網協同開通等服務請求，并將服務請求接入邊緣服務器。在實驗中所有的應用服務請求數據被分成不同數目，并生成大小統一的服務數據包單元，實驗中服務數據包數據共10 000個，每隔0.1 s發送一個服務請求。在以上參數設置情況下，實驗運行1 000次，為了保證實驗結果的可靠性，3種架構運行配置相同，具體配置為：英特爾i8CPU，12 GB隨機存取存儲器，Windows2010操作系統的電腦上。以下對3種網絡架構具體性能進行檢驗與測試，為了降低隨機性的影響，本次實驗數據采用平均值。

5.2 實驗結果與討論

實驗以網絡延時與帶寬利用率為3種網絡架構性能評價指標，首先對網絡架構的服務請求延時測試，實驗以向網絡發送應用服務請求時間為起始時間，以用戶得到邊緣云開通、行業云開通、共享邊緣云開通、行業云開通以及云網協同開通等服務響應時間為終止時間，使用KHFA軟件測量到服務延時時間，并以服務請求數量為變量，對比不同服務請求數量下網絡架構服務延時，具體數據如表1所示。

從表1可以看出，隨著應用服務請求數量的增長，3種架構所表現出來的性能不同，其中本次構建的網絡架構服務響應延時相對較短，雖然會隨著服務請求數量的增加，延時會有所增長，但是增長幅度比較小，當服務請求數量達到100個時，網絡架構延時僅為0.48 s，可以將延時控制在1 s以內，說明本文構建網絡架構延時性能良好；而兩種傳統架構服務響應延時相對較長，并且會隨著服務請求數量的增加大幅度增長，當服務請求數量達到100個時，傳統架構1與傳統架構2服務響應延時分別為8.13 s、8.46 s，遠遠長于本文架構，說明本文架構延時性能優于傳統架構。

為了進一步驗證本文架構的適用性，對3種架構帶寬利用率進行測試，帶寬利用率越高，表示網絡架構云資源分配越均衡，其計算公式為：

式中，r表示網絡架構帶寬利用率；i表示網絡流量數量；e表示第i條流量的實際帶寬；w表示第i條流量的指定帶寬。實驗以網絡負載為變量，網絡負載持續時間10 s，然后增長0.2 s，記錄實驗數據，將其代入上述公式，計算出不同網絡負載情況下3種網絡架構帶寬利用率，并繪制實驗結果如圖2所示。

從上圖可以看出，隨著網絡負載值的增長，3種架構所表現出來的性能不同，本文架構帶寬利用率相對較高，并且受到網絡負載影響較小，當網絡負載為1.2時，本文架構帶寬利用率為92.45%，兩種傳統架構分別為62.15%，54.22%，遠遠低于本文架構。實驗結果證明，無論是在延時方面還是在網絡帶寬利用方面，本文架構均表現出明顯的優勢，具有良好的可行性。

6 結語

云邊協同能更好地滿足大型2B客戶需求，文章以5G創新能力融合平臺為基礎，基于MEC應用場景需求以及MEC系統架構，提出基于云協同的聯通MEC邊緣網絡架構，開發了MEC網絡能力協同系統，結合邊緣計算技術，搭建聯通MEC邊緣網絡架構，實現一體化供給、運營及服務，逐步完善MEC邊緣網絡能力協同功能，并通過實驗論證了該網絡架構具有良好的適用性與可靠性。此次研究對云協同技術在聯通MEC邊緣網絡架構中的廣泛應用具有一定的推廣意義，同時豐富了該方面的理論，具有一定的理論意義。

參考文獻

［1］葉迎暉，施麗琴，盧光躍.無線供能移動邊緣網絡中計算時延最小化資源分配方法研究［J］.電子與信息學報，2022（5）：1839-1846.

［2］秦靖堯，韓子媛.基于5G網絡的MEC邊緣計算平臺在電力系統中的部署研究［J］.集成電路應用，2022（2）：98-101.

［3］劉伯陽，馬杰，白靜，等.基于MDP的協作認知邊緣計算網絡資源分配方案［J］.西安郵電大學學報，2022（1）：23-28.

［4］鄭遠鵬，張天魁，朱光宇，等.MEC系統中面向網絡切片的3C聯合資源分配算法［J］.北京郵電大學學報，2021（5）：41-47.

［5］沈剛，陳斌，毛明榮.基于邊緣云協同網絡的數據存儲容災備份仿真［J］.計算機仿真，2021（5）：380-383，412.

（編輯 王雪芬）

Unicom MEC Edge network architecture based on cloud collaboration

Jiang Xuelian

（China United Network Communications Co.， Ltd.， Guangdong Branch， Guangzhou 510000， China）

Abstract： Because the current Unicom MEC edge network architecture has a long service response delay time in practice， and the low network bandwidth utilization rate， and the overall lack of synergy， a Unicom MEC edge network architecture scheme based on cloud collaboration is proposed. On network architecture edge cloud opening， industry opening， sharing edge cloud opening， cloud opening and cloud network collaborative opening function requirements design， built by the data layer and control layer network service architecture， using the model of network service identification and description， through network services， the edge network resource allocation， function mapping to the network service architecture， implements the network based on the cloud collaborative unicom MEC edge network architecture structures. It is proved that the network architecture constructed in this paper has a relatively short response delay time and a low bandwidth utilization rate， which has a good application prospect.

Key words： cloud collaboration; unicom MEC; network architecture; bandwidth utilization; service identification