以行動應用程式為對象的效能導向流量排程演算法

國

立

交

通

大

學

資訊科學與工程研究所

碩

士

論

文

以行動應用程式為對象的效能導向流量排程演算法

Utility-Based Traffic Scheduling For Mobile Applications

研 究 生：柯承孝

指導教授：邵家健 教授

易志偉 教授

以行動應用程式為對象的效能導向流量排程演算法

Utility-Based Traffic Scheduling For Mobile Applications

研 究 生：柯承孝 Student：Cheng-Hsiao Keh

指導教授：邵家健 Advisor：John Kar-kin Zao

易志偉

Chih-Wei Yi

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

A Thesis

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science

September 2011

Hsinchu, Taiwan, Republic of China

i

以行動應用程式為對象的效能導向流量排程演算法

學生：柯承孝

指導教授

：

邵家健 易志偉

國立交通大學資訊科學與工程研究所碩士班

摘

要

在現今的移動通訊網路中，網路服務已經非常普遍，幾乎每位手機用戶都會使用到。 但隨著用戶數量迅速的成長，硬體設備漸漸無法滿足大眾的需求，導致網路傳輸速率緩 慢、應用程式服務品質下降，因此網路頻寬的不足已經成為一個全世界電信業者共通的 課題。若是要增加基地台數目及線路數量，成本將會十分昂貴且緩不濟急，應該從另一 個方面著手，試著降低多餘的資料傳輸量，並且尋找有效率的方式應用有限的頻寬資 源。 在本篇論文中，將代理伺服器此一元件引進現今的網路架構，設置於手機及網際網 路中。手機端的代理伺服器擁有快取的功能，可避免重複的資料傳輸，同時能控管與網 路之間的所有連線，並進行流量排程的工作。網路端的代理伺服器會定期向各個應用程 式的伺服器抓取新資料，儲存在它的快取中，同時在資料更新時，發送一短訊息告知手 機端。所有從手機端送出的資料要求訊息都須經過網路端的代理伺服器，若是代理伺服 器中的快取已經過期，才再向應用程式伺服器發送要求。 有了手機端及網路端的代理伺服器的支援後，本文中提出了基於此系統架構下的三 個目標: (1)避免重複的資料傳輸造成頻寬浪費。(2)減少網路流量超出負荷及壅塞的情 況。(3)針對每個使用者的需求以求將資料效益最大化。第一個目標可由代理伺服器提 供的快取功能獲得實現。第二及第三個目標則可由手機端的代理伺服器對資料流量進行 適當的排程來達到目的。因此，我們設計出一個以效能函數為基準的排程演算法。此效 能函數將以服務品質和個人偏好兩方面做考量來計算其值。演算法會調整每個連線的傳 輸順序及各自的流量，以即時的方式做排程，期使在一段時間內所獲得的效能函數值最 大化。 實驗部分是以模擬的方式進行，我們基於現在的行動網路架構選擇一個合理的網路 流量模型，並且加入了代理伺服器的支援。模擬所得到的數據結果，呈現出在有代理伺 服器進行快取和流量排程的情形下，能有效的降低網路流量、減少壅塞的發生以及增加 資料效益。未來則可考慮實際將代理伺服器部署於移動通訊網路中，佐以良好的演算法， 則能有效減少增加硬體的成本。 關鍵字: 代理伺服器、效能函數、行動網路、線上排程演算法

ii

Utility-Based Traffic Scheduling For Mobile Applications

Student：Cheng-Hsiao Keh

Advisor：Dr. John Kar-kin Zao

Dr. Chih-Wei Yi

Institute of Computer Science and Engineering

National Chiao Tung University

ABSTRACT

In recent years, a variety of services have been available to mobile subscribers. Because the number of subscribers grows too fast, the current infrastructure cannot give services to fulfill everyone’s need, which causes reduced data rates and poor service performances.

To solve this problem, we propose Application Proxies into current network design. Mobile Proxy is set at the cell phone end, which has a local cache and manages all sessions so that traffic scheduling can be achieved. Cloud Proxy on the other hand is sited at the external data network namely Internet, which does periodicity crawling to third party application servers. When the content of an application has updated, an short message would be sent to the Mobile Proxy.

With the support of Application Proxies, we may attain the following objectives: (1) eliminate redundant data transmission. (2) reduce network congestion and overloaded cases. (3) maximize data values for individual subscribers. First objective can be realized by content caching at Mobile Proxy, while second and third objectives will be achieved by sophisticated traffic scheduling mechanism. Thus an utility-based scheduling algorithm, which takes service quality and user preferences into consideration is proposed.

The simulation environment is based on mobile network architecture and corresponding traffic models. The result shows that with suitable caching and traffic scheduling method, our goals can be truly achieved.

iii

誌 謝

本篇論文中的研究進行了一段不算短的時日，能夠獲得今日的成果，絕非我一個人 獨力辦到，而是有賴於多位人士的幫助。首先我要感謝的是我的指導教授邵家健老師， 從進入研究所以來，他總是能給予我懇切的建議，並協助我一步步的向前邁進。其次要 謝謝同組的同學，陳淑華及高偉翔。在研究的過程中時常會遇到難題與挫折，除了與他 們彼此討論方法，使得研究內容更加精進之外，同伴間的互相勉勵也讓我的心理更加踏 實。最後則要謝謝趙禧綠教授、遠傳電信的黃天立先生及韋殿釗先生，他們給的專業諮 詢，指引我朝著正確的研究方向前進。有了這些人士的慷慨協助，才造就了今日本論文 的完成。能在這段日子中與他們共事，讓我感到無比的幸運，更是一段珍貴的經驗。

柯承孝

2011 9 月

iv

目 錄

以行動應用程式為對象的效能導向流量排程演算法 ... i

Utility-Based Traffic Scheduling For Mobile Applications ... ii

誌 謝 ... iii 目 錄 ... iv 表 目 錄 ... vi 圖 目 錄 ... vii 符 號 說 明 ... viii 一、 緒 論 ... 1 1.1 研究背景與動機 ... 1 1.2 研究問題 ... 1 1.3 研究目標 ... 2

1.3.1. 降低無線存取網路(Radio Access Network)中不必要的資料流量 ... 2

1.3.2. 減少網路負荷過載及壅塞的情形 ... 2 1.3.3. 替個別用戶最大化其獲得的資料價值 ... 2 1.4 論文結構與研究流程 ... 2 二、 相 關 文 獻 探 討 ... 4 2.1 效能函數(Utility Function)描述及應用 ... 4 2.2 行動網路中的服務品質(QoS)控管策略 ... 4 三、 研 究 方 法 ... 6 3.1 系統模型(System Model) ... 6 3.1.1. 行動網路架構 ... 6

3.1.2. 雲端至用戶端訊息傳輸框架(Cloud to Device Messaging, C2DM) ... 6

