工研院資通所 陳昀暄 陳建成 王俊傑

本文針對多接取邊緣運算（Multi-access Edge Computing, MEC）中的快取應用服務進行探討。縱使邊緣運算平台（Mobile Edge Platform, MEP）具有數據暫存服務，但各平台之間皆獨立運作並缺乏聯繫，導致對用戶的快取應用服務效能不彰，因此，本文藉以提升內容快取（content cache）的命中率（hit ratio），為用戶提供較好的使用體驗。

MEC快取技術問題與改善

當用戶透過網路向遠地資料庫取得內容時，從請求到回應具一定程度的等待時間，所花費的網路流量成本也很高，而文獻[1]思科（Cisco）更是預測，到了2019年時，在行動網路的快取服務中將會有72%的網路流量為視頻服務，對於此類較大型的資料回應需要在用戶端和伺服器之間進行多次往返通訊，將是拖延伺服器可以使用及處理內容的時間，同時也增加用戶的行動數據傳輸成本。對此，文獻[2]將多接取邊緣運算（MEC）應用於多媒體影音服務上，藉由MEC帶來計算和存儲資源能力，增強行動網路服務的傳輸吞吐量與服務效率，而文獻[3]分析用戶訪問內容的熱門度與邊緣節點的緩存能力，使這些邊緣節點能著重暫存熱門且將被存取的內容，供使用者可以就近取得所需的資料，而不必每次向原始資料庫存取。

其中，運作著MEC服務的邊緣運算平台（以下簡稱MEC平台或MEP）[4]所擁有的資源有所限制，當快取儲存空間不足時，便須進行快取替代策略。在電信網路中著名的演算法有FIFO、LRU與LFU[5]。FIFO（First In，First Out）即先進先出的原理，如同隊列的特性，當暫存空間不足時，淘汰儲存在儲存伺服器最悠久的內容。但FIFO未考量用戶存取的特性與趨勢，因此，LRU（Least recently used）及LFU（Least Frequently Used）演算法納入內容的存取時間與次數進行考量，LRU針對最長時間未被使用的內容進行淘汰，而LFU針對內容的存取頻率進行比較，淘汰存取頻率最低的內容。所以，MEC的快取伺服器若能夠有效地重複使用先前取得的資源，對於網路效能最佳化將是非常關鍵的一環。

然而，面對MEC在快取處理上的問題，鑒於MEC被設計建立在無線接取網路內，部屬範圍廣泛，雖然貼近用戶並提供即時的雲端運算能力，同時，卻導致各個邊緣運算平台皆獨立地運作，不同的運算平台之間缺乏資訊交流，在數據分析上可能降低精準度與真實性。

以影音服務應用例來說，網路營運商透過MEP上架快取服務，將用戶影音資料進行快取，當後續的相關用戶欲觀賞相同影片時，可以直接地透過MEP取得影片，藉此大幅節省後端骨幹網路（Backhaul Network）的資料流量。然而，在數據不足夠的情況下，進行LRU或LFU演算法，可能導致即將熱門的影片被淘汰掉。也因此，本文將探討MEC技術中進行大型資料的快取服務下所衍生的潛在問題，並進一步提升MEC cache的hit ratio。

以圖1的影音服務應用情境為例，在基地台1與基地台2服務範圍內有大量正在觀看影片的行動用戶，為提供更快速的影片存取，分別在基地台1及基地台2部屬MEC服務，即MEP1及MEP2。而MEP1及MEP2的暫存空間內儲存有最熱門的影片及紀錄相關的下載次數。因此，當一個新的影片需被儲存在MEP2的暫存空間但MEP2的暫存空間不足時，

• 未考慮鄰近MEP1資訊的替代策略：直接採用LFU替代演算法的MEP2將會捨棄下載次數最少的影片#01。此時，當正在觀看影片#01的行動用戶從基地台1移動進入基地台2的服務範圍時，原先儲存在MEP2暫存空間上的影片#01已被移除，導致該行動用戶需要重新連線至遠端伺服器下載影片，進而延長了存取時間。
• 參考鄰近MEP1資訊的替代策略：將鄰近MEP1的影片下載資訊帶入LFU替代演算法後，使得原先被視為不熱門的影片#01，更變為影片#16並淘汰之。因此，在該策略下，對於正移動至基地台2服務範圍內且欲觀看影片#01的行動用戶，將可直接存取MEP2暫存空間上的影片#01，而無須連線至遠端的影片供應伺服器進行存取。

