（來源：ETSI）

多接入邊緣計算 (MEC) 為應用程序開發人員和內容提供商提供云計算能力和網絡邊緣的 IT 服務環境。該技術由ETSI ISG MEC標準化，支持開放的市場和新的商業模式，包括服務多個用例和應用程序的可能性。邊緣計算環境還具有市場參與者多樣化的生態系統，從基礎設施所有者到服務提供商、系統集成商和應用程序開發商。這種情況的特點是復雜的多供應商、多供應商、多組設備，包括硬件和軟件設備。作為額外的復雜程度，典型的現實世界場景包括多個運營商的存在，每個運營商都有自己的邊緣計算基礎設施、網絡能力和客戶群。

在這種異構環境中，為了向客戶提供全球邊緣計算服務，運營商意識到需要協作并形成所謂的 MEC 聯盟，在最近發布的報告 GR MEC中定義和分析了這些用例和關鍵問題035 “實現跨MEC系統部署和MEC-Cloud系統協調”。

點擊查看完整大小的圖片

MEC 聯盟有助于為客戶提供跨移動網絡運營商（MNO 環境）多樣化生態系統的無縫訪問。（來源：ETSI）

該研究由日本電信運營商 KDDI 牽頭，得到其他運營商的支持，并與許多其他 MEC 成員和參與者合作，還考慮了 GSMA OPG（運營商平臺組）的要求。GSMA 計劃的目標是使邊緣計算成為運營商服務，使用邊緣應用程序的客戶應該可以無縫訪問具有邊緣體驗質量的應用程序，無論應用程序是在其運營商的邊緣云上運行，還是在其邊緣云上運行。不同的（但聯合的）操作員。ETSI ISG MEC 的工作確實旨在引入可以實現這一目標的適當標準（也與 3GPP 和其他機構合作）。

更詳細地說，ETSI GR 035報告強調了與 MEC 聯盟相關的問題、差距和解決方案以及建議，MEC 聯盟被定義為“能夠共享使用 MEC 服務和應用程序的 MEC 系統的聯盟模型”。各種用例推動了 MEC 聯盟的建立，本報告對它們進行了分析，并描述了可能的解決方案和相關評估：

V2X服務的MEC聯合場景

為 V2X 服務啟用 MEC 聯盟的多運營商協議

MEC和云系統之間的應用實例傳輸

涉及 MNO 網絡中的 MEC 系統的系統間通信

連接不同服務的MEC聯合場景

沉浸式 AR 游戲的 MEC 聯合場景

訪問網絡上邊緣服務可用性的 MEC 聯合方案

邊緣節點共享的 MEC 聯合場景

特別是，最近加入 ETSI MEC 成員的 5GAA（5G 汽車協會）的汽車利益相關者對用例 #1（“V2X 服務的 MEC 聯合場景”）感興趣。這種 V2X 服務（即多 MNO、多 OEM、多 MEC）的 MEC 聯合場景在智能城市中很典型，其中具有不同 SIM 卡和網絡訂閱的汽車連接到不同的運營商，每個運營商具有不同的能力，在MEC 平臺和/或 API 的可用性條款。從這個角度來看，實現 MEC 應用程序之間的 MEC 系統間通信，以及應用程序的互操作性和可移植性，是整個汽車生態系統提供 V2X 服務的關鍵需求（從移動網絡運營商、原始設備制造商、技術提供商、城市市政當局和其子公司、監管機構和政策制定者）。

MEC 系統發現，包括安全（認證/授權、系統拓撲隱藏/加密）、計費、身份管理和監控等方面，是形成 MEC 聯盟的必要前提。

MEC 平臺發現，通過 MEC 系統交換有關其 MEC 平臺的信息，即它們的身份、它們的共享服務列表以及授權和訪問策略。

MEC 平臺層面的信息交換，滿足 MEC 服務消費需求，或 MEC 應用間通信。

汽車領域的另一個有趣用例是#8（“邊緣節點共享的 MEC 聯合方案”），其中 MEC 聯合也可用于從一個運營商共享邊緣能力到另一個運營商，其中一個運營商具有某個區域沒有邊緣資源。這對于可能希望加入聯盟并從彼此的邊緣計算基礎設施中受益的所有運營商來說特別方便，因為無論客戶位于哪個國家/地區，都可以為其客戶提供全球用戶體驗。除了第一個用例引入的要求外，該用例還需要運營商 A 的 MEC 平臺和運營商 B 的網絡網關之間的連接（反之亦然），以優化從一個運營商到另一個運營商的服務交付。最后，

GR 035定義的要求（不僅與汽車領域相關，而且原則上服務于所有 MEC 用例）自然導致了 ETSI MEC 規范工作的開始（工作項 GS 040），其重點是定義適當的 MEC 聯合 API 作為不同 MEC 系統的聯合管理器之間的通信手段（即所謂的 EWBI，用 OP 的話來說）。

ETSI MEC GR 035報告是該領域的第一項研究，考慮到 GSMA 對 MEC 聯盟的要求，ETSI ISG MEC 的目標是與 3GPP 和開源社區合作，以提供可以支持互操作服務的一致標準提供給邊緣計算生態系統中的所有利益相關者。

審核編輯 黃昊宇