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 應用程式定義的服務品質(Quality of Service, QoS)需求，而用戶檔案則包括了使用 者對應用程式的個人偏好及用戶歷史行為。有了適當的輸入資訊後，演算法就能據此找 出一個可能的工作排程方式。決定好的排程將交由代理伺服器的連線控制模組(session control module)執行，開始進行應用程式資料的下載。
雲端代理伺服器接收到從手機端來的連線，會先搜尋快取，如果快取中沒有對應內 容才向應用程式伺服器下載。除了轉送手機端來的連線要求，雲端代理伺服器還會定期 自動查看應用程式伺服器的情況，以分析應用程式的更新週期。雲端代理伺服器會將更 新週期的資訊利用 C2DM 的機制送給手機端的代理伺服器，與用戶行為模式一同作為決 定是否預先下載的參考。
3.1.5. 服務品質參數(QoS Parameters)
MS Proxy Proxy main
console
App. update pattern waiting list Job
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 播放影片時，有多種解析度可 選擇，當用戶頻寬能滿足某個需求時，就能獲得相應的效能。但是頻寬介於高解析 度和低解析度需求之間時，仍然只能播放低解析度的影片，當頻寬符合高解析度的
內容，因此可以對每個服務品質參數定義多個可能的需求等級，並根據現在的網路 資源調選擇可接受的品質層級。Google Earth 的地面圖像和 YouTube 的影片皆屬於 此類型。可能的效能函數圖形如(圖 6)，可以看到在傳輸速率的層面，函數形狀就 像階梯一般有較明顯的間隔。舉例來說，在 YouTube 播放影片時，有多種解析度可 選擇，當用戶頻寬能滿足某個需求時，就能獲得相應的效能。但是頻寬介於高解析 度和低解析度需求之間時，仍然只能播放低解析度的影片，當頻寬符合高解析度的