3.1.3. 代理伺服器(Application Proxy) ... 6 3.1.4. 系統架構及運作流程 ... 7 3.1.5. 服務品質參數(QoS Parameters) ... 8 3.1.6. 流量分類(Traffic Classifications) ... 9 3.1.7. 用戶檔案(Subscriber Profile) ... 11 3.1.8. 工作規格(Job`s Specifications) ... 12

3.2 效能導向的排程演算法(Utility-Based Scheduling Algorithm) ... 13

3.2.1. 概觀(Overview) ... 13 3.2.2. 假設(Assumptions) ... 15 3.2.3. 效能函數(Utility Functions) ... 15 3.2.4. 快取機制(Caching Mechanisms) ... 20 3.2.5. 應用程式內容預先下載(Application Pre-fetching) ... 20 3.2.6. 排程策略(Scheduling Strategies) ... 21 四、 資 料 分 析 與 結 果 ... 29

v

4.1 模擬設計(Simulation Model) ... 29

4.1.1. 網路狀況模型(Network Status Model) ... 29

4.1.2. 流量模型(Traffic Model) ... 29 4.1.3. 應用程式規範(Application Specifications) ... 30 4.2 結果分析 ... 31 4.2.1. 整體網路效能評估 ... 31 4.2.2. 應用程式效能評估 ... 32 五、 結 論 ... 35 參 考 資 料 ... 36

vi

表 目 錄

表 1 – LTE服務品質分類表 ... 9 表 2 – 網路品質狀態及其對應的參數值 ... 29 表 3 – 應用程式規格 ... 31

vii

圖 目 錄

圖 1 – 北美洲行動網路的一日平均流量 ... 1 圖 2 – LTE網路架構&代理伺服器 ... 7 圖 3 – 系統運作流程 ... 8 圖 4 – 以服務品質為參數的效能函數圖形(一般性流量) ... 10 圖 5 – 以服務品質為參數的效能函數圖形(時間重要性流量) ... 10 圖 6 – 以服務品質為參數的效能函數圖形(品質調整性流量) ... 11 圖 7 – 工作執行範例 ... 12 圖 8 – 流量控制(a)於RNC上 (b)於手機上 ... 14 圖 9 – 無線資源分配於不同時間尺度下的控制策略 ... 14 圖 10 – 一般性流量的效能函數: (a) 傳輸速率 (b) 延遲時間 (c) 封包錯誤率 .... 17 圖 11 – 時間重要性流量的效能函數: (a) 傳輸速率 (b) 延遲時間 (c) 封包錯誤率 ... 17 圖 12 – 品質調整性流量的效能函數: (a) 傳輸速率 (b) 延遲時間 (c) 封包錯誤率 ... 18 圖 13 – 工作狀態變化示意圖 ... 23 圖 14 – 基於效能及傳輸親合性決定工作執行的順序 ... 24 圖 15 – 以(𝑟1, 𝑟2, … , 𝑟𝑁)為參數的效能概念圖 ... 26 圖 16 – 排程演算法流程圖 ... 28 圖 17 – 網路品質狀態轉移圖 ... 30 圖 18 – 基地台下行流量統計數據 ... 31 圖 19 – 基地台下行流量比較 ... 31 圖 20 – 不同用戶數量下的基地台下行平均傳輸速率 ... 32 圖 21 – 無代理伺服器的手機流量 ... 32 圖 22 – 應用程式平均流量 ... 33 圖 23 – 有代理伺服器的手機流量 ... 33 圖 24 – 應用程式平均回應時間 ... 34 圖 25 – 不同用戶數量下的平均回應時間 ... 34

viii

符 號 說 明

𝑟 資料傳輸速率 𝑟∗ _{決策者最偏好的傳輸速率} 𝑟𝑜 _{決策者最不偏好的傳輸速率} 𝑟𝑖 第𝑖個工作的傳輸速率 𝑟𝑟𝑒𝑞 最小傳輸速率需求 𝑟𝑖,𝑟𝑒𝑞 第𝑖個工作的最小傳輸速率需求 𝑑 延遲時間 𝑑𝑖 第𝑖個工作的延遲時間 𝑑∗ _{決策者最偏好的延遲時間} 𝑑𝑜 _{決策者最不偏好的延遲時間} 𝑑𝑟𝑒𝑞 最大延遲時間需求 𝑑𝑖,𝑟𝑒𝑞 第𝑖個工作的最大延遲時間需求 𝜀 封包錯誤率 𝜀∗ _{決策者最偏好的封包錯誤率} 𝜀𝑜 _{決策者最不偏好的封包錯誤率} 𝜀𝑟𝑒𝑞 最大封包錯誤率需求 𝜀𝑖,𝑟𝑒𝑞 第𝑖個工作的最大封包錯誤率需求 𝑈 總體效能函數 𝑈𝑏𝑜𝑢𝑛𝑑 效能邊界值 𝑈𝑖 第𝑖個工作的總體效能函數 𝑈𝑇 以傳輸速率為參數的效能函數 𝑈𝐷 以延遲為參數的效能函數 𝑈𝑅 以封包錯誤率為參數的效能函數 𝑝𝑖 使用者對第𝑖個工作的偏好值 𝑀 總資料量 𝑀𝑖 第𝑖個工作的總資料量 𝑀� 剩餘資料量 𝑀�𝑖 第𝑖個工作的剩餘資料量 𝑗𝑜𝑏𝑖 第𝑖個工作 𝑁𝑎𝑝𝑝 用戶所存取應用程式的數量 𝑊 權重函數 𝐶 工作建立時間 𝐶𝑖 第𝑖個工作的建立時間 𝑇𝑐 現在時間 𝑃𝑎𝑐𝑐𝑒𝑠𝑠 用戶存取應用程式的間隔時間機率分布 𝑃𝑢𝑝𝑑𝑎𝑡𝑒 應用程式更新的間隔時間機率分布 𝑃ℎ𝑖𝑡 預先下載的應用程式被用戶存取的機率 𝑀𝑝𝑟𝑒𝑓𝑒𝑡𝑐ℎ 預先下載的期望資料量 𝜏𝑝 網路參數更新週期 𝑟𝑚𝑎𝑥 單一用戶最大可用頻寬 𝐵𝑚𝑎𝑥 無線網路總頻寬

ix

𝜑data 網路額外負擔時間量

𝑈𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑 工作狀態變化的效能門檻值

𝛺𝑢𝑡𝑖𝑙𝑖𝑡𝑦 效能下限比率

1

一、 緒 論

1.1

研究背景與動機

自從手機被發明以來，有很長的一段時間被當成單純的通話裝置使用。不過隨著科 技的演進，通訊系統的架構已經能整合聲音及資料網路[23]，許多不同種類的應用程式 服務也開始被提供到手機上，而能存取這些應用程式服務的手機就被稱為智慧型手機。 行動網路與一般廣泛使用的網際網路有若干不同之處，其一是行動網路的末梢需要經由 無線通訊的方式和客戶端溝通。其二則是用戶在存取網路時擁有移動的性質，因此網路 要確保與用戶之間連線的持續性。其三是由於傳輸介質的因素，無線頻寬的擴增較有線 頻寬受到更大的侷限。在這種限制下，業界及學界都不斷地思索改善的方式，行動網路 的標準更不斷的演進，現在已經發展到第四世代，也就是 LTE 及 WiMAX 標準。隨著系統 架構的改變，新的網路協定和方法也以解決不同的問題為目的不斷被提出。

1.2

研究問題

由於行動網路技術的成熟，手機上能提供的服務種類也大幅成長，這造成了資料流 量所佔的比例遠大於傳統的通話流量。而用戶數量的大幅成長，使得網路頻寬不足的問 題也漸漸浮上檯面[21,22]。造成此一問題的主要原因是行動網路的移動性，讓使用者 可以在任何地點，任何時間存取網路服務。在大部分的情況下，頻寬都可以滿足使用者 的需求，但是若是人群大量湧入特定地方，例如市區、百貨公司，而且又同時使用網路， 那麼就會造成網路壅塞的情況。這種人群密度較高的場所被稱做熱點(hot spot)。在(圖 1)中可以看到使用者的行為都遵循著類似的模式，大量使用頻寬的行為其實只發生在特 定的時段中，這造成了流量在時間層面的極度不均衡。若是要增加更多基地台，或是增 加線路在這些地方，事實上是非常不經濟的做法，因為在大部分的時間裡，這些額外的 頻寬都是處於閒置的狀態。因此眾多研究者們針對如何改善行動網路壅塞的問題，提出 了種種可能的架構及方法[5,24,25,26]。 圖 1 – 北美洲行動網路的一日平均流量

2 有些研究者試著從數學的角度去處理此問題，將其化為適合的最佳化問題型式後解 決。另外一種可能的方法則是以適當的演算法，將流量分散至不同路由中，例如基於最 大化傳輸速率(max-min)分配，或是按照比例性原則分配，以及基於最小化延遲來分配 等方式。但是在實際的網路中，流量變化是無法完全模擬的，因此只有運用良好的流量 分散策略還不夠，當流量超出預期時還需要有壅塞防止(congestion avoidance)措施的 支援。常見的幾種機制例如將超過負荷的封包踢除，暫停服務新的連線要求，或是隨機 早期偵測(Random Early Detection)都是現今的網路所採行的方式。

綜觀過去的研究，都是在網路的樞紐或是路由器上處理壅塞的情況，不過隨著使用 者數量逐漸成長，所能達到的效果事實上是很有限的。在本篇論文中，引進了代理伺服 器此元件並安裝於手機上，如此一來代理伺服器則可在手機端對流量進行控制，從根本 上減少網路的流量。

1.3

研究目標

本篇論文中為了解決上述的問題，提出以下三個目標:

1.3.1. 降低無線存取網路(Radio Access Network)中不必要的資料流量

訊號在無線網路中經由空氣介質傳輸，會有明顯的衰減現象，而且頻寬的擴充也受 到了大幅限制。因此如何善用頻寬，避免多餘的資料傳輸變成一個很重要的課題。針對 此一問題，可運用快取的機制來解決。在手機上設置一個代理伺服器，擁有快取儲存區 可保存各個應用程式的資料，則可避免多次傳輸同樣資訊的情形發生。 1.3.2. 減少網路負荷過載及壅塞的情形 從行動網路的調查報告中，可發現到在不同的時間，網路流量的差異性是很巨大的。 其原因在於群眾行為有著類似的模式，傾向於在同一時間同一地點使用網路資源，因此 造成了傳輸速率緩慢的情形。但是在大部分的時間內，網路頻寬的使用率卻相對的低。 在手機上的代理伺服器，可在網路流量較低時預先下載應用程式的資料，並且根據網路 狀況動態調整下載中使用的頻寬，則可減少網路壅塞的情況。 1.3.3. 替個別用戶最大化其獲得的資料價值 每個應用程式都有其傳輸上的需求，也就是服務品質(Quality of Service,QoS)， 對用戶而言，每個應用程式也有著不同的重要性。在本論文中，我們提倡一個運用效能 函數估算資料價值的方法。效能函數是一種量化資料價值的手段，運算中會把服務品質 及用戶的偏好納入考量計算。手機上的代理伺服器則可根據效能函數的輸出值，找出適 當的資料傳輸方式及順序，以最大化所獲得的資料價值。如此則可確保各種資料類型的 服務品質以及客戶的個人偏好都能獲得滿足。

1.4

論文結構與研究流程

本篇論文的剩餘部份將依序說明以下的內容。在第二章中，我們會先介紹與本研究 方法相關的文獻及其差異性。在第三章中將詳細說明研究的系統架構及方法。第四章則

3

是針對所提出的方法以模擬方式做驗證，並分析其結果。最後在第五章中進行全篇研究 的總結，並且評估未來可能的發展方向。

4

二、 相 關 文 獻 探 討

2.1

效能函數(Utility Function)描述及應用

效能函數原本是經濟學上的一個概念[33]，它指的是某個決策能提供給使用者的滿 意程度，當使用者越偏好特定結果，則其效能也越高。那時還沒有人將此說法用於資訊 工程的領域中。直到 1995 年 Shenker 提出了較完整的說法[1]，他將效能表示成頻寬的 函數，並且針對不同流量類型用不同形狀的效能函數來描述流量的特徵，不過在該篇文 獻中並沒有提到如何量化和計算效能函數值的部分。Zimmermann 和 Killat 在[4]中假設 效能函數可以對數函數的形式來呈現，並定義了效能最佳化的問題。Dharwadkar[3]則 將效能函數分成梯級(step)、線性(linear)、凹形(concave)三種形式，並提出了一個 線上排程的原則方法，可以達到效能最大化的目的。Kelly[5]等人參閱了前人的研究結 果，將效能函數假設有遞增(increasing)、凹形(concave)、可微分(continuously differentiable)的性質，並證明了對流量分配給各個用戶的最佳化問題，是數學上可 解決的。 之後，效能最佳化問題廣泛應用於各種環境，被研究者提出以及驗證。例如 Harks 等人[6]在基於效能公平的假設下，推導出一個適合的方式以評估各個用戶所獲得效能 的公平性，並且提出了對應的優先權付費(priority pricing)機制。Chang 等人[7]針對 了 HTTP 流量類型建立了模型及效能函數，並解決了在這種假設下的頻寬分配最佳化問 題。Chen 等人[8]則考慮於無線感測網路(wireless sensor network)中，把元件的電力 消耗作為額外的成本，建立了一個效能-電力的模型，並在數學上解決了此最佳化問題。

2.2

行動網路中的服務品質(QoS)控管策略

在網際網路剛開始發展的年代，封包的傳輸並沒有考慮所謂服務品質的概念，而一 概採用最大效能(best-effort)的傳送方式。這種方法使得頻寬資源的使用效率不彰， 用戶也無法獲得良好的應用程式體驗。在這種情形之下，基於服務品質的網路架構與方 法開始慢慢被提出。能提供服務品質的網路，代表可針對應用程式的需求運用不同的傳 輸策略。可能的需求包括頻寬、延遲、排程優先權等等，隨著行動網路的崛起，在行動 網路環境下的服務品質調節，也變成了一個重要的研究主題。 Singh[9]在 1996 年時提出了行動網路應該提供兩個額外的服務品質參數:在切換區 域時保證無間斷的通訊以及服務的規格降低(degradation)，同時他也提出了能支援服 務品質的網路架構及傳輸協定。Campbell 等人[12]也提出了一個可程式化的行動網路架 構，能動態的適應網路情況並對應用程式進行傳輸的調節。Mahadevan 和 Sivalingam[11] 則針對路由(routing)層面的服務品質調控，提出了對應的行動網路架構及機制。 除了能支援服務品質的網路結構，另外一群人則針對頻寬的分配方式進行研究。在 [10]中，Kroner 在考慮服務品質的條件下，對 UMTS 網路中無線資源的分配提出了三種 可能的方法:基於傳輸速率分配、基於傳輸功率(transmission power)分配，以及基於

5 最大化傳輸速率(max/min)分配，並在模擬系統中進行了效能和優劣的分析和比較。在 [13]中採用了模糊邏輯(fuzzy logic)的概念，將傳輸資料根據服務品質分成四個類別: 交談式(conversational)、影像(streaming)、傳統、背景執行。接著將觀測及計算而 得的網路參數做為模糊邏輯運算的輸入，根據設定好的規則列表以決定適當的頻寬分配 方式。Yang 等人[14]根據應用程式對頻寬的需求定義了相對的效能值，每當有新的連線 進來時，則決定一個新的頻寬分配方式，以最大化所獲取的效能值。另一種可能頻寬分 配方法是建立一個決策樹(decision tree)[15]，將服務品質可能的參數以階層式連接， 越上層的表示其資訊越為重要並且先抉擇，接著根據適當的分析後找出最適合的路徑。 頻寬分配和流量排程的方法都有一個共通的要求，就是需實現某種條件下的公平。 由於兩者能處理的方向不同，演算法的目標也有些差異性。對資源分配來說，如何有效 率的使用有限的資源是最重要的課題。相較之下，一般在流量排程演算法重視的是如何 降低最大延遲以及優先傳送較重要的資料。例如在無線公平排程方法(Wireless Fair Queuing, WFQ)[16]中，演算法會選擇錯誤率最低的頻道先服務，被服務過的頻道會降 低其優先權，如此就可以避免服務分配不公平的情形發生。Wang 等人在[17]中改良此方 法，將流量分成即時(real-time)和非即時(non real-time)兩種，並採用不同的策略處 理，接著證明了在流量分類的情形下，仍然能夠保證有限的延遲(bounded delay)和公 平性。以上的流量排程演算法，雖然考慮了頻道的狀況，但是並未替不同應用程式設定 不同的服務品質。當資料類型越來越多時，若是仍然採用統一的原則進行排程，則會發 生應用程式效能低落的問題，因此如何滿足服務品質的需求也成了研究者關注的主題之 一。Shi 等人[18]提出了一個排程演算法，主要概念是透過動態的將手機切換至睡眠模 式，在滿足最低頻寬需求的條件下，同時達到省電的目的。Mendez 等人[19]考慮在以分 碼多重存取(Code Division Multiple Access, CDMA)作為資源分配方式的架構中，針 對多媒體類型的資料來進行排程。排程的基本原則是根據服務品質和資料量決定其權重， 並給予不同程度的頻寬。Choi 等人[20]提出了一個上層的排程演算法，在一個連線進來 時，先以整體資料的角度去計算其效能值，以決定工作執行的順序，接著將此工作交由 下層的封包排程處理。由於效能跟服務品質需求相關，因此可保證執行的工作能獲得最 高的效能。 本論文中所提倡的方法與過去研究最大的不同之處在於排程演算法是在網路中的 客戶端運作，而非傳統在路由器或是閘道器上進行。在伺服器上能做的策略是針對已經 產生的資料流量而定，因此對網路的傳輸改善十分有限。但是在手機端可以在應用程式 的層面直接決定各個連線的控管策略，如此則有可能大幅提升網路的效能。

6

三、 研 究 方 法

3.1 系統模型(System Model)

3.1.1. 行動網路架構 隨著手機用戶數量急遽增加，研究者和業者都不斷尋找著改良目前網路結構的方法， 行動網路的標準和演算法也日新月異。發展到今日為止，被正式公認的新一代標準是 3GPP 長期演進技術(3GPP Long Term Evolution, LTE)，也就是俗稱的第四代無線通訊 技術[23]。本論文中所提出的額外網路元件及方法，都假設下層硬體設施為 LTE 標準和 其網路架構。在 LTE 網路中包括了以下幾個元件:

 先進基地台(Evolved NodeB, eNB) – 這個元件在 LTE 無線存取網路中扮演了基地 台的角色，它除了負責與手機之間的無線傳輸，並且也進行訊號資源的管理和手機 區域切換(handover)。

 行動性管理模組(Mobility Management Entity, MME) – 它負責持續追蹤手機的 所在位置，並驗證其合法性，接著將其註冊到正確的閘道器上。

 服務閘道器(Serving Gateway, SGW) – 此閘道器負責決定封包的路由並進行轉送。 用戶的個人資訊也在此進行註冊，例如現在所在位置、可使用的服務、以及路由資 訊等等。

 資料網路閘道器(PDN Gateway, PGW) – 此閘道器提供了手機與公開資料網路 (Public Data Network, PDN)之間連線的橋樑，並針對各個用戶執行不同的策略， 例如封包過濾，網路服務費用計算等功能。

3.1.2. 雲端至用戶端訊息傳輸框架(Cloud to Device Messaging, C2DM)

行動通訊系統結合雲端運算，在智慧型手機興起後，被認為是未來十分有潛力的應 用方式。為了輔助這個新概念， Google 提供了 C2DM 的服務，它提供了簡單的方式讓應 用程式伺服器通知手機端，有新資料可供下載。手機端收到通知後，可選擇不做任何回 應，也可以跟伺服器要求連線取得資料。從開發者的角度來說，可以將大部分的運算在 伺服器端就完成，而利用 C2DM 告知應用程式來取得結果，因而降低手機的處理負擔。 本論文中使用 C2DM 技術作為手機端和資料網路間的溝通橋樑，實際應用方式將於下一 節說明。 3.1.3. 代理伺服器(Application Proxy) 為了實現本論文中提出的方法，需要將代理伺服器此元件加入現有的網路架構中。 根據代理伺服器其負責的功能不同，可分為行動端代理伺服器(MS Proxy)及雲端代理伺 服器(Cloud Proxy)兩種，部署於網路中不同的位置:  雲端代理伺服器 - 這個元件部署於公開資料網路也就是網際網路中，並作為第三

7 方應用程式伺服器的逆向代理(reverse proxy)來運作。所有從手機端使用的應用 服務都會經過此代理伺服器，如果快取中沒有該應用程式最新的資料，才將此資料 要求轉送至對應的應用程式伺服器。除此之外，它還會定期去查看應用程式是否有 更新，以分析各個應用程式的更新模式，這樣即可確定快取是否過期。每當應用程 式伺服器有新資訊產生時，雲端代理伺服器會利用 C2DM 服務傳送一個短訊通知手 機。各個應用程式的更新通知和更新週期，皆會傳送到行動端代理伺服器上，成為 排程策略的參考資訊。  行動端代理伺服器 - 這個元件設置於手機上，手機與外界進行連線都需經由此代 理伺服器。他擁有獨立的快取空間，負責儲存應用程式最新的內容副本。它不只會 監控網路流量的狀態，更可進一步對各個連線進行程式化的操作，例如改變連線開 始的時間、暫停一個連線、或是傳輸速率的調整等等。另一方面，行動端與雲端的 代理伺服器可經由 C2DM 服務進行點對點的加密傳輸，以取得在雲端所獲得的資訊。 藉由以上敘述的功能，行動端代理伺服器則能根據演算法，實現適當的工作排程。 代理伺服器詳細的硬體規格以及功能實做方法，並非本論文的重點，因此不再贅述。 接下來章節中所提出的演算法，皆假定代理伺服器已部署於網路中，且能提供所需的功 能支援和網絡資訊。 3.1.4. 系統架構及運作流程 將 3.1.3 所提出的代理伺服器加入現在的網路後，所呈現的架構就如同(圖 2)所示。 行動端代理伺服器位於行動裝置上，作為手機的系統程式控管所有對外的連線。雲端代 理伺服器則位於網際網路上，負責從各個應用程式伺服器下載資料。須注意在圖中並未 表現出 LTE 網路中所有的元件，而只表示資料會經過的部分。黑色實線表示應用資料傳 輸的路徑，紅色虛線則是雲端代理伺服器和手機端代理伺服器傳送訊息的路徑。使用 C2DM 服務做為資訊的傳輸方式有著若干優點，其一是 C2DM 是專門設計給第三應用程式 伺服器傳送一些短訊給手機端的服務，不論是架構或是方法上都較為完善，讓開發者不 需自行設計額外的溝通方式。其二則是短訊的傳輸是由 C2DM 伺服器負責控制，除了過 圖 2 – LTE 網路架構&代理伺服器

8 濾重複的短訊之外，它也會知道行動裝置是否在線，當行動裝置運作時才將短訊送至目 標裝置，因此可以減少大量的網路額外負擔。 (圖 3)將代理伺服器中的各個模組以及其功能以方塊圖的方式描繪了出來，圖中紅 色的方塊代表手機用戶，黑色的方塊代表手機端代理伺服器，綠色的方塊代表雲端代理 伺服器，而藍色的方塊則代表第三方應用程式伺服器。當用戶要求某個應用程式的資料 時，手機端代理伺服器會先搜尋快取中有沒有最新的內容，如果沒有找到則將此要求轉 換成演算法可處理的工作(job)格式，作為排程策略的輸入。除了使用者的要求之外， 代理伺服器還會分析使用者的行為，預先下載(pre-fetch)高機率被使用的應用程式。 除了進行排程的目標工作之外，應用程式規範(application specification)及用戶檔 案(subscriber`s profile)也是排程演算法必要的輸入。應用程式規範指的是服務商對 應用程式定義的服務品質(Quality of Service, QoS)需求，而用戶檔案則包括了使用 者對應用程式的個人偏好及用戶歷史行為。有了適當的輸入資訊後，演算法就能據此找 出一個可能的工作排程方式。決定好的排程將交由代理伺服器的連線控制模組(session control module)執行，開始進行應用程式資料的下載。 雲端代理伺服器接收到從手機端來的連線，會先搜尋快取，如果快取中沒有對應內 容才向應用程式伺服器下載。除了轉送手機端來的連線要求，雲端代理伺服器還會定期 自動查看應用程式伺服器的情況，以分析應用程式的更新週期。雲端代理伺服器會將更 新週期的資訊利用 C2DM 的機制送給手機端的代理伺服器，與用戶行為模式一同作為決 定是否預先下載的參考。 3.1.5. 服務品質參數(QoS Parameters) MS Proxy main console Mobile user Applicatio n cache Usage probability analyzer Job constructor Job scheduler App. specificatio n Subscriber profile Session control module Applicatio n cache Cloud Proxy main console App. update pattern analyzer Third party servers Access cached content Request data Collect user behavior Forward user request Send update pattern Pre-fetch app. content

