# Edge Computing Assisted Adaptive Mobile Video Streaming

## Paper detail
Mehrabi, Abbas, Matti Siekkinen, and Antti Ylä-Jääski. "Edge computing assisted adaptive mobile video streaming." IEEE Transactions on Mobile Computing 18.4 (2018): 787-800.

## Paper Introduction
### 1 Introduction
  目前主要的網路流量都來自影片。網路狀況可能會因為客戶競爭有限的頻寬而浮動，這會顯著影響使用者 QoE，尤其在移動中或無線網路中更明顯。為了避免播放干擾或重新緩衝的事件在串流中發生，很多公司採用可適性串流方式。
  其中最大宗的可適性串流為基於顧客的可適性策略。這種策略沒有使顧客、伺服器和網路一起合作，使得多個顧客同時存取網路時會發生不公平的資源分配且使用率低。
  作者們針對 MEC場景，設計了最佳化的網路輔助行動串流影音位元率可適性的方案。這個最佳化包含最大化 QoE 和公平的分配位元率。因為問題是 NP-hard，他們使用啟發式算法求解，且他們的解法不太需要調整參數。

### 3 Multi-Access Edge Computing Assisted DASH

#### 3.1 Overview

  下圖解釋了整個架構。這邊作者講的有點亂，我就我的理解解釋一下，若有錯請大家留言更正。
  edge sever 會設在基地台附近以使用網路，edge sever 主要就是存有一些影片供消費者快速取用。而 edge sever 裡會有一個 coordinator，這個 coordinator 負責做 (1) 客戶到 edge sever 的映射（顧客要由哪個 server （基地台）服務） (2)每個顧客影片的選擇。coordinator 做這些事會使用基地台的資訊和顧客的資訊。


#### 3.3 Quality of Experience
  [5]說 4 個最可以影響 QoE 的參數為 video bitrate、startup delay、stalling ratio 和 bitrate switching，本篇也是討論這 4 個
1. video bitrate：高位元率當然可以獲得較好的延遲，但若今天頻寬是有限且需要競爭的，此時高位元率也會增加卡頓的風險。
2. startup delay：他是從使用者點下播放到實際播放的時間，研究顯示一般使用者比較不會因為這個時間太長而不滿（至少跟卡頓比還可以忍受）。
3. stalling ratio：當由於下載吞吐量與視訊位元率相比過低而導致播放緩衝區變空時，就會發生停頓事件。因此，作者的系統旨在犧牲視訊品質（位元率），以便盡可能避免停頓事件，即，所有活動串流媒體用戶端的最低可能品質位元率總和不超過網路容量。
4. bitrate switching：這個也不能太常發生，他們考慮一個 E 作為切換前與切換後的差的累積。
#### 3.4 Fair Bitrate Allocation
  LTE 基地台通常會根據比例公平 (PF) 策略在每個時隙將無線資源調度給多個競爭的用戶端裝置 [4]。 更準確地說，無線資源塊根據客戶端的鏈路品質分配給客戶端。在傳統行動 DASH 用戶端的部署場景中，當視訊流量加密時，協調器將無法以正確的方式向客戶端分配位元率。相較之下，我們提出的網路輔助解決方案是為非傳統客戶端的部署場景而設計的，其中行動用戶端明確與協調器通信，以便在視訊流量加密的情況下進行正確的位元率分配。

  每個行動 DASH 用戶端根據基地台 PF 調度程序分配的資源份額選擇最可持續的位元率。 由於共享無線存取鏈路的多個 DASH 用戶端之間缺乏協調，基於客戶端的自適應啟發式方法在某些情況下可能會以不公平的方式分配位元率 [4]。 為了在競爭的客戶之間公平分配比特率，作為我們網路輔助優化解決方案的一部分，我們努力為每個客戶端選擇最佳的可持續比特率，該比特率在同一時間段與分配給其他同時客戶端的平均比特率差異最小。 更準確地說，公平位元率分配的目標是最小化每個客戶端 i 在其整個視訊串流會話期間的總體位元率偏差
#### 3.5 Load Balancing
  我們系統中的協調器透過將每個客戶端映射到最合適（負載最小但不一定距離最近）的伺服器來平衡邊緣伺服器（包括基地台）之間的負載，以便客戶端有效吞吐量（客戶端收到的實際吞吐量）最大化（也就是選一個最好的伺服器來服務客戶），其問題可以表示如下：


### 4 Joint Optimization of QoE and Fairness
  章節 3.5 解完了映射的問題，剩下的問題是如何在公平的情況下最大 QoE。由於 initial buffer delay 的影響很小，因此我們不考慮他，除此之外，考慮第 3.3 和 3.4 章所討論的，我們可以列出問題如下：


問題詳細說明可以去看論文。後續其證明這是一個 NP-hard 的問題。

### 5 Online Optimization Algorithms
#### 5.1 Client-to-Server Mapping

  他們用一個簡單的演算法來解第 3.5 章的問題。簡單來說就是顧客離所有基地台的平均距離太長時我們會找距離最短的去服務，但若顧客離所有基地台的平均距離很短，我們就會找吞吐量較高的去服務。

#### 5.2 Bitrate Selection with Parameter Auto-tuning

  這邊在解第 4 章提的問題，他的特色是會自己動態調整參數使我們不用調整。後續他們使用貪婪演算法求解，細節可以自己觀看，主要就是一開始會先找一個最高的位元率，後續會找的位元率會盡量避免切換影片品質跟滿足公平性（像 Subroutine 1: Startup Phase 的第 8 行）。

  之後再跟 5.1 章的方法結合變成 Algorithm 1 。

### 6 METHODOLOGY FOR SIMULATIONBASED COMPARATIVE EVALUATION

#### Other Approaches
  他們比較兩個 client-based 的做法 BBA 和 RBA，也就是不管公平性和顧客至伺服器映射這些網路協作的做法。還有一個有網路協作的做法[11]。

### Result
  跟 BBA 和 RBA 比較的話，可以看到大多數結果作者的方法在吞吐量和 initial delay 都比較好，但在切換頻率和幅度卻會在顧客分佈較不均勻時而較差（圖 4c 和 4d）。但除此之外，作者的方法在公平性的表現很好，切不太會受到 buffer 大小的影響。在第 9 章也有使用 LTE 模擬器模擬，效果跟前面差不多。

  跟[11]比的話，我們在公平性、位元率、使用率都比較好，只有切換頻率在顧客較多時會比較差。

  他們的改善在吞吐量較高或顧客之間的鏈路品質沒有差太多時特別明顯。

# Comment
  這篇考慮到顧客的位置和使用者的公平性，提出一個整體網路協作的想法。我認為這是一個很好的跨層設計想法，網路之間本來就有很多資訊，只是看我們有沒有拿來用。這篇的觀點也可以讓營運商和供應商參考，當然不能直接拿來用，但可以給他們一些 insight 讓他們思考還能怎麼使用一些可能可以簡單獲得的資訊來提升服務品質。這篇也做了大量實驗來分析他們的方法，就如同我說的，實驗越詳細越能增加你的可信度。