540 likes | 664 Views
嵌入式通訊系統之運算資源調適控制機置設計與製作. Computing Resource Adaptation Control Mechanism fo Embedded Communication Systems. 報告者:龔旭陽 教授 日期: 2008/11/04 國立屏東科技大學 資訊管理系. NSC 96-2218-E-020-002 NSC 97-2218-E-020-001. 報告大綱. 研究背景 研究議題 系統設計目標 系統架構與流程 系統實作展示 系統效能分析 成果可應用性 結論. 2. 研究背景. 研究背景與動機
E N D
嵌入式通訊系統之運算資源調適控制機置設計與製作 Computing Resource Adaptation Control Mechanism fo Embedded Communication Systems 報告者:龔旭陽 教授 日期:2008/11/04 國立屏東科技大學 資訊管理系 NSC 96-2218-E-020-002 NSC 97-2218-E-020-001
報告大綱 • 研究背景 • 研究議題 • 系統設計目標 • 系統架構與流程 • 系統實作展示 • 系統效能分析 • 成果可應用性 • 結論 2
研究背景 • 研究背景與動機 • 隨著行動通訊技術日漸成熟,使用者將可於任何時間(Anytime)及任何地點(Anywhere)進行個人化的影音聲光服務。 • 然而在行動通訊網路環境下,尚有一些特性需要去克服解決,如:低頻寬(Low Bandwidth)、可用網路頻寬(Available Bandwidth)變動快速及隨機封包遺失(Random Loss)等。 • 行動裝置(Mobile Appliances)與桌上型電腦之運算環境差異甚大,其中央處理器(CPU)運算速度慢、記憶體(Memory)容量少、電力(Power)有限與網路頻寬(Bandwidth)不足等有限資源之缺點。
研究議題 • 影音串流服務時,對行動通訊設備運算資源的影響 • CPU處理能力-需進行大量複雜運算 –但 CPU 能力有限 • 記憶體負載-需進行串流資訊之緩衝暫存 – 但 memory 容量小 • 電力耗損-無線網路開啟與多媒體播放耗用大量電力 – 但電池容量小 • 螢幕感觀效果-手持設備無法提供大畫面播放效果 • 影音串流服務時,對網路頻寬狀況影響 • 傳輸速率-串流傳輸需依靠穩定傳輸速率 • 網路頻寬-串流傳輸需仰賴一定頻寬大小 • 延遲-串流傳輸可能造成客戶端接收不一的封包順序 • 封包遺失-串流傳輸產生封包遺失
系統設計目標 • 研究目標 • 本計畫提出一行動裝置之運算資源與多媒體服務品質控制系統(Computing Resource Adaptation Control Mechanism for Embedded Communication Systems, CRAC)。 • 提出運算資源調適控制機制(Computing Resource Adaptation Control) ,針對中央處理器(CPU)、記憶體(Memory)、行動網路(Mobile Network)及電源(Power)進行系統資源監控與管理。 • 根據運算資源資訊執行多媒體品質調適決策,提供使用者較合適之多媒體服務品質(Quality of Service, QoS)。
專案開發模式: LW-CMMI • 需求分析與系統設計階段:負責收集相關資訊,進而分析CRAC系統的軟硬體需求。 • 系統(雛型)開發階段:撰寫CRAC系統程式。 • 系統(雛型)整合階段:整合CRAC系統內子系統。 • 系統(雛型)測試階段:評估CRAC系統效能,當系統的執行效能不如預期時,則必須重回第一階段。 • 專案結案階段:撰寫系統報告文件。
系統架構 CRAC系統控制機制: (1) 運算資源與多媒體服務品質控制機制 (2) 預排式多媒體流量控制機制
系統功能說明- Multimedia Server • 事件分析者(Event Analyzer):主要功能為接收行動客戶端所傳送之連線要求、多媒體服務品質(QoS)決策與網路頻寬狀況等。 • 多媒體檔案櫃(Multimedia File Storage):主要負責存放MPEG-4之多媒體影片。 • 傳輸控制器(Rate Controller):根據行動客戶端所回傳之網路頻寬資訊來調整多媒體之傳輸速率,以符合行動網路快速變動之特性。 • QoS監控器(QoS Monitor):根據行動客戶端所回傳之QoS決策來平順切換多媒體服務品質 。
系統功能說明- Mobile Client • QoS決策者(QoS Decision):分析行動裝置之網路頻寬資訊、記憶體(Memory)及中央處理器(CPU)的使用情況,來決定是否需要調整QoS,並將QoS決策傳送至Feedback Dispatcher。 • 電源管理者(Power Manager):主要監控行動裝置之即時電源消耗資訊,並依照播放多媒體串流之不同情境,動態調適感觀裝置之電力供應等級,提升行動裝置續電力。 • 回饋派送者(Feedback Dispatcher):將行動裝置之運算資源及QoS決策回傳至多媒體伺服器之Event Analyzer,提供行動客戶端之即時資訊。
運算資源與多媒體服務品質控制機制(CRMQ) • 其目的依據客戶端中央處理器能力、記憶體負載程度與網路頻寬之變化進行資源監控 • 依據監控的設備資源參數值進行多媒體串流影音品質調適決策,並且加入電力管理機制,依據各項運算資源情境進行感觀設備調適。 • 電力管理 針對行動裝置進行電源管理,使電池進行感觀設備調適,並提升續電能力。 • 多媒體品質調適決策 依據CPU使用率、記憶體耗用程度與網路壅塞情況為決策判斷進行影音串流品質調適。 多媒體伺服器:接收使用者請求,並進行影音串流傳輸與速率和QoS調適。
預排式多媒體流量控制機制(PSFC) • 預排式多媒體流量控制機制(PSFC) 評估網路狀況,並於壅塞狀態時進行影音串流速率控制,將所接收的資訊暫存於記憶卡內,以達到網路狀況不穩時也能平順播放影音串流服務。 • 無線網路頻寬之偵測機制 使用TIBET與Measurement-Based TFRC進行網路頻寬偵測。 • 多媒體動態調適之傳輸策略 無線網路的狀況及頻寬的變化來決定多媒體之傳輸控制。 • 多媒體預載決策機制 判斷網路頻寬狀態進行傳輸預載控制。
CRAC系統流程 • 使用者連線伺服器並且發送影片請求。 • 向媒體庫搜尋影片檔案。 • 將搜尋結果傳送至Stream Sender。 • Feedback Dispatcher傳送QoS與設備資源至事件分析。 • Feedback Dispatcher持續將網路狀況至事件分析。
CRAC系統流程 • 事件分析依據所接收的QoS與資源等資訊進行多媒體品質調適。 • 事件分析依據所接收的網路狀況進行傳輸速度調控。 • 事件分析評估網路壅塞狀況進行預載控制。 • 進行多媒體影音串流傳輸。 • 多媒體影音播放控制。 • 影音播放同時,啟動電力調適機制。
網路頻寬偵測 • 網路頻寬的偵測可以藉由傳輸的流量與T時間週期比值來運算 • 計算出平均的封包長度 、每個封包的平均傳輸時間 以及資料單位的傳送時間TimeInterval。 (Capone et al., 2004 & Liang et al., 2005)
網路頻寬偵測 • 由於行動網路頻寬變動較起伏,所以網路頻寬偵測機制導入指數加權移動平均法(Exponentially Weighted Moving Average, EWMA) • 利用歷史資料與目前觀察值兩個權重來運算出較平緩且彈性的網路頻寬數據 • 以動態調整α權重,以便計算出較準確的網路頻寬值 • 經由EWMA filter所估測的網路頻寬值
網路頻寬狀態變化 • 行動網路的狀態變化,將運用統計學正負三個標準差的標準常態數值區域概念,來區分目前的行動網路是趨於穩定還是震盪起伏的狀態 • 如果此一時間週期的平均網路頻寬值Bwi落在正負三個標準差 之間的話,則目前行動網路是趨於穩定的狀態,反之則是趨於震盪起伏的狀態 (Lin et al., 2006) • μ為上一時間週期所估測的網路頻寬值EBwi-1,σ則為上一時間週期的網路頻寬平均變動範圍 除以評估標準差的係數d2,而d2 的值近乎於1.128 (Kim and Nobe, 2001) • 利用β及(1-β)兩個權重來加權計算標準差的網路頻寬平均變動範圍 • 行動網路於穩定狀態下的頻寬範圍區間:正負三個標準差()
網路頻寬偵測 • 行動網路頻寬之偵測機制 • 提出結合TIBET (Time Intervals based Bandwidth Estimation Technique) (Capone et al., 2004)與Measurement-Based TFRC (Lin et al., 2006) • T時間週期的平均網路頻寬值 • 經由EWMA filter所估測的網路頻寬值 • 正負三個標準差()
網路頻寬偵測 • 行動網路頻寬之偵測機制:網路頻寬值之正負三個標準差 • Bwi落在此範圍區間,則行動網路的狀態為stable,即較為穩定,所以將α設為0.9,β設為0.6 • 如果Bwi落在範圍區間之外,則會有個suspect window來記錄此一情況,代表網路疑似不穩定,因為行動網路具有隨機封包遺失(Random Loss)的特性,此時不會即時調整網路頻寬值之權重,先觀察此情況是否為隨機封包遺失所造成,直到suspect window的window size連續累積到四次
多媒體動態調適之傳輸策略 • 多媒體動態調適之傳輸策略: 壅塞變數 γ (1) 網路狀態為stable (2) 網路狀態為unstable (Liang et al.,2005)
運算資源監控與管理 • 收集客戶端的系統資訊:CPU與記憶體資訊。 • 微軟(Microsoft) MSDN所提供MEMORYSTATUS及STORE_INFORMATION此兩種結構,含有監控行動裝置系統記憶體資源之結構變數 • 系統記憶體資源之結構變數
運算資源監控與管理 • 運算CPU使用率之相關函式 • GetTickCount函式為從系統開機以來,已過了多久時間,單位是毫秒 • GetIdleTime函式為從系統開機以來,已經閒置的時間,單位是毫秒。 • 中央處理器(CPU)使用率
電源管理機置 • 以Windows CE 5.0的系統架構為主,電源管理架構如圖 (MSDN Library, 2006)所示 • 利用Application及Driver之電源相關APIs,來支援此電源管理設計,而Power Management APIs則會呼叫Power Manager (Pm.dll),此Pm.dll會直接連結Device.exe,提供Power Management APIs的要求。
電力監控 • 行動裝置的電力監控,將使用微軟(Microsoft) MSDN所提供系統電源狀態之SYSTEM_POWER_STATUS_EX2結構,以此結構變數來獲得電池電源的相關資訊
電力監控函式 • 電池電源狀態 • 系統電池電源狀態的結構變數
電力監控函式 • 裝置電源狀態與調整系統及裝置電源之相關函式 • 運算電池耗盡時間之相關參數
電源管理機置 • 電源管理機置 • 行動裝置播放多媒體串流時,主要的運作裝置為背光(30%)、聲音(22%)及網路(17%)此三種裝置,此三種裝置也是手持式設備耗電比率較高的裝置。(南加州大學 2005) 調整系統及裝置電源之相關函式
電源管理機置 • 電源管理機置 • 行動裝置播放多媒體串流時,主要的運作裝置為背光(30%)、聲音(22%)及網路(17%)此三種裝置,此三種裝置也是手持式設備耗電比率較高的裝置。 • 依剩餘電池電量百分比,將針對背光、聲音及網路此三種裝置調整電力供應等級,並自動調適對應裝置之感觀品質。 電力情境等級
電力與播放品質動態調整機置 • 動態調整裝置電力供應等級與感觀品質自動調適 :電力充足(剩餘電量70%~100%) • X軸為時間,依序經過程式開始、串流緩衝、播放串流到結束播放,Y軸為行動裝置之電力供應等級。
電力與播放品質動態調整機置 • 動態調整裝置電力供應等級與感觀品質自動調適 :電力充足(剩餘電量30%~70%) – 背光與聲音調降一等級
電力與播放品質動態調整機置 • 動態調整裝置電力供應等級與感觀品質自動調適 :電力充足(剩餘電量0%~30%) – 背光與聲音再調降一等級
系統實作展示 • 系統可選擇多媒體檔案櫃路徑,存放MEPG-4相關格式之多媒體影片,並將所有影片顯示在多媒體檔案列表中,在多媒體檔案的管理上,可藉由新增、修改及刪除的功能按鈕得以完成,直接進行多媒體檔案之存取。 多媒體伺服器端
系統實作展示 串流播放器 本地播放器
系統實作展示 電力監控 資源監控
系統實作展示 感觀設備調適-調適前 感觀設備調適-調適後
系統實作展示 網路傳輸監控
效能分析 • 實驗平台
效能分析(續) • 系統初始環境
效能分析(續) • 系統初始環境
效能分析(續) • 實驗設定 • 影片品質於事先進行轉碼,在視訊部分使用Windows Media MPEG-4 V2視訊轉碼器,在音訊部分使用Windows Media Audio V9音訊轉碼器,並將影片轉成ASF串流格式進行測試。 DirectShow Filter Graph Manager
效能分析(續) • 多媒體服務品質(QoS)
網路頻寬效能分析 • 網路頻寬偵測分析 • 在TIBET+MBTFRC方法中,可運算出較平順且彈性之網路頻寬,不管在網路是否於穩定狀態,都有其對應的方式來取得網路頻寬,也能較客觀的決定多媒體服務品質(QoS)
效能分析(續) • 多媒體服務品質調適分析: 提升QoS • 在行動裝置播放多媒體串流時,先選擇QoS-2等級來播放,隨著時間的進行,發現還有足夠的CPU使用率,隨即調整QoS,從QoS-2等級慢慢提升到QoS-4等級,CPU使用率則保持在80%~90%之間
效能分析(續) • 多媒體服務品質調適分析: 調降QoS • 一開始選擇QoS-5等級來播放 ,開始播放時,CPU使用率在超過90%的狀態,所以通知多媒體伺服器調整QoS,從QoS-5等級調降至QoS-4等級,後來則保持在QoS-4等級到播放結束。
記憶體使用控制效能分析 • 測試程式所使用之記憶體與可用記憶體比較圖(未使用記憶體控管)
記憶體使用分析 • 系統常註程式必要性(PDA)
記憶體使用控制效能分析 • 使用記憶體控管 執行第一次RRC 執行播放程式 執行第二次RRC
電源管理機置效能分析 • 電源管理分析 • 一般模式與電源管理模式之剩餘電量分析(待機模式)
電源管理機置效能分析 • 電源管理分析 • 電池耗盡時間分析(待機)
電源管理機置效能分析 • 電源管理分析 • 一般模式與電源管理模式之剩餘電量分析(播放模式)