Put job into waiting list Job schedule Access cached content Fetch data Collect update behavior 圖 3 – 系統運作流程

9

在 LTE 行動網路中所定義的服務品質類型，基本上是 UMTS 標準中的延伸和擴充， 在(表 1)中可以看到有九種可能的服務類型，以傳輸速率(bit rate)、封包延遲(packet delay)，及封包錯誤或遺失率(packet error or loss)這三種傳輸參數來描述服務品質 層級。為了增加演算法與網路架構之間的親和度並提升效能，本篇論文中也將採用同樣 概念的參數，茲說明如下:

 傳輸速率(transfer rate) –指的是每單位時間中所收到的資料量，是最普遍的效 能評估指標。

 延遲時間(total delay) –與 LTE 標準的定義方式不同，這邊指的是整份資料下載 完成加上等待所花的時間，而非傳送單一封包的延遲。

 封包錯誤率(packet error rate) – 在無線環境中用以評估頻道品質的中一個指 標，我們將封包遺失率也算進封包錯誤率中。 這三種服務品質的需求會定義在應用程式的規範中，並且當作演算法的其中一項輸 入。為了簡單起見，我們假設所有應用程式對傳輸質量的要求皆只包含以上三種參數。 在下一小節中將會描述不同應用程式的特性，並根據服務品質參數和效能的關係進行分 類。 3.1.6. 流量分類(Traffic Classifications) 隨著智慧型手機的興起，應用程式種類也越來越多。為了提供使用者良好的服務品 質，每個應用程式對傳輸參數皆有不同程度的要求，例如封包遺失率、頻寬、延遲時間 等等。基於過去的研究[1,3,4,5]，我們描繪出這些參數跟用戶體驗之間可能的關係後 進行分類，並採用用戶效能作為量化和測量用戶滿意度的方式。根據效能函數形狀，可 將流量類型區分為以下三種:一般性(Ordinary Traffic)、時間重要性(Time-Critical 表 1 – LTE 服務品質分類表

10 Traffic)、品質調整性(Quality-Scalable Traffic)。  一般性 – 這類應用程式對服務品質的要求不高，甚至沒有明確的需求，而且對延 遲的容忍度也較高。這意味著當傳輸速率較低時，增加頻寬所能獲得的邊際效益 (marginal benefits)是很高的。但是當傳輸速率越來越高時，增加頻寬所能提升 的用戶滿意度卻越來越不明顯。有著此種特徵的應用程式像是網頁瀏覽、檔案下載， 和收發郵件等等。從(圖 4)中可以觀察到此類應用程式的特性，一開始增加傳輸速 率時，效能有著明顯的增長，但是隨著速率越來越高，額外效益也隨之變差。而傳 輸時間越長，用戶體驗也就是效能會呈現不斷下降的趨勢，不過由於此類資訊沒有 明確的時間限制，因此不會導致效能變成零的情況。封包錯誤率與效能之間的關係 也是成反比的，與傳輸時間不同之處在於，一般應用程式有其能接受的封包錯誤率 上限，當超過此限制時收到的資料就不再擁有可辨識的資訊。  時間重要性 – 有些應用程式的資料更新十分迅速，而且講求時效性，若是超過限 制的時間才取得，對使用者來說就失去了其原有的價值，因此對服務品質的要求也 較為嚴苛。我們將股票內容跟新聞定義於此類別中。(圖 5)顯示了可能的效能圖形， 與一般性流量的差別只在於傳輸潛伏時間與效能之間的關係，當時間超過應用程式 設定的上限，收到的資料就沒有任何效能可言。  品質調整性 – 對影片跟圖像來說，不一定需要完整收到全部封包才能辨識裡頭的 效能 延遲時間 效能 傳輸速率 效能 封包錯誤率 圖 4 – 以服務品質為參數的效能函數圖形(一般性流量) 圖 5 – 以服務品質為參數的效能函數圖形(時間重要性流量) 效能 傳輸速率 效能 封包錯誤率 效能 延遲時間