圖 1　影音服務應用情境

可能解決的方法

以大型資料快取的影音服務應用為例，用戶之間在地理位置上具備著相似的生活機能與文化背景，以及人與人之間的互動與組織，而各個地區藏有不同的習性與特色，進而用戶在存取資料上，使資料分布產生「區域特性」。因此，若要提升MEP的資料維度，除了自有的資源紀錄外，應進一步的參考相鄰MEP的資源，彼此間的資料進行共享，方能在人文興趣方面的網路內容進行分析，有效提升content cache的hit ratio。

本文提出MEC快取優化機制，擬在各自獨立運作MEP之間，建立起相對應的鄰居關係，透過MEP鄰居的資訊交換，擴大MEP的資料維度，可避免快取影音誤刪的風險。在本文提出的快取優化機制可以分為NeiMEC系統建立與NeiMEC-based LFU兩個階段，以下將依序介紹技術流程。

A.自動建立MEP鄰居關係之方法與系統

圖 2　自動建立MEP鄰居關係之系統

依ETSI MEC所公布的技術標準[6]中，MEC可布署於基地台（base station）或是於匯流聚合節點（aggregation site）。而根據MEP的運算能力及服務需求，一個MEP將服務一個或一個以上的基地台。本文以三個MEC服務各自部屬在一個基地台為例，提出一個自動建立MEP鄰居關係之系統架構，如圖2所示。底層的三個基地台之間利用Automatic Neighbor Relation （ANR）[7]功能偵測基地台彼此之間的鄰居關係，並由虛擬化出網路元件管理系統（Element Management Systems，EMS）和網路管理系統（Network Management System，NMS）進行基地台的資源管理。MEP透過EMS（或NMS）取得基地台的鄰居關係後，再交由MEC neighboring Manager（NeiMgr）進行多個MEP之間的管理。值得注意的是，當基地台的部署有所變化時，因為ANR可自動偵測基地台之間的鄰居關係，因此所對應的MEP鄰居關係將依據ANR自動偵測到的基地台鄰居關係而自動地被更新，無須另外花費人工成本針對每個設備進行手工設定。本文所提出的自動建立MEC鄰居關係之流程，如圖3所示。

圖 3　自動建立MEP鄰居關係之方法

首先，多個基地台可利用ANR功能取得彼此之間的鄰居關係，即步驟（1）。每一個MEP藉由NMS/EMS服務所提供的基地站關係資訊傳遞至NeiMgr，即步驟（2）~（4）。當任一個MEP（此例為MEP2）發起其鄰居關係詢問需求時，由NeiMgr接收到MEP2的請求後，並進行交叉比對目前的資料表格，找出相對應的MEP鄰居列表並回傳給MEP2，即步驟（5）~（7），MEP2即可與其鄰居MEP1自動建立鄰居關係以共享資訊，即步驟（8）。

B. NeiMEC-based LFU演算法

本做法在第一階段使MEC與相鄰的MEC進行連結的環境下，針對MEC平台中的快取伺服器空間不足時，透過相鄰資訊擴增資訊維度，淘汰真正較不受歡迎的內容，以提升內容命中率。但不同的內容對用戶的影響範圍可能不同，使得內容間參考相鄰資訊的程度可能具有不同的效益。針對相鄰資訊以提升內容命中率，應設計彈性的演算法，可解決內容之間的差異特性。本文提出的作法加入一個動態參數α、鄰居區域特性與LFU進行設計，其NeiMEC-based LFU演算法的核心概念如下式所示。

計算公式

以動態參數αj,ID針對不同鄰居（j）參考內容（content ID）的程度進行區別，更新F’ 後進行LFU演算法比較，淘汰真正較不熱門的影片或資訊。

圖 4　 NeiMEC-based LFU演算法流程

