基于約束的自適應QoE算法設計 ①

鄭小蘭

(福州理工學院，福建 福州 350506)

0 引 言

霧計算技術作為云計算技術的延伸主要部署在靠近用戶側。為提升霧架構的QoE，通常將載荷的計算移至本地實施。然而這樣卻付出了開銷的代價。為此業界對此展開了相關研究。文獻[1]提出了基于最小篩選的均衡機制(MB)。主張通過統計整個霧系統所有服務器節點的用戶提請連接數，進而鎖定連接規模最小的那個服務器節點來應對霧用戶發起的任務請求。基于MB算法思路，文獻[2]設計了基于權重最小化的均衡機制(WMB)。該機制考慮到了霧系統中服務器設備負載能力多變的客觀情況而引入了權重參量。然而每一次霧用戶提請任務的持續時間和任務所需消耗開銷資源存在變數。對于每一個服務器設備而言，即便其和霧用戶之間的響應連接與權重參量呈一定的比例關系，卻依舊存在響應連接規模和負載能力不匹配的情形。故提出基于約束的自適應QoE算法設計。旨在以縮短霧用戶等待計算響應時長為約束探討服務器節點與任務請求的優化適配機制。

1 方案分析

自適應QoE算法目標是最小化響應終端用戶任務請求的時延代價[3]。此處將算法部署的體系依次分為三層，分別是云數據中心層、霧節點層、終端用戶層。在霧終端用戶向距離其最接近的霧節點發起任務請求后，霧系統開始對霧節點展開計算資源評估。若評估結果顯示無法受理任務請求則將該任務請求轉發給與此霧節點相鄰的其他霧層服務器，如此循環評估直至遍歷到合適的霧服務器節點。若算得該霧節點具有足夠的開銷則可用于響應任務請求。用于響應任務請求的霧服務器將最終計算結果送至霧層中最接近于霧用戶的那個霧服務器，進而將霧計算數值響應給發起任務請求的霧用戶。要是霧層無法遍歷到合適的霧節點，此任務請求將被向上提交到云數據中心層。經云層服務器節點計算處理后將結果下發至與該云節點最為接近的霧層中的霧服務器，然后再響應給霧終端用戶。

2 算法設計和部署

評估一個服務器節點能否有足夠的開銷用于自適應地應對霧用戶提請的任務計算請求，需綜合分析下列幾種情形。情形A：當CAll/σAll小于C(Ni)/σ(Ni)且RAll/σAll小于R(Ni)/σ(Ni)時，說明當前節點屬于重載情形；情形B：當CAll/σAll大于C(Ni)/σ(Ni)且RAll/σAll大于R(Ni)/σ(Ni)時，說明當前節點屬于輕載情形；情形C：當CAll/σAll大于C(Ni)/σ(Ni)且RAll/σAll小于R(Ni)/σ(Ni)，說明此時當前節點的連接規模雖小然而載荷度卻依舊很大；情形D：當CAll/σAll小于C(Ni)/σ(Ni)且RAll/σAll大于R(Ni)/σ(Ni)，說明此時當前節點的連接規模雖大載荷度卻反而很小。出現后面兩種情形主要緣于SDN數據流呈現突發[5]特征，用戶提請的任務請求規模、任務持續時長、服務器瞬時開銷資源均是動態隨機所致。

部署自適應QoE算法時可定義一個數組用于容納情形B和情形D下的節點，逐個遍歷數組中的節點直至為空。然后開始重新評估服務器的參數R(Ni)、RNull(Ni)、σ(Ni)、RAll、σAll、CAll，評估后若符合情形B和情形D的條件則可以放入數組內用于應對霧用戶提請的任務計算請求。

圖1 三種算法下的服務器載荷占用比

圖2 三種算法下的服務器閑置負載占比

3 算法實施

基于約束的自適應QoE算法以終端霧用戶可接受的等候時延為前提來降低服務器轉發任務請求的頻率。從QoE時延角度出發，應統籌考慮三種情形下霧層服務器執行任務請求時節點進行任務轉發操作的頻次，并盡可能地讓任務請求在霧層中就能夠得到順利的響應。基于此思想，整個算法的實施過程做如下規劃：

初始化自適應QoE算法各指標參量Mi、Ci、Bi并定義一個數組后，首先通過評估R(Ni)、RNull(Ni)進而求出σ(Ni)。其次，分別計算出σAll、CAll、RAll然后分析RAll/σAll和R(Ni)/σ(Ni)關系。如果前者小于后者，則返回至第一步驟；反之將Ni存放到數組內。隨后判斷數組內的節點是否為空。若非空數組則返回執行步驟一；若為空數組再分析是否還有終端用戶發起任務請求。如果仍有則重返步驟一，如果沒有待執行的任務請求則終止計算。

4 算法測試

選用Matlab作為自適應QoE算法的測試[6]環境。為云層配置15GHz的計算能力，霧層中霧服務器的計算能力配置為f(GHz)=[f1,…,fm]=[1.5、1、2.5、0.7、0.6、0.9、0.8、0.5]，一次任務傳輸的時延設置為Dt(s)=[0.02、0.17、0.1、0.19、0.09、0.1、0.08、0.06]。并為霧服務器f1和霧終端配置0.05s的任務傳輸時延。

圖1曲線是三種算法機制下節點受理相同用戶任務請求連接規模時，節點表現出的載荷占用比。由于MB算法并未顧及終端用戶提請任務計算請求的數據規模，一味地將任務轉發給連接數最少的節點來受理。這勢必導致服務器節點載荷占用比的變化起伏不定。WMB雖然克服了MB所忽略的關鍵環節但未考慮到隨機突發特征環境下，終端用戶提請的任務數據規模存在多變情形所引發的載荷變化情況。QoE算法則是調用那些當前載荷度低于所有節點平均載荷度的節點。因此節點載荷度依然以最小的變化幅度徘徊在系統均值左右。

圖2所示三條曲線描述了三種算法機制下的同一個終端用戶發起任務計算請求后，服務器節點表現出的閑置負載占比變化情況。顯而易見，由于只考慮用戶請求連接規模忽略了不同節點性能存在差異問題，MB算法機制下的節點在載荷占比指標上很容易出現兩個極端，要么很小要么很大，因此負載起伏不定。WMB算法思想是在MB基礎上引入權重系數用于動態計算某些節點的優越性能。此機制下的節點載荷占比雖總體較為均衡但卻付出了系統開銷的代價。相比之下本文構思的QoE算法通過統籌考察節點的權重系數、連接規模、載荷度等來客觀地動態地評估所有節點的載荷使用情況。QoE機制下的節點載荷占比基本徘徊在系統均值附近。

5 結 語

QoE算法的構思是從全局角度出發以時延控制為目標，為霧用戶設計的一種自適應能力較強的算法方案。該方案通過引入權重參數為任務請求合理地計算出可用于響應的服務器節點。評估結果表明相對于傳統研究方案，該QoE算法的部署具有良好的普適性。