11

內容，因此可以對每個服務品質參數定義多個可能的需求等級，並根據現在的網路 資源調選擇可接受的品質層級。Google Earth 的地面圖像和 YouTube 的影片皆屬於 此類型。可能的效能函數圖形如(圖 6)，可以看到在傳輸速率的層面，函數形狀就 像階梯一般有較明顯的間隔。舉例來說，在 YouTube 播放影片時，有多種解析度可 選擇，當用戶頻寬能滿足某個需求時，就能獲得相應的效能。但是頻寬介於高解析 度和低解析度需求之間時，仍然只能播放低解析度的影片，當頻寬符合高解析度的 需求，用戶才能獲得較高的效能。因此品質調整性的流量就如同將多個一般性流量 組成群集，它們對於傳輸速率有不同的品質要求，但可接受同等的傳輸潛伏時間及 封包錯誤率，因為它們都屬於同一種應用程式的內容。 3.1.7. 用戶檔案(Subscriber Profile) 我們的研究目標包含了替使用者取得最大化的資料價值，在效能函數及排程演算法 中都需要考慮特定的個人資訊。這些資料有些是由用戶設定，有的則是由代理伺服器主 動收集，儲存在用戶檔案中，裡頭包含了以下內容:  應用程式偏好 –用戶需要決定各個應用資料的重要性，也就是此工作在傳輸時的 優先權。此資訊以編號方式進行設定，數字 1 表示優先權最高，不同應用程式也可 以設定為同一優先權。進行流量排程時會將用戶偏好作為演算法的輸入之一，若是 一個工作的優先順序較高，那麼執行它會帶來額外的用戶效能補正。  應用程式預先下載 –當用戶認為某種資訊對他十分重要，希望即時取得最新的內 容，那他可以在用戶檔案中設定預先下載，則代理伺服器會在空閒的時候自動更新 該應用程式的內容。這種做法對用戶來說有若干個好處，其一是使反應時間最小化， 其二是避免錯過可能的新資訊。不過需要注意，若選擇要預先下載的資料太多，超 過頻寬資源可負荷的程度，可能使得此機制無法完全發揮其作用。 圖 6 – 以服務品質為參數的效能函數圖形(品質調整性流量) 效能 延遲時間 效能 封包錯誤率 效能 傳輸速率