為了達到上述做法，本文透過Centralized Replacement Manager（CRM）進行管理與運算，如圖4所示。當MEP2欲進行內容淘汰時，將目前儲存在自有平台中的各影音紀錄（content ID及存取頻率）給CRM，CRM向NeiMgr取得該平台的鄰居資訊後，再向這些相鄰的MEP平台取得所需的紀錄，最後在CRM進行NeiMEC-based LFU演算法，計算出較不熱門的影片ID回傳給MEP2，以提升MEP2伺服器的內容命中率。

模擬成效

為驗證本做法的可行性與改善效益，本文針對不同儲存空間的快取伺服器與參考相鄰資訊的動態參數α進行內容命中率之實驗。當動態參數α等於0時，可以解讀為不參考相鄰資訊的做法，即原始的LFU。根據模擬數據，如圖5所示，可顯而易見的觀察到儲存空間增大，以利內容命中率提升；但在相同的儲存空間下，動態參數α>0，皆對命中率有所改善。然而，如本文先前提及，參考過多資訊也可能對內容進行誤判，導致命中率下降發生；以圖5中儲存空間為10及20單位大小為例，較佳的快取命中率分別是設定α=0.5及α=0.9。因此，針對動態參數α可藉由數據分析的方式，找出合適的α值，以利MEC在內容命中率有所提升。

圖 5　 內容命中率與動態參數α之比較

未來計畫、發展性及其價值

MEC技術具備了低延遲、高容量的特性，在距用戶較近的網路位置提供運算及儲存能力，提升網路營運效率、增強資料傳送能力，為用戶營造更好的應用服務體驗。此外，根據文獻[8]，現階段MEC尚有其它議題與挑戰，如MEC系統的商業部署、MEC的快取應用、MEC的移動性管理，MEC的節能以及MEC的隱私與安全性等議題。在本文中，針對MEC的快取應用提出在多個MEC平台之間建立鄰居關係的新機制，當MEC伺服器的快取空間不足時，可以使用基於NeiMEC的LFU算法來提昇內容的命中率。藉由提升MEC快取的命中率，移動用戶可以直接在MEC平台上獲取內容，而不是在遠端的雲中，大幅減省存取內容的回應時間。

參考文獻

[1] CISCO White paper （2016）, “Cisco visual networking index: Global mobile data traffic forecast update, 2015-2020,” [Online]. Available: http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/vni-forecast-qa.pdf

[2] Xiaodong Xu, Jiaxiang Liu, and Xiaofeng Tao, “Mobile Edge Computing Enhanced Adaptive Bitrate Video Delivery With Joint Cache and Radio Resource Allocation,” IEEE Access, vol. 5, pp.16406-16415, Aug. 2017.

[3] J. Liao, K.-K. Wong, Y. Zhang, Z. Zheng, and K. Yang, “Coding, Multicast, and Cooperation for Cache-Enabled Heterogeneous Small Cell Networks,” IEEE Transactions on Wireless Communications, vol. 16, no. 10, pp.6838-6853. Oct. 2017.

[4] Tanwir, Gamantyo Hendrantoro, and Achmad Affandi, “Early Result from Adaptive Combination of LRU, LFU and FIFO to Improve Cache Server Performance in Telecommunication Network,” in Proc. ISITIA, 2015. pp. 429-432.

[5] ETSI GS MEC 003 （2016） Mobile Edge Computing （MEC）; Framework and Reference Architecture, V1.1.1. [online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf

[6] ETSI GS MEC 002 （2016） Mobile Edge Computing （MEC） Technical Requirements V1.1.1. [online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/002/01.01.01_60/gs_MEC002v010101p.pdf

[7] 3GPP TS 32.511 Telecommunication Management; Automatic Neighbor Relation （ANR） management; Concepts and Requirements, V14.1.0. [online]. Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2040

[8] Yuyi Mao, Changsheng You, Jun Zhang, Kaibin Huang, and Khaled B. Letaief, “A Survey on Mobile Edge Computing: The Communication Perspective,” IEEE Communications Surveys & Tutorials, vol. 19, no. 4, pp.2322-2358, Nov. 2017.