12  用戶歷史行為 – 手機端的代理伺服器會記錄用戶存取應用程式的次數、時間，以 及使用的頻寬。根據這些資訊，可以幫助演算法在未來的排程中調整工作的傳輸速 率及時間，將資料流量分散到不同時間處理以減少網路負荷和壅塞的情況發生。同 時可用來分析應用程式存取週期，與更新週期一同作為考慮是否預先下載的因素。 3.1.8. 工作規格(Job`s Specifications) 每當用戶使用應用程式，或是代理伺服器決定自動下載資料時，就有一個對應於此 要求(request)的工作(job)產生。排程演算法的目標，就是決定適合的方式完成這些工 作，以求最大化使用者效能。一個工作的規格可以用以下資訊進行表示。  應用程式規格(Application Specifications) – 應用程式規格中包含了服務品質 參數和流量類型，在 3.1.5 和 3.1.6 小節已經對這兩個名詞進行了完整的定義，每 個應用程式都會有其固定的服務品質需求和所屬的流量類型。根據以上規格我們能 建立對應的效能模型，用以計算完成此工作可獲得的效能值。  優先權(Priority) – 這個參數指的是用戶認為此資料對他而言的重要性，在用戶 檔案中進行設定。這個數值並非永遠保持不變，演算法可決定於排程中動態調整優 先權。  資料量 – 說明這個工作總共大小是多少位元組，與傳輸速率配合就可以估計傳輸 時間，以作為效能函數可能的輸入之一。  建立時間 – 使用者要求應用程式資料或是代理伺服器自動下載發生的時間點，也 工作(一) 工作(二) 工作(三) 傳輸速率 時間 可用頻寬變化 圖 7 – 工作執行範例

13

就是工作的最早可能執行時間(earliest starting time)。

 延遲時間(delay) – 這裡指的是系統現在時間減去工作建立時間。為了保證各個 工作都能獲得服務的機會，當延遲時間越來越接近工作的完成期限時，執行它所能 獲得的額外效能補正也隨之成長。

在我們定義的系統模型中所有工作皆先由排程演算法決定適合的傳輸時間和傳輸 策略，然後交給通訊端控制模組(session control module)負責執行。由於代理伺服器 能控管所有對外連線，因此可以直接對通訊端進行程式化的操作。例如決定下載開始時 間、暫停/恢復傳輸、調節傳輸速率。注意在排程中將時間及頻寬資源皆視為離散，即 有最小單位存在。(圖 7)描繪了一個可能的情境，說明工作如何排程以及執行。一開始 有兩個待執行的工作，工作(一)跟(二)。代理伺服器基於效能因素來分配給他們適當的 傳輸頻寬，隨著時間推移，可用頻寬以及訊號品質等網路參數也會改變，代理伺服器也 會根據網路狀況動態調整各個工作的速率。時間到了第三格時，有一個新的工作(三)開 始執行，代理伺服器判斷此工作比(二)重要，因此就暫停(二)的傳輸，將頻寬分配給(三)。 而當(三)完成時，就繼續(二)的傳輸。

3.2 效能導向的排程演算法(Utility-Based Scheduling Algorithm)

3.2.1. 概觀(Overview) 行動網路和傳統有線網路在特性上有若干不同之處，其一是資料需經由無線訊號傳 遞，因此無線環境中的頻寬跟有線網路比起來受到較大的限制。另一方面由於訊號在空 氣中傳輸，背景雜訊所佔的比例相對較高，造成通訊品質時常有大幅的波動。考慮以上 這些因素，行動網路上對不同流量類型進行頻寬資源分配(bandwidth resource allocation)以及流量排程(traffic scheduling)的研究著重於如何有效率的使用頻寬 資源，並在網路狀況不佳時滿足不同應用程式服務品質的需求。 在本論文中所提倡的方法也是針對行動網路的特性而設計的，但是跟過去研究關注 的層面則有所差異。傳統上進行頻寬分配和流量排程的元件是無線電網路控制器(Radio Network Controller, RNC)，因此相關的演算法也是運作於此位置。在我們提出的系統 中有代理伺服器的存在，可以在手機端決定適合的工作排程和傳輸速率，從流量源頭直 接進行可能的控制。從(圖 8)中可以觀察到兩種方式的差異，在一個對話(session)中， 無線電網路控制器扮演了中繼點的角色，它能對到達的各個流量根據某種公平的原則分 配頻寬並轉送封包至對應的目的地，但是不主動建立連線和結束連線。若是單位時間內 到達的封包數量太多，只能選擇將封包丟棄，是一種被動(passive)的運作模式。當手 機上有代理伺服器的存在，則可以直接對各個連線做控制，包括分配頻寬、暫停/恢復 連線、以及選擇下載時間。當網路狀況不佳時，可以動態調整頻寬，將資源用於執行最 重要的工作，屬於(proactive)的控制方式。 本研究跟傳統方法在不同的層次中處理資料流量，由於基地台並非對話中的端點， 因此無法觀測到應用層(Application Layer)的資訊，需以封包為對象進行資源分配與

14 排程的演算法。不過在手機上則可從宏觀的角度處理，如此一來排程方法的設計較為直 觀，且應用程式的服務品質調整也更明確。(圖 9)描述了在不同層次中資源分配的概念， 在硬體層中負責改變傳輸功率，此事件發生的時間間隔大約是一毫秒左右。而在傳輸層 則進行封包的排程，一般來說封包傳輸速率的變化週期大約以十毫秒為最小單位。在最 上層中進行的是通訊控制，例如建立與接受連線等操作。 基於上述的理由，我們將專注於連線層面的排程，而不考慮下層如何傳送單一封包。 因為隨時可能有新的要求發生，因此演算法需以線上即時的方式進行。另一方面，我們 令各個手機的排程演算法獨立運作，也就是不考慮基地台範圍內其他手機的排程情況。 不考慮其他手機流量的原因在於，若是採取合作的模式，不只會造成頻寬的額外通訊負 Power Control Packet Scheduling

Session Control Application Layer

Transport Layer Physical Layer 1ms 10ms 1s Fast Fading Packet Duration Burst Duration 圖 9 – 無線資源分配於不同時間尺度下的控制策略 Internet Drop packets Huge data amount Small data amount RNC MS Internet Session control Small data amount Small data amount RNC MS (a) (b) 圖 8 – 流量控制(a)於 RNC 上 (b)於手機上

15 擔，而且由於網路狀況改變迅速，需要時常改變現有排程，無法達到預想的效能。為了 實現 1.3 提出的目標，我們設計了通用的效能函數以及執行效能區域性最佳化(local optimization)的排程演算法。 3.2.2. 假設(Assumptions) 在 3.1 提出的系統模型中在網路架構中加入了手機端代理伺服器和雲端伺服器兩種 元件，我們可以此為基礎做一些合理的假設，令其可提供以下功能以及資訊。  手機端代理伺服器知道它使用的應用程式列表及其規範，意即代理伺服器知道應用 服務對三種服務品質參數的需求，且使用者存取的應用程式總數不會變更。  手機端代理伺服器可對基地台發出詢問(query)，取得頻道的頻寬和接收訊號強度， 同時它可以運用一些程式化函數觀測與計算獲得現在的最大傳輸速率、封包延遲、 封包錯誤率等網路狀況資訊。  手機端代理伺服器從應用層控管所有網路連線，包括各個對話的開始時間、傳輸速 率、暫停或繼續傳輸等功能，皆可經由程式化函數實現，但是它不接觸下層的封包 排程方式和傳輸功率調節函數。  手機端代理伺服器會記錄使用者存取應用程式的時間，並能透過統計分析得到存取 間隔時間的機率分布。  雲端代理伺服器會定期去應用程式伺服器抓取資料，記錄更新時間後分析可能的更 新間隔時間機率分布。每當它發現新的應用資料內容時，都會發送一個短通知給手 機端代理伺服器。 3.2.3. 效能函數(Utility Functions) 效能函數原本是經濟學中的一個概念，用於量測消費者對商業服務的滿意程度，後 來被擴展調整型態後應用於網路資料傳送中[1,2,5,7]，此時它定義的對象變成了用戶 對網路服務的滿意度。隨著它用於不同種類的系統模型中，效能函數的內容也需要進行 調整。過去量測有線網路效能時[8,27,28]，一般只考慮以頻寬作為函數的輸入，原因 在於有線的連線品質較為穩定，其他因素對效能的影響相對較小。但是在無線環境中， 可用頻寬相對較小，通訊品質的波動較大，因此應用程式的服務品質無法僅以傳輸速率 表示，而需考慮其他網路條件。在我們所提倡的排程演算法中，也是以效能函數最大化 為目的，因此如何合理設計效能函數的型式，令其能符合現實中使用者對服務品質的期 望，成為一個十分重要的課題。 在 3.1.6 小節中對流量類型進行了分類，並概略描述了對應的效能圖形。這邊開始 將基於過去的研究及合理的推導，建構出對應於不同參數的效能模型，接著根據相關的 定理將其合併。我們定義服務品質的三個參數是傳輸速率、傳輸潛伏時間、封包錯誤率， 基於這三個屬性的效能函數分別以𝑈_𝑇、_𝑈𝐷及𝑈_𝑅表示。

16 首先我們先定義何謂效能函數，令進行一個決定(decision)所產生的結果可能是 𝑥1, 𝑥2, … , 𝑥𝑁，這些xi可能是純量(scalar)或向量(vector)，且決策者對這些結果有明確 的偏好順序， 𝑥₁ ≺ 𝑥₂ ≺ ⋯ ≺ 𝑥_𝑁，𝑥₁ ≺ 𝑥₂表示對𝑥₂的偏好大於𝑥₁。這個偏好是相對而非 絕對的，當我們希望建立量化的單位時，需先定義其中兩個結果的基準值，再根據基準 值去設定其他結果的相對數值。在不失一般性的條件下，我們可建立以下的比例尺。 𝑢(𝑥∗_{) = 1 𝑎𝑛𝑑 𝑢(𝑥}𝑜_{) = 0} 𝑥𝑜_{表示決策者最不偏好的結果，而𝑥}∗_{表示決策者最偏好的結果，𝑢(𝑥)表示定義的偏好。} 此時對其他可能的結果𝑥來說，可寫成 𝑢(𝑥) = 𝜋 ∙ 𝑢(𝑥∗_{) + (1 − 𝜋)𝑢(𝑥}𝑜₎ 以上式子的意義是說，獲得x的結果等同於有𝜋的機率獲得𝑥∗加上1 − 𝜋的機率獲得𝑥𝑜， 在實際情形中， 𝑢(𝑥)可能很複雜，此時不針對個別𝑥做定義，而找出其擬似曲線(fitting curve)是較好的選擇。 根據過去的研究[1-3,6,28]，可以知道對一般性流量來說，增加傳輸速率的邊際效 能(marginal utility)會不斷遞減，意義是每單位的資源所能給予的效能將越來越低。 在數學上此函數會有以下的性質，單調遞增(monotonic increasing)，和嚴格凸形 (strictly concave)。擁有這些性質的函數圖形皆可作為適當的𝑈_𝑇，我們則採用指數圖 形來表示: 𝑈𝑇(𝑟) = 1 − 𝑒−𝑐(𝑟−𝑟𝑟𝑒𝑞)。 (1) 𝑟𝑟𝑒𝑞是應用程式的傳輸速率需求，𝑐是形狀參數。 對傳輸潛伏時間來說，效能的變化也受到邊際效應的作用[20,29]，起初延遲增加 時，用戶的感受十分明顯，但是過了很長一段時間還沒有收到資料時，那麼效能幾乎不 再變動。因此函數性質為單調遞減(monotonic decreasing)，及嚴格凹形(strictly convex)，因此可以用以下函數表達: 𝑈𝐷(𝑑) = 𝑒 𝑙𝑛 (𝑈𝑏𝑜𝑢𝑛𝑑) 𝑑𝑟𝑒𝑞 𝑑_{。 (2)} 𝑑𝑟𝑒𝑞是應用程式的延遲需求，𝑈𝑏𝑜𝑢𝑛𝑑表示在延遲是𝑑𝑟𝑒𝑞時的效能邊界值。 封包錯誤率與用戶效能間的關係又不太一樣，使用者並不會直接因為錯誤率的改變 影響其偏好，而是封包錯誤影響了傳輸速率跟傳輸時間，而間接造成滿意度的變化。在 這種情況下，封包錯誤率較低時對邊際效能的影響較小，但是當封包錯誤率接近應用程 式能忍受的上限時，效能即開始急遽下降。因此函數特性包括了單調遞減(monotonic decreasing)，及嚴格凸形(strictly concave)，可能的形式之一為: 𝑈𝑅(𝜀) = 2 − 𝑒 𝑙𝑛2 𝜀𝑟𝑒𝑞𝜀_{。 (3)}

17 𝜀𝑟𝑒𝑞是應用程式的封包錯誤率需求。 (圖 10)顯示了一般性流量對應不同參數方面的效能函數，可以觀察到此類型應用 程式對於傳輸速率和封包錯誤率有嚴格要求，網路條件無法滿足其需求時，就無法獲得 任何效能。但是它對延遲並沒有硬性規範，只說明延遲太高時效能會極端低落。 接下來我們考慮時間重要性的流量類型，過去的研究[20,29,30]說明了此類型流量 的特性。對於頻寬並沒有特殊要求，但是當延遲超過其規範的訴求，服務表現就會變的 很差。根據以上條件，我們可以選擇傳輸速率與封包錯誤率跟一般性流量相同的函數形 狀，而針對延遲層面的函數形狀，我們希望有以下數學性質，單調遞減(monotonic decreasing)，並與x 軸相交。基於這些特性，我們提出了線性的效能模型: 𝑈𝐷(𝑑) = 1 −_{𝑑𝑟𝑒𝑞}𝑑 。 (4) (圖 11)顯示了時間重要性流量可能的函數圖形，相較於一般性流量，差異只在延 遲造成的效能變化。隨著時間推遲越久，兩種流量的效能都會隨之降低，但是對一般應 用程式來說只會變的很低而不會變成零，它對延遲時間的需求事實上屬於軟性規範 (soft constraint)。對注重時效性的應用程式如股票來說，不能及時取得資料對用戶 造成的影響是相當大的，因此需要明確的硬性規定(hard constraint)告知伺服器其需 圖 11 – 時間重要性流量的效能函數: (a) 傳輸速率 (b) 延遲時間 (c) 封包錯誤率 (a) (b) (c) 1 εreq UR 封包錯誤率 rreq 1 UT 傳輸速率 dreq UD 延遲時間 1 圖 10 – 一般性流量的效能函數: (a) 傳輸速率 (b) 延遲時間 (c) 封包錯誤率 (a) (b) (c) 1 εreq UR 封包錯誤率 rreq 1 UT 傳輸速率 _d req Ubound UD 延遲時間 1

18 求。

在我們分類中的最後一種流量是品質調整性，顧名思義這種類型的應用程式可以根 據網路狀況的改變而選擇不同的服務品質，像是 YouTube 影片跟 Google Earth 的圖像 皆有此種功能，讓使用者根據可用頻寬來決定品質。因此應用程式有多個可能的速率需 求，但是對延遲跟封包錯誤率的需求只有一種，原因在於資料類型並沒有改變，所以仍 有相同的延遲跟封包錯誤率需求。概念上來說，品質調整性流量可以視做多個一般性流 量的集合，因此傳輸速率的效能函數也可以疊合方式來計算，此時它的數學性質變為: 單調遞增(monotonic increasing)和部分凸形(quasi concave)，我們以多邏輯函數 (multi-logistic function)作為模型: 𝑈𝑇(𝑟) =1_𝑛∑ 1 (1 + 𝑒𝑛 ⁄ −𝑟+𝑟𝑟𝑒𝑞𝑛) , 𝑟𝑟𝑒𝑞1< 𝑟𝑟𝑒𝑞2 < ⋯ < 𝑟𝑟𝑒𝑞𝑛。 (5) 當傳輸速率介於兩個需求之間時，使用者獲得的效能只能根據較低的需求計算，因 此函數中有較明顯的階層差，在速率能滿足較高的需求時，效能才會有顯著的提升，如 同(圖 12)所示。 到這邊為止我們已經將所有流量類型的𝑈_𝑇、_𝑈𝐷及𝑈_𝑅都定義完成，但是這是考慮單 一參數的情況下所得出的效能值。實際上用戶效能會同時受到這三個品質參數的影響， 因此我們必須找出它們之間的關聯性並建立一個整合的效能函數表示形式，如同 𝑈(𝑟, 𝑑, 𝜀) = 𝑓(𝑈𝑇(𝑟), 𝑈𝐷(𝑑), 𝑈𝑅(𝜀))。 𝑓是將各個單一參數的效能函數進行合成的方式，例如以加法(additive)或是乘積 (multiplicative)的形式進行，接下來我們將根據多屬性效能定理(Multi-Attribute Utility Theorem)中提倡的標準方式，以數學推導出一個合理的效能描述方法。 多屬性效能定理要成立的基本的前提是效能獨立(utility independent)，意思是 說決策者對於一個參數𝑋的偏好，不會受到另一個參數Y值的影響。其數學定義如下。 定義 1.若決策者對𝑋在給定Y值下的條件偏好(conditional preference)，不受到Y的 圖 12 – 品質調整性流量的效能函數: (a) 傳輸速率 (b) 延遲時間 (c) 封包錯誤率 (a) (b) (c) 1 εreq UR 封包錯誤率 dreq Ubound UD 延遲時間 1 rreq1 UT 傳輸速率 1 rreq2 0.5

19 影響，則𝑋效能獨立於Y。 𝜋 ∙ 𝑢(𝑥1, 𝑦) + (1 − 𝜋) ∙ 𝑢(𝑥2, 𝑦) = 𝑢(𝑥3, 𝑦) ⇒ 𝜋 ∙ 𝑢(𝑥1, 𝑦′) + (1 − 𝜋) ∙ 𝑢(𝑥2, 𝑦′) = 𝑢(𝑥3, 𝑦′) 實際情況中傳輸速率、延遲時間、封包錯誤率這三個參數的效能關聯性可能無法完 全滿足效能獨立的概念，但是根據多屬性效能定理，我們知道在多數情形中可以直接假 設效能獨立滿足於兩兩參數之間。理由在於只要選擇適當的函數型式，就足以良好的模 擬原始效能函數，並達到同樣的效果。進一步可應用許多可能的數學方法，對問題的解 決有很大的助益。 定義 2. 基於效能獨立的假設下， 𝑢(𝑥, 𝑦, 𝑧) = 𝑓(𝑢_𝑋(𝑥), 𝑢_𝑌(𝑦), 𝑢_𝑍(𝑧))且有以下性質 i. 𝑢(𝑥𝑜, 𝑦𝑜, 𝑧𝑜) = 0且𝑢(𝑥∗, 𝑦∗, 𝑧∗) = 1 ii. 𝑢_𝑋(𝑥), 𝑢_𝑌(𝑦), 𝑢_𝑍(𝑧)的值皆落在[0,1]的區間 iii. 可寫成𝑢(𝑥, 𝑦, 𝑧) = 𝑘_𝑥𝑢_𝑋(𝑥) + 𝑘_𝑦𝑢_𝑌(𝑦) + 𝑘_𝑧𝑢_𝑍(𝑧) + 𝑘_𝑥𝑦𝑢_𝑋(𝑥)𝑢_𝑌(𝑦) + 𝑘𝑥𝑧𝑢𝑋(𝑥)𝑢𝑍(𝑧) + 𝑘𝑦𝑧𝑢𝑌(𝑦)𝑢𝑍(𝑧) + 𝑘𝑥𝑦𝑧𝑢𝑋(𝑥)𝑢𝑌(𝑦)𝑢𝑍(𝑧) 從定義 2.中可以看出𝑢(𝑥, 𝑦, 𝑧)中的項次可能有一次項還有乘積項，一次項如 𝑘𝑥𝑢𝑋(𝑥)表示它對總效能有獨立的影響力，而乘積項如𝑘𝑥𝑦𝑢𝑋(𝑥)𝑢𝑌(𝑦)則表示𝑢𝑋(𝑥)對 𝑢(𝑥, 𝑦, 𝑧)的影響，與𝑢𝑌(𝑦)的值有關。為了確定其適當的函數型式，需要引進另一個概念。

定義 3. 若𝑋與𝑌效能獨立，且滿足u(x, y) + u(x′, y′) = u(x′, y) + u(x, y′)，則稱參數𝑋和

𝑌為偏好獨立(preferentially independent)。 當兩個參數𝑋和𝑌為偏好獨立時，意味著總效能與(𝑥, 𝑦)的組合情形無關，而只受到x 和y個別的值所影響。 定義 4. 在多參數效能函數中，若兩兩參數皆為偏好獨立，則函數型式可用完全加性 (additive)表示。若兩兩參數皆非偏好獨立，則可用完全積性函數(multiplicative)表 示。 我們針對服務品質需求的定義，指的是對每個應用程式來說，皆有傳輸速率、傳輸 潛伏時間、封包錯誤率的最低需求。當傳送應用資料時，若任一要求無法被滿足，用戶 即無法獲得對應的品質。現在可以針對定義 2.的標準效能函數形式求得各項的係數， 令𝑈_𝑇(𝑟∗) = 1, 𝑈_𝐷(𝑑𝑜) = 0, 𝑈_𝑅(𝜀𝑜) = 0，則 𝑈(𝑟∗_{, 𝑑}𝑜_{, 𝜀}𝑜_{) = 𝑘} 𝑥 𝑈(𝑟∗_{, 𝑑}𝑜_{, 𝜀}𝑜_{)表示傳輸速率是用戶最偏好的狀態，延遲和封包錯誤率則為最不偏好的狀態。} 根據我們對服務品質的定義，這種狀況下應用程式無法給予用戶可行的品質，即獲得效 能為零，因此𝑘_𝑥= 0。以同樣的方式可知兩兩參數皆非偏好獨立，則根據定義 4.，合 併後的效能函數可表示成 𝑈(𝑟, 𝑑, 𝜀) = 𝑈𝑇(𝑟) ∙ 𝑈𝐷(𝑑) ∙ 𝑈𝑅(𝜀) (6)

20 當應用程式的傳輸協定不同時，同樣的網路品質狀況可實現的用戶效能也會不一樣。 例如應用程式採用 UDP 通訊協定時，封包有錯誤時不需重傳，因此傳輸速率即為資料的 有效傳輸速率(effective throughput)，則效能函數可直接表示成 𝑈(𝑟, 𝑑, 𝜀) = 𝑈𝑇(𝑟) ∙ 𝑈𝐷(𝑑) ∙ 𝑈𝑅(𝜀) 但是若以 TCP 協定進行傳輸，則部分頻寬會用於重傳機制，因此有效傳輸速率會低於其 分配到的頻寬，此時效能函數的型式應為 𝑈(𝑟, 𝑑, 𝜀) = 𝑈𝑇(𝑟̂) ∙ 𝑈𝐷�𝑑̂� ∙ 𝑈𝑅(𝜀) 𝑟̂ = 𝑟(1 − 𝜀 − 𝜀2_{− ⋯ ) ≅ r(1 −} 𝜀 1−𝜀) 𝑑̂ = (𝑇𝑐− 𝐶) +𝑀�_𝑟̂ 𝑇𝑐表示現在時間，𝐶表示工作建立時間，𝑀�則是剩餘資料大小。 3.2.4. 快取機制(Caching Mechanisms) 當一個應用程式的新資料被下載至手機上時，代理伺服器會將其副本放到至本地的 快取儲存區中，快取的可用期限則與應用程式的更新週期相關聯。位於雲端的代理伺服 器會定期的查看應用程式伺服器的狀態，統計分析資料的變化情形以了解應用程式的更 新頻率。雲端代理伺服器會將此資訊傳給有使用此應用程式的手機端代理伺服器，如此 則可以對快取設定其可用的期限。每當用戶使用某個應用程式時，如果快取中有此資料 且尚未過期，則可直接回傳給使用者而避免耗費頻寬傳送重複的內容。如果應用資料的 延遲時間過長，超過其可接受的期限(deadline)，那麼代理伺服器就會判斷將快取中較 舊的資料給使用者。但是當應用程式屬於時間重要性的流量類型，例如股票跟新聞時， 代理伺服器並不會儲存其快取資料，而是在用戶發送資料要求時才向伺服器下載。採用 這種方式的原因在於股票與新聞本身的特性，過期的內容對使用者來說完全沒有價值可 言，只有即時下載才能保證資料的新鮮度。 3.2.5. 應用程式內容預先下載(Application Pre-fetching) 行動網路中的流量在不同時間的差異十分大，大多數人有類似的作息因此傾向於在 差不多的時間存取服務。這種現象會造成壅塞的發生，網路傳輸速率緩慢，服務品質下 降等情形。在基地台或是路由器上遇到此種狀況時，只能選擇將過多的封包丟棄。如果 手機可以在空閒的時候先下載所需的應用資料至本機端儲存，則可有效改善壅塞的問題。 因此代理伺服器除了可以替用戶的要求做排程之外，還可以自動產生工作執行，如此則 能分散各個連線傳輸的時間，使整體效能獲得提升。對使用者來說，則有最小化回應時 間的好處。需要注意的是預先下載的資料沒有被使用者存取的話，反而變成網路的額外 負擔。因此我們運用一個簡單的策略來決定是否該進行預先下載的操作，考慮此決定的 時間點只發生在雲端代理伺服器告知應用程式內容更新時。令使用者存取一個應用程式

21 的間隔時間機率分佈為𝑃_{𝑎𝑐𝑐𝑒𝑠𝑠}(𝑡)，而此應用程式更新的間隔時間機率分佈為𝑃_{𝑢𝑝𝑑𝑎𝑡𝑒}(𝑡)， 這兩種分佈資訊皆可由代理伺服器分析歷史紀錄而取得。預先下載機制能發揮作用的情 況，是使用者在應用程式再度更新前就存取其內容。假設用戶上次存取此應用程式的時 間是𝑥，現在的時間點即應用程式更新時間是𝑢，應用程式下次更新的時間點為𝑢′，則在 𝑢′前存取的機率是 𝑃𝑎𝑐𝑐𝑒𝑠𝑠(𝑢 − 𝑥 ≤ 𝑡 < 𝑢′− 𝑥) = ∫𝑢 𝑃𝑎𝑐𝑐𝑒𝑠𝑠(𝑡)𝑑𝑡 ′_−𝑥 𝑢−𝑥 。 (7) 考慮所有可能的𝑢′: 𝑃ℎ𝑖𝑡 = ∫ 𝑃_𝑢∞ 𝑎𝑐𝑐𝑒𝑠𝑠(𝑢 − 𝑥 ≤ 𝑡 < 𝑢′− 𝑥) ∙ 𝑃𝑢𝑝𝑑𝑎𝑡𝑒(𝑢′− 𝑢)𝑑𝑢′ = ∫ ∫𝑢 𝑃𝑎𝑐𝑐𝑒𝑠𝑠(𝑡) ∙ 𝑃𝑢𝑝𝑑𝑎𝑡𝑒(𝑢′− 𝑢)𝑑𝑡𝑑𝑢′ ′_−𝑥 𝑢−𝑥 ∞ 𝑢 。 (8) 𝑃ℎ𝑖𝑡為預先下載的資料被存取的機率，則對網路來說額外資料量的期望值為 𝑀𝑝𝑟𝑒𝑓𝑒𝑡𝑐ℎ= 𝑀𝑖(1 − 𝑃ℎ𝑖𝑡)。 (9) 當𝑀_{𝑝𝑟𝑒𝑓𝑒𝑡𝑐ℎ}⁄𝐵_𝑚𝑎𝑥 < 𝜑_{𝑑𝑎𝑡𝑎}時，表示對網路的額外負擔在可接受的程度內，就可以建立 預先下載的工作放入待執行工作佇列中。 在 3.1.8 中針對排程演算法中的工作規格進行了詳細的說明，預先下載的工作同樣 也有這些參數，但是設定方式跟一般工作有很大的差異。原本優先權為𝑝_𝑖的應用程式， 其預先下載的工作優先權將被設成𝑝_𝑖 + 𝑁_𝑎𝑝𝑝，這保證了一般工作會先被執行，而在所有 預先下載的工作之間，仍維持著使用者定義的偏好順序。另一方面，預先下載的工作並 非直接傳送給用戶即時使用，因此對服務品質不需有嚴格的要求。我們將其傳輸速率的 需求設為零，傳輸延遲的需求設為應用程式再度更新的時間點，封包錯誤率的需求設為 一。 3.2.6. 排程策略(Scheduling Strategies) 行動網路中的狀況例如可用頻寬、訊號強度、封包錯誤率會隨著時間而連續不斷地 改變。但是實際進行演算法時，無法完全針對所有可能的變化去調整現在的排程，因為 如此會對代理伺服器帶來大量的額外負荷，而所獲得的結果也不一定能明顯改善。因此 我們每隔𝜏_𝑝的時間觀測及計算網路參數的變化，並假設在𝜏_𝑝這段時間內排程演算法需考 慮的網路參數皆不會發生改變，因此𝜏_𝑝即為排程的週期。排程演算法的核心概念，是希 望找出適當的工作傳輸方式以最大化使用者所獲得的效能函數值，當等待執行的工作有 𝑁個時，可以表示成以下的最佳化問題: 最大化∑𝑁_𝑖=1𝑊(𝑝_𝑖) ∙ 𝑈_𝑖(𝑟_𝑖, 𝑑_𝑖, 𝜀)， 限制條件為 0 ≤ ∑𝑁𝑖=1𝑟𝑖 ≤ 𝑟𝑚𝑎𝑥 ， 𝑑𝑖 = (𝑇𝑐−𝐶𝑖) + 𝑀� 𝑟𝚤⁄ 𝑓𝑜𝑟 ∀𝑖。 𝑖 𝑊(𝑝𝑖) = 1 (𝑝⁄ 𝑖 ∙ (1 −𝑇_𝑑𝑐−𝐶𝑖 𝑖,𝑟𝑒𝑞)) 𝑈𝑖(𝑟𝑖, 𝑑𝑖, 𝜀)是第𝑖個工作的效能函數，注意效能函數會因流量類型以及服務品質需求的差 別而有不同形狀。加權函數_{𝑊(𝑝𝑖})會隨著𝑝_𝑖值越小，即優先順序越高時而增加，並隨著

22 時間越來越接近工作的期限而增加。𝑇_𝑐表示現在時間，𝐶_𝑖是工作建立時間，𝑀�是資料剩_𝚤 餘大小。𝑝_𝑖是用戶偏好而𝜀是封包錯誤率，𝜀的值與工作互相獨立只與現在網路狀況有關， 這兩者皆非排程時可以改變的因素。𝑑_𝑖會受到𝑟_𝑖的影響而變化，因此我們在排程方法中 考慮的問題簡化成找出一組適當的(𝑟₁, 𝑟₂, … , 𝑟_𝑁)。後面提到效能函數時，若無特別說明， 則𝑈_𝑖(𝑟_𝑖, 𝑑_𝑖, 𝜀)和𝑈_𝑖(𝑟_𝑖)表同一概念。此問題可用拉格朗日乘數法(lagrangian multiplier) 來表示，意即對以下方程式組求解。 ∑𝑁𝑖=1𝑟𝑖− 𝑟𝑚𝑎𝑥 = 0 (10) 𝑑 𝑑𝑟𝑖∙ ∑ 𝑊(𝑝𝑖) ∙ 𝑈𝑖(𝑟𝑖, 𝑑𝑖,𝜀) 𝑁 𝑖=1 = _𝑑𝑟𝑑_𝑖𝜆 ∙ (∑𝑁𝑖=1𝑟𝑖− 𝑟𝑚𝑎𝑥) , ∀𝑖 (11) 等式(11)可改寫成下列的式子。 𝑊(𝑝𝑖) ∙ 𝑈𝑖′(𝑟𝑖) = 𝜆 , ∀𝑖 (12) 我們可找到其解為 𝑟𝑖 = (𝑈𝑖′)−1(_𝑊(𝑝𝜆_𝑖)) , ∀𝑖 (13) 有_{𝑁 + 1個式子，理論上可以解出𝑟1, 𝑟2, … , 𝑟𝑁, 𝜆，但是由於效能函數由三個部分組成，} 要計算微分及反導數所耗費的複雜度太高，無法在實務中運用，因此我們採用了試探性 (heuristic)原則來做區域性的最佳化，以嘗試接近於最佳解。 引理 1. 當工作列表不變動時，在_𝜏𝑝時間內的效能最大化方式唯一，意即存在唯一一組 的_{(𝑟1, 𝑟2, … , 𝑟𝑁)，使∑}𝑁_{𝑖=1𝑊(𝑝𝑖) ∙ 𝑈𝑖}(𝑟_{𝑖, 𝑑𝑖,}𝜀)最大。 說明.基於我們前面的假設，在_𝜏𝑝時間內網路參數皆不變化，會改變的只有剩餘資料大 小。我們可以明顯看出在(𝑈_𝑖′)−1( 𝜆 𝑊(𝑝𝑖))這個值中，並不受到資料大小的影響，因此總效 能也不會變化。 除了每次到達排程週期𝜏_𝑝的時間需要進行重新計算外，每當有工作完成或是新工作 加入時，也需要重新考慮資源的利用及排程，以得出新的效能最大方式。我們將演算法 的執行分成兩個部分，工作選擇階段(job selection phase)和頻寬分配階段(bandwidth allocation phase)。在工作選擇階段，會依據用戶偏好跟可獲取的效能來決定工作應 執行的順序。在頻寬分配階段，則考慮如何分配頻寬給各個工作可獲得最大利益，同時 試著將流量分散至不同時間，以減少網路負擔。 我們根據系統中工作執行的狀態不同，將所有工作分成三個集合(set)。一個新工 作剛加入時會進入等待集合(waiting set)，正在進行傳輸的工作屬於活躍集合(active set)，已經傳輸部份資料而現在暫停的工作屬於不活躍集合(inactive set)。在(圖 13) 中可以看到工作如何在狀態間移動，藍色的狀態表示此工作還在系統中待處理，紅色則 表示已離開系統，可能是完成或是被丟棄。 在工作選擇階段時，我們對三個集合中的工作皆計算其潛在效能值(potential utility value)。潛在效能值指的是在給定工作最大可用頻寬𝑟_𝑚𝑎𝑥時，使用者所能得到

23 的效能，也就是根據𝑊(𝑝_𝑖) ∙ 𝑈_𝑖(𝑟_𝑚𝑎𝑥)做排序。有了工作的潛在效能次序後，並不直接根 據此順序來執行工作，而是進一步考慮其傳輸親和性(transmission affinity)。傳輸 親和性指的是正在傳送資料的連線，會傾向於保持在活躍的狀態，意即對使用者來說， 連續且平穩的資料下載能提高用戶體驗。因此我們提出了狀態變化的門檻值 (threshold)，等待和不活躍集合中的工作效能比活躍集合的工作效能高過門檻，才能 搶先活躍工作執行。基於傳輸親和性調整順序的演算法如下。

Let 𝑗𝑜𝑏1, … , 𝑗𝑜𝑏𝑁 be the job list in descending order of potential utility value

𝐹𝑜𝑟(𝑖 = 1~𝑁)

{ If( 𝑗𝑜𝑏𝑖 belongs to waiting or inactive set)

𝐹𝑜𝑟(𝑗 = 𝑖 + 1~𝑁)

If( 𝑗𝑜𝑏𝑗 belongs to active set)

𝐼𝑓(𝑊(𝑝𝑖) ∙ 𝑈𝑖(𝑟𝑖, 𝑑𝑖, 𝜀) − 𝑊(𝑝𝑗) ∙ 𝑈𝑗�𝑟𝑗, 𝑑𝑗, 𝜀� < 𝑈𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑)

Switch the positions of 𝑗𝑜𝑏𝑖 𝑎𝑛𝑑 𝑗𝑜𝑏𝑗

} 我們以(圖 14)做為例子來說明以上演算法的實際運作情形，左邊是根據潛在效能 值排序完的工作順序，右邊是考慮傳輸親和性進行調整後的結果。這種方式有兩個優點， 其一是將資源集中於活躍的工作，避免許多工作都只傳輸了部分資料的狀況，其二是減 少工作時常在狀態中切換(switch)，造成傳輸品質不佳的問題。 知道了工作執行順序後，接著我們選擇可滿足 New job arrives Data transfer starts Pause session Resume session Data rate changes Stale data Stale data Data transfer completed Waiting Discard Finish Inactive Active 圖 13 – 工作狀態變化示意圖