中 華 大 學 碩 士 論 文
題目：在行動計算環境中以新增有序遺失區段方 式解決資料遺失問題的資料廣播方法
A Data Broadcast Scheme Based on Add Ordered Missing Data Approach for Mobile Computing
Environments with Data Missing
系 所 別：資訊管理系碩士班 學號姓名：M09410026 莊育銘 指導教授：李之中 博士
中華民國 九十六 年 七 月
摘 要
在行動計算環境中使用資料廣播的方法，不但可以克服行動客戶端的規模問 題，同時也可以有效的節省行動客戶端執行應用時的能源消耗。但是當廣播伺服 器端依據廣播結構中的時間索引所決定的時間進行廣播時，如果資料是來自一個 無法確定時間的資料來源時，此時可能發生廣播時間已到，但是資料卻無法取得 的情形，進而導致廣播資料無法準時播出，我們稱此為資料遺失問題。當行動客 戶端所需的資料項發生資料遺失時，行動客戶端無法取得所需的資料項，應用可 能被迫中止進行。本論文提出了一個新的改進方式－新增有序遺失區段方式，改 進現行的資料廣播方法。我們並以系統模擬進行效能評估，結果顯示，以新增有 序遺失區段方式所改進的資料廣播方法在調校時間上比新增遺失區段方式所改 進的資料廣播方法來的少；在另一方面，以新增有序遺失區段方式所改進的資料 廣播方法在延遲時間上與新增遺失區段方式所改進的資料廣播方法相同。因此新 增有序遺失區段方式所改進的資料廣播方法在效能上優於新增遺失區段方式所 改進的資料廣播方法。
關鍵詞：行動計算、資料廣播、資料遺失問題
Abstract
Data broadcast is an efficient method for disseminating data items in a mobile computing environment. With the data broadcast method, data items are broadcast periodically according to a predetermined schedule. If a data item is retrieved from a storage device with a nondeterministic access time, the content of the data item may not be ready when it is required in a broadcast cycle. We call this problem the data-missing problem. When data missing occurs, a mobile client which requires the up-to-date contents of the missed data items will be forced to terminate its related application. In this paper, we will propose a new approach - add ordered missing data and use it to revise the data broadcast schemes. We compare the performance of the revised schemes in terms of access time and tuning time. The comparison shows that the tuning time of an add-ordered-missing-data-based revised scheme is shorter than that of its add-missing-based counterpart. However, the latency of the former is the same as that of the latter. Thus, we conclude that the revised scheme based on add ordered missing data approach excels its counterpart based on add-missing approach.
Keywords：Mobile computing、Data broadcasting、Data-missing problem
誌 謝
兩年的碩士生涯即將結束，首先要感謝我的指導教授李之中博士，在這兩年 研究所期間對於我不辭辛勞地指導，使本論文能夠順利的完成，也感謝老師在此 過程中引導我獨立思考的能力，使我在研究的過程中，學習到嚴謹的研究態度和 方法，在此真誠的感謝老師的教導。此外，還要感謝口試委員邱登裕博士與蔡耀 弘博士，給予我許多寶貴的意見與看法，使我的論文能夠更加完善。
在研究所的這段期間很開心有夏暘、郁君這兩位伙伴，陪伴著我一起並肩努 力，在研究上適時的給予我意見與鼓勵，在生活上互相幫忙與扶持，使我的研究 能夠順利完成。另外還要感謝學弟妹政傑、莉婷與芃安，以及商業智慧實驗室的 同學兆瑜、韋綸、謹豪、冠呈、逸芸這段時間在生活上的陪伴，使得我這兩年的 研究所生活有著許多美好的回憶，在此致上由衷的謝意。
最後要感謝多年來辛苦養育我的父母親以及我的家人，因為有你們的照顧我 才能無後顧之憂的專心完成我的論文，因為有你們鼓勵與支持才讓我有機會完成 碩士的學位，在此希望將我的論文與你們一同分享。
莊育銘 謹誌於中華大學資訊管理研究所 九十六年七月
目 錄
摘 要 ... I
Abstract...II
誌 謝 ... III 目 錄 ... IV 圖 目 錄 ...V 表 目 錄 ...VII
第一章 序論 ...1
第一節 行動計算的環境...2
第二節 資料廣播...5
第三節 研究動機...8
第四節 論文架構...10
第二章 相關研究 ... 11
第一節 資料廣播環境...11
第二節 索引結構...13
第三節 現存的資料廣播的方法...18
第四節 現存解決資料遺失問題的資料廣播方法...20
第三章 新增有序遺失區段方式 ...35
第一節 新增有序遺失區段方式...36
第二節 以新增有序遺失區段方式修正的資料廣播方法...37
第三節 實例說明...43
第四章 實驗設計與分析 ...51
第一節 系統模擬...51
第二節 實驗設計與變數...51
第三節 效能分析...52
第五章 結論 ...59
參考文獻 ...61
附錄一 調校時間變化 ...63
附錄二 (1, m) indexing-AOM, m=2 程式碼 ...67
圖 目 錄
圖1-1 行動計算環境 ...3
圖1-2 混合模式的資料廣播方式 ...7
圖1-3 Tuning Time與Latency Time ...8
圖2-1 廣播磁碟的架構 ...12
圖2-2 樹狀的廣播結構 ...14
圖2-3 索引節點的Attribute_value ...15
圖2-4 樹狀的廣播結構 ...16
圖2-5 Tune_opt的廣播結構 ...17
圖2-6 Latency_opt 的廣播結構 ...18
圖2-7 Tune_opt 的廣播結構 ...19
圖2-8 (1, m) indexing, m=3 的廣播結構 ...19
圖2-9 Latency_opt-RA的廣播結構 ...21
圖2-10 Tune_opt-RA的廣播結構 ...21
圖2-11 (1, m) indexing-RA , m=3 的廣播結構...22
圖2-12 Latency_opt-AM的廣播結構 ...24
圖2-13 Tune_opt-AM的廣播結構 ...25
圖2-14 Tune_opt-AM 的擷取程序 ...25
圖2-15 (1, m) indexing-AM, m=3 的廣播結構 ...27
圖2-16 (1, m) indexing-AM 的擷取程序...28
圖2-17 Tune_opt-IAM的廣播結構...32
圖2-18 (1, m) indexing-IAM , m=3 的廣播結構 ...33
圖3-1 Tune_opt-AOM的廣播結構 ...38
圖3-2 Tune_opt-AOM 的擷取程序 ...38
圖3-3 (1, m) indexing-AOM , m=3 的廣播結構...40
圖3-4 (1, m) indexing-AOM 的擷取程序 ...41
圖3-5 樹狀的廣播結構 ...43
圖3-6 廣播排程 ...44
圖3-7 資料遺失時廣播伺服器端的處理程序 ...44
圖3-8 Case 1 資料遺失時行動客戶端的擷取程序 ...45
圖3-9 Case 2 資料遺失時行動客戶端的擷取程序 ...47
圖3-10 Case 3 資料遺失時行動客戶端的擷取程序 ...49
圖4-1 在不同資料遺失機率的調校時間 ...54
圖4-2 在不同資料遺失機率的延遲時間 ...55
圖4-3 降低遺失資料區段中資料遺失機率的調校時間 ...57
圖4-4 降低遺失資料區段中資料遺失機率的延遲時間 ...58
表 目 錄
表2-1 bucket的表頭資訊...14
表4-1 系統模擬相關參數 ...52
表4-2 廣播週期的長度 ...53
表4-3 在不同資料遺失機率的調校時間 ...53
表4-4 在不同資料遺失機率的延遲時間 ...55
表4-5 降低遺失資料區段中資料遺失機率的調校時間 ...56
表4-6 降低遺失資料區段中資料遺失機率的延遲時間 ...57
第一章 序論
隨著行動通訊技術的發展，再加上無線通訊環境所需的基礎設施廣泛的建 置，使用者可以在任何時間、任何地點，透過可攜式無線通訊設備來滿足隨時隨 地都可獲得資訊的便利性，這樣的環境被稱為行動計算環境。在行動計算環境 中，受限於許多的限制(如通訊頻寬較小、容易斷線、行動客戶端(Mobile Client) 有限的能源等)，當行動客戶端數目眾多且同時向資料庫伺服器端要求資料時(例 如在台灣的股票交易期間，大多數的使用者可能對某支股票的股價感到興趣，因 此在股票市場交易的任一時間，可能同時有許多的使用者想要擷取該股票的股價 資訊)，這可能會造成行動客戶端與資料庫伺服器端間上下傳通道的不敷使用，
而導致在行動客戶端中所執行的應用程式因為無法及時取得通訊通道而造成反 應時間(Response Time)過長，或是應用程式無法執行的窘境。
幸運的是，此種規模性的問題(Scalability Problem)已經被學界利用資料廣播 (Data Broadcast)方法來克服。在資料廣播方法中，行動客戶端無須向資料庫伺服 器端發出擷取資料的請求。取而代之的是由資料庫伺服器透過廣播伺服器，將使 用者感興趣的資料「推」（Push）給行動客戶端。原則上行動客戶端只要監聽所 需要的資料項在廣播通道（Broadcast channel）上是否由廣播伺服器端根據廣播 結構（Broadcast structure）所廣播。廣播伺服器端是將使用者感興趣的資料項根 據預先排定的廣播排程以廣播的方式傳送給行動客戶端。而當行動客戶端所需資 料項被廣播時，行動客戶端只要從廣播通道中擷取所需的資料項即可。如此廣播 伺服器可以在僅使用一個下傳通道的情形下，傳遞所有行動客戶端所需的資料 項。因此，行動客戶端之間無需競爭連接資料庫伺服器端的通訊通道，而整個系 統執行應用的成本與效能，不會受到行動客戶端數量的影響，而使得行動客戶端 的規模問題得以解決。
在本章中我們首先介紹行動計算環境，依序說明資料廣播模式、效能評估的 指標、研究動機與本論文的架構。
第一節 行動計算的環境
在現今科技發達的時代來說，網路己成為不可或缺的資料傳輸方式，近年來 也由於網路傳輸的技術發展，從傳統的有線網路進而發展到透過空氣分子做為無 線電波傳遞訊號的無線網路，也由於無線網路的移動性與便利性，使得無線網路 的應用更為普及。無線網路的特性著重在不須要佈線，不受實體的限制可隨時隨 地使用網路連線，在加上目前WI-FI無線上網熱點的普及與通信業者所提供的 GPRS與3G無線上網，因此使用者可以利用行動裝置在任何時間、任何地點，透 過這些無線通訊技術存取伺服器端上的資訊就更加便利了，而這結合可攜式行動 裝置與無線通訊技術的運作環境則稱之為行動計算的環境(Mobile Computing Environment)[1,2,3]。
在行動計算的環境中，主要的架構是由固接式的網路(Fixed Network)、固定 式的主機(Fixed Host)、行動支援裝置(Mobile Support Station，MSS)與行動單元 (Mobile Unit，MU)所組成。行動單元指的是持有行動裝置(UMPC、PDA、
NOTEBOOK 等具有行動通訊的產品)的行動客戶端，利用 GPRS、3G 或 WI-FI 等無線通訊的連線方式與行動支援裝置做連結，再透過行動支援裝置使用固接式 的網路與固定式的主機進行資料通訊，行動支援裝置是具有無線通訊傳輸功能的 伺服器，主要是作為行動單元與固定式主機間溝通的橋樑，每個行動支援裝置所 發射的無線訊號所能涵蓋的範圍稱為蜂巢狀區域(Cell)，並且每個行動客戶端在 同一時間中只屬於某個蜂巢狀區域的行動支援裝置所管理，而固定式主機之間或 是與行動支援裝置則是藉由固接式的網路來進行資料通訊，如圖1-1 則為行動計 算的環境。
圖1-1 行動計算環境
與傳統固接式有線網路相比，無線通訊的行動計算環境所擁有的特性[1,4]
如下：
(1) 傳輸媒介的不同：傳統的網路架構與無線通訊的架構最大的不同點就是在過 去的網路架構的傳輸媒介是必須透過固接式的線路(如雙絞線、同軸電纜、光 纖等傳輸媒介)連接，而無線通訊架構的傳輸媒介是透過空氣分子做為無線電 波傳遞訊號的無線網路，不須要佈線，不受實體的限制。
(2) 有限的頻寬：在行動計算的環境下，無線通訊的頻寬(PHS(64 Kbps)、GPRS(115 Kbps)、3G(2 Mbps)與 WI-FI(54 Mbps)等)相較於有線網路頻寬(100 Mbps、1000 Mbps)是比較低的，除此之外無線通訊也容易受外在環境的影響，無法如有 線網路提供穩定的頻寬。
(3) 有限的能源：由於行動客戶端所使用的移動式通訊裝置(UMPC、PDA、
NOTEBOOK 等具有行動通訊的產品)多半是使用電池作為供電來源，而且使 用無線通訊的耗電量相當的高，再加上移動式通訊裝置體積上的限制，造成 電池無法持續長時間供電。此外由於技術的瓶頸，在未來的幾年間電池的容
量只會有20％的成長[5]。
(4) 非對稱式的傳輸環境：在行動計算的環境下，資料傳輸的上傳與下載的流量 有 著 極 大 的 差 異 ， 由 伺 服 器 端 傳 送 到 行 動 客 戶 端 的 下 傳 通 道(Downlink channel)的流量往往大於由行動客戶端傳送到伺服器端的上傳通道(Uplink channel)的流量，因此雙向的頻寬並不對稱，造成行動客戶端的上傳頻寬低於 下載的頻寬。由另一方面來看，由單一伺服器所必須服務的行動客戶端數量 來看，也是另一種非對稱式的傳輸環境。
(5) 經常性的離線：例如 WI-FI 無線網路的有效距離在開放式空間約是 150 公尺，
距離越遠訊號越弱，遇有阻隔物(木板、屏風、水泥等隔間)會因材質不同而 造成訊號的衰減，因此會造成斷線的狀態，或是行動客戶端為了節省電力的 消耗而進入睡眠模式(Doze mode) 也必須離線，如此經常性的斷線會造成通 訊上的困難，降低了資料通訊的效率。
(6) 移動式裝置在功能上的限制：由於移動式裝置在體積上的限制，必須讓使用 者能夠隨身攜帶，造成移動式裝置必須捨棄一些非必要的元件，因此在功能 上較一般的設備簡略，因此這些移動式裝置所能執行的工作也有所限制。
(7) 移動式的行動客戶端：傳統的客戶端是處於固定位置的狀態下，然而無線網 路的行動客戶端是可以處在移動式的狀態，由於單一行動支援裝置所能涵蓋 的蜂巢狀區域範圍有限，因此行動客戶端在通訊的過程中，若是跨越不同行 動支援裝置所涵蓋的蜂巢狀區域，則系統必須把行動客戶端由舊的行動支援 裝 置 再 連 接 至 新 的 行 動 支 援 裝 置 ， 這樣 的 過 程 稱 為 交 遞 管 理 （Handoff Management）。
由於使用無線通訊的行動計算環境的諸多特性，尤其是當大量的行動客戶端 在同個時間向伺服器端提出資料項的請求時，可能會造成伺服器端無法負荷所造 成的規模問題，因此為了有效解決行動客戶端的規模問題，我們利用資料廣播的 方法來解決。
第二節 資料廣播
由於無線通訊設備的基礎建設的普及與行動通訊業者在新世代無線網路整 合平台上所提供的加值服務日益增多的情況下，使用者可以利用無線通訊 (GPRS、3G 與 WI-FI 等技術)的傳輸模式，透過手持式行動裝置使用這些應用服 務的情況也會越來越普遍。而目前這些行動通訊業者所提供的應用服務中主要還 是以點對點的互動式的傳輸模式，也就是這些應用服務是由行動客戶端對伺服器 端發出請求，而伺服器端根據這些請求做出回應的模式，例如網路訂購電影票、
股市下單與網路銀行等線上互動式的網路加值服務。在現行許多的應用服務中，
有許多的應用服務是不需要以一對一互動式傳輸模式來達成服務行動客戶端的 應用服務，例如天氣資訊、股票資訊、地理資訊、交通資訊、新聞資訊等等，由 於這些應用服務所提供的資訊是一致的，再加上目前無線通訊的頻寬仍舊是相對 的較低，因此若此類應用服務以一對一的互動模式進行時，行動客戶端數量眾多 時，伺服器端可能會無法負荷外，也會造成頻寬的浪費嚴重影嚮系統的運作效 能，因此資料廣播的方式就被提出作為此類應用服務在行動用戶端數量規模問題 的解決辦法，如此廣播伺服器端就可以在同時間下服務大量的行動客戶端，也能 夠有效的利用無線通訊網路的頻寬，以滿足大量行動客戶端的需求。
一、資料廣播的模式
在 行 動 計 算 的 環 境 下 ， 資 料 廣 播 的 模 式 包 含 了 廣 播 模 式 (Broadcasting Mode)、需求模式(On-Demand Mode) [6,7]與混合模式(Mixture Mode) [8]三種資料 廣播的模式。
(一) 廣播模式
廣播模式又稱為推式(Push-based)的資料廣播模式，廣播伺服器端依照資料 項所排定的廣播時間，將資料項週期性地在廣播通道中使用廣播的方式來傳送資 料，當行動客戶端需要資料項時，嵌入到廣播通道中監聽廣播伺服器端所廣播的
資料項，直到行動客戶端擷取到所需的資料項之後才離開廣播通道。推式的廣播 模式適用在行動客戶端數量眾多的時候，能夠較有效率的滿足大多數行動客戶端 的需求，廣播伺服器端的系統效能也不會因為行動客戶端的數量而受到影響，使 得有限的頻寬在使用上更有效率。
(二) 需求模式
需求模式又稱為拉式(Pull-based)的資料廣播模式，是由行動客戶端利用上傳 通道對廣播伺服器端提出資料項的請求(Request)，廣播伺服器端再根據行動客戶 端的需求將所需的資料項加入到廣播排程中，使用廣播通道傳送給行動客戶端。
拉式的資料廣播模式較適用在行動客戶端數量較少的情況下，能夠較有效的滿足 行動客戶端的需求，並且能夠降低行動客戶端在廣播通道中監聽資料項的等待時 間。但此種資料廣播模式並不適合使用在行動客戶端數量眾多的時候，因為廣播 伺服器端會因行動客戶端提出資料項的請求數量過多，造成廣播伺服器無法負荷 的規模問題而影響到系統的運作效能。
(三) 混合模式
混合模式是整合上述兩種模式的資料廣播方法，廣播伺服器端提供了推式與 拉式的資料廣播方式，首先廣播伺服器端在廣播通道上廣播較熱門的資料項，行 動客戶端若發現所需的資料項並未在廣播通道中播送時，行動客戶端則可利用廣 播伺服器端所提供的backchannel[8](如圖 1-2 所示)提出資料項的請求，廣播伺服 器端再根據行動客戶端的需求將所需的資料項使用下傳的通道傳送給行動客戶 端，如此行動客戶端就可依其需求選擇拉式的資料廣播模式(主動地向廣播伺服 器端提出需求)或推式的資料廣播模式(被動地等待廣播伺服器端所廣播的資料 項)。
圖1-2 混合模式的資料廣播方式
為了解決在行動計算環境中非對稱式的傳輸環境問題，以及避免行動客戶端
的規模問題，因此本研究主要是採取推式的資料廣播模式，這樣不僅可以有效的 利用頻寬，並且不需要擔心行動客戶端規模問題所帶來的影響。
二、效能指標
除了規模性的問題之外，在行動計算環境中另一個重要的議題則是行動客戶
端上能源消耗的問題。由於行動客戶端上所使用的移動式通訊裝置電力有限，為 了減少能源的消耗，因此廣播伺服端會在廣播資料前，先廣播一個資料項的索 引，此索引中提供了各個資料項的廣播時間，當行動客戶端進入廣播通道中取得 索引資訊後，行動客戶端可以藉由索引的資訊得知所需資料項的廣播時間，此時 行動客戶端即可離開廣播通道，進入較為省電的睡眠模式(Doze Mode)中，在所 需的資料項廣播時恢復為活動模式(Active Mode)，進入廣播通道中擷取所需的資 料項。因此行動客戶端無需為了擔心錯失所需的資料項而一直處於耗電的活動模 式中監聽廣播通道，藉此降低監聽廣播通道的時間，減少行動客戶端電力的消耗 的問題 [6](行動客戶端在活動模式下所消耗的能源是處於睡眠模式下的 5000 倍 左右[6])。
圖1-3 Tuning Time 與 Latency Time
圖 1-3 是在[6]中 Imielinski 等學者提出 tune_opt 的資料廣播方法，主要在廣 播資料項的前端插入了一段引導行動客戶端取得資料項的索引資訊，利用索引的 方式引導行動客戶端取得所需的資料項。在資料廣播的環境中，我們使用調校時 間(Tuning Time)與延遲時間(Latency)[6]這兩項指標來衡量系統的效能。所謂調校 時間指的是行動客戶端擷取資料項的過程中，處在活動模式中的時間，也就是指 行動客戶端實際嵌入到廣播通道中擷取資料項所耗費的時間。而延遲時間則是指 行動客戶端完成擷取資料項整個過程所需的時間，主要由行動客戶端嵌入廣播通 道後到取得資料項索引的廣播時間稱為Probe wait 與從 probe wait 之後到擷取所 需的資料項為止的時間稱為Bcast wait，這兩項數據加總所得，如上圖 1-3 所示。
一個良好的資料廣播方法應該是行動客戶端消耗較少的能源(較小的調校時間) 與較短執行應用的反應時間(較短延遲時間)，完成資料項的擷取。
第三節 研究動機
在廣播伺服端主動廣播資料項的索引情形下，為了使此時間索引是有效的，
廣播伺服端必須在資料項進行廣播之前，明確的律定各個廣播資料項的廣播時 間。當廣播伺服端以廣播的方式傳遞最新狀態的資料給行動客戶端時(例如，在 某些軍事資訊系統中，指揮官需要立即將即時的戰情資訊傳遞給所有的作戰單 位)，由於各個資料項都需依循時間索引中所訂定的時間進行廣播，此時如果廣
播資料是來自一個無法確定延遲時間的資料來源時，可能會發生廣播時間已到，
但是資料尚未取得的問題，造成廣播資料項無法順利播出，行動客戶端也無法取 得所需的資料項的情況，則稱為資料遺失問題[9]。
在現今有關行動計算環境中資料廣播方法的研究中，僅有少數的論文對廣播 伺服器端進行資料廣播時的資料來源進行討論。在[6]中的廣播資料來自於某個 事先準備好的檔案中，而且這個檔案在廣播週期中是不允許被更新的，只有在廣 播週期與廣播週期之間才可以更新檔案中的資料。這個方式雖然使得資料廣播問 題得以簡化，但是卻不符合現實生活中的需求。第一、資料來源來自於檔案，實 際上與現今多數企業將資料儲存於資料庫的現實狀況並不吻合。顯然，資料是來 自於資料庫系統，相對於資料是來自檔案應該是比較合理的情形。第二、在某些 應用中(例如戰情資訊系統)，使用者需要最新的資料，資料在廣播週期結束後才 能更新廣播資料，可能不符合使用者的需求。因此，一個能夠提供使用者最新狀 態資料的資料廣播資料來源，應該為廣播資料來自資料庫系統。同時，當廣播伺 服端根據時間索引上所規劃的時間進行資料廣播時，廣播伺服器端會到資料庫中 擷取廣播資料的內容，並於取得內容後進行廣播。在此種情形之下，廣播伺服端 可以取得最新狀態的資料進行廣播，滿足使用者需求。然而，在資料來源為資料 庫系統時，資料遺失問題就有很大的可能會發生。主要的因素為資料庫系統執行 查詢的反應時間是不確定性的(non-deterministic)。特別是，資料庫進行並行控制 時所造成的延遲時間與資料庫系統透過作業系統向磁碟機讀取資料區塊所使用 的磁碟存取時間[10]。
為解決資料遺失問題，在[9]中已提出兩個修正資料廣播方法的方式為重取 資料與新增遺失區段，來修正現有的資料廣播方法(latency_opt、tune_opt 與(1, m) indexing [6])，使得這些已經存在的資料廣播方法，得以適應資料遺失問題。根 據[9]所修正後的資料廣播方法進行效能評估的實驗結果顯示，以新增遺失區段 方法修正的資料廣播方法，在延遲時間上優於相對應的以重取資料修正的資料廣 播方法；但是在調校時間上，除了latency_opt 之外 tune_opt 與(1, m) indexing 都
是以重取資料方式進行修正的資料廣播方法優於相對應以新增遺失區段進行修 正的資料廣播方法。因此我們認為以新增遺失區段方式所修正的資料廣播方法在 調校時間上還有改進的空間，所以我們希望重新提出一個修正方式，並使用此修 正方式修正現有的資料廣播方法。我們希望這些修正後的資料廣播方法在調校時 間上能夠接近相對以重取資料方式進行修正的資料廣播方法。
我們也在[16]中提出改進新增遺失區段方式所修正的資料廣播方法，在經過 系統模擬與效能分析之後，我們發現在調校時間上，使用改進新增遺失區段方式 所修正的資料廣播方法的確是有所降低，但是在預期中也會降低的延遲時間上卻 有不降反增的現象，所以實驗後的結果顯示使用改進新增遺失區段方式修正的資 料廣播方法並未明顯優於使用新增遺失區段方式所修正的資料廣播方法。因此本 論文延續[16]中的研究，再提出一個新的改良方式為新增有序遺失區段方式，用 來修正現有的資料廣播方法，我們希望使用新增有序遺失區段方式所修正的資料 廣播方法，在延遲時間上能夠優於相對我們在[16]中所提出改進新增遺失區段方 式所修正的資料廣播方法。
第四節 論文架構
本論文架構如下：在第二章我們對相關研究進行討論並簡介索引樹、廣播磁 碟、基本的資料廣播方法與解決資料遺失問題的資料廣播方法；在第三章中說明 以新增有序遺失區段方式修正的資料廣播方法；第四章是實驗分析，說明實驗參 數設定與整個實驗過程，以系統模擬進行效能評估並分析結果；第五章是我們的 結論。
第二章 相關研究
過去針對行動計算環境中進行資料廣播的研究，已經有許多學者投入此方面 的研究。在[6,7,11]中，美國 Rutgers 大學的學者 Imielinski 首先提出 Selective Tuning Approach，探討如何利用索引的方式減少行動客戶端在擷取廣播資料時在 能源上的消耗問題，另一些相關的研究則是討論在資料進行廣播時，行動客戶端 與廣播伺服器端之間通訊失效時的議題，在[12]中，新加坡大學的 Tan 與 Ooi 修 正現有Selective Tuning Approach 中的方法，使得通訊失誤發生於行動客戶端進 行索引探查或是擷取資料項的過程時，行動客戶端仍能取得所需的資料項。在[13]
中，Leong 與 Si 這兩位學者的作法是使用多個廣播通道(Multiple channel)廣播資 料項，在這個研究中，作者將所有廣播資料項分成數個等份，而廣播伺服器端在 同一時間分別在不同的廣播通道中，廣播不同部分的廣播資料項。當行動客戶端 在某個廣播通道中無法取得所需的資料項時，行動客戶端就轉換到另一個廣播通 道中擷取資料項，藉此避免當某個廣播通道發生通訊失敗時，行動客戶端的應用 程式無法執行的窘境發生。相較我們所做的研究與過去學者所做的研究，不同的 是我們的研究主要是處理在廣播伺服器端上所發生的資料遺失問題，而過去的研 究則是處理行動客戶端與廣播伺服端之間的通訊問題。在有關行動計算環境中使 用資料廣播方法的相關研究中，在[9]首先提出資料遺失問題。在此篇文章中，
對資料遺失問題做了定義，並針對資料遺失問題提出重取資料與新增遺失區段兩 種方式來修正現有的資料廣播方法，以解決資料遺失的問題。
第一節 資料廣播環境
在過去固接式有線網路的通訊環境中，大多數是屬於Client/Sever 的網路架 構，由Client 端對 Server 端提出請求，Server 端再對 Client 端的要求做出回應，
而在行動計算的環境中，同樣存在著相同的網路架構，稱為點對點(Point-to-Point)
網路架構，行動客戶端對伺服器端提出要求，而伺服器端根據行動客戶端要求將 所需的資料項傳送給行動客戶端，如果同時另一個行動客戶端又對同一個資料項 提出要求，而伺服器端還是必須將這個資料項傳送給另一個行動客戶端，因此伺 服器端不斷地在有限的頻寬下傳送相同的資料項，將會造成通訊頻寬的浪費，再 加上行動計算環境中許多的限制，例如行動計算環境中，無線網路有限的頻寬和 伺服器端下載的頻寬遠大於行動客戶端上傳的頻寬，而且單一伺服器可能面臨必 須服務大量的行動客戶端，因此為了善用行動計算環境中有限的頻寬，並且解決 行動客戶端規模問題，所以在[14]中，作者提出了一個廣播磁碟(Broadcast Disk) 的架構(如下圖 2-1 所示)，也就是資料廣播的架構，資料廣播是利用一個共同的 廣播通道來傳送行動客戶端所需資料項，廣播的資料項在廣播通道上週而復始的 播送就像是在一個磁碟上持續的運轉，由廣播伺服器端負責廣播資料項，而行動 客戶端則到廣播通道中擷取資料項，在不同的廣播通道上資料項經由廣播排程會 呈現不同的廣播結構，較密集播放的資料項屬於較熱門的資訊，可視為轉動較快 的磁碟上運轉，這些資料項就會被廣播較多的次數。
圖2-1 廣播磁碟的架構
資料廣播的環境特性如下：
(1) 採用一共同的廣播通道來傳送資料項，當行動客戶端需要資料項時，便會到 這個共同的廣播通道中來擷取資料項，因此在頻寬的使用上會更有效率。
(2) 廣播伺服器端允許大量的行動客戶端同時存取資料，廣播伺服器端的效能不 會因為行動客戶端數量的增加而有所影響。
(3) 由於行動客戶端不需要傳送資料項的請求，因此也能夠節省行動客戶端能源 的消耗。
由於行動客戶端在睡眠模式下會以較省電的方式在運作，而在活動模式中則
是比較耗費電力的，當行動客戶端為了取得需要的資料項時，行動客戶端必須在 廣播通道中持續的監聽廣播伺服器端所廣播的資料項是否為所需的資料項，因此 行動客戶端處在活動模式的時間較長，會消耗大量的能源。為了解決這個問題，
我們使用索引的技術來降低行動客戶端處於活動模式的時間，減少行動客戶端在 擷取資料項的過程中所消耗的電力，達到降低調校時間的效果。
第二節 索引結構
在行動計算的環境中，行動裝置的電力來源絕大多數是以電池來維持，因此 如何有效的節省能源的消耗是很重要的議題，節省能源消耗的方式有很多，目前 最有效節省能源消耗的方式是使用索引技術，因此有許多研究[6,7,12]利用樹狀 的結構運用在索引的技術上，例如使用索引樹(Index tree)的架構來加以改變廣播 排程的結構，在廣播資料項的同時，也廣播相關資料項的索引資訊，因此廣播伺 服器端將依照廣播排程將索引與資料項依序的廣播。在此種廣播結構下行動客戶 端若要擷取資料項時，必須先進入廣播通道中取得索引，利用索引的資訊來判斷 廣播伺服器端播放所需資料項的時間，在等待資料項廣播的這段期間，行動客戶 端可以進入睡眠模式以減少能源的消耗，而不需持續的待在廣播通道中，只要依
照索引的資訊等到所需的資料項廣播時，再恢復成活動模式進入廣播通道中擷取 所需的資料項，如此就能夠有效達到節省能源的消耗。
R
4 6
13 15
25 27 16
18 19 21 7
9 10 12
22 24 1
3
31 33
40 42
52 54 43
45 46 48 34
36 37 39
49 51 28
30
58 60 55 57 C6
61 63
73 75 64
66 67 69
70 72
79 81 76 78 C7 C8 C9
C4 C5 C3 C2
C1 C10C11C12C13C14C15C16C17C18C19C20C21C22C23C24 C25C26C27
B1 B2 B3 B4 B5 B6 B7 B8 B9
A1 A2 A3
圖2-2 樹狀的廣播結構
上圖 2-2 是一個樹狀的廣播結構，索引是以樹狀的架構所構成，索引樹的最 下層為廣播的資料項，資料項的上層為相關的索引，每個資料項或索引都視為一 個相同大小的bucket。在樹狀的廣播結構為基礎的資料擷取方式為行動客戶端必 須先取得根索引(root)，取得根索引後，依據索引的資訊與所需的資料項做判斷，
決定下一個要擷取的索引為何，依照上述的方式反覆地執行相同的步驟，直到行 動客戶端取得需要的資料項。
在資料廣播環境中，廣播伺服器端在產生一個廣播週期的排程中，為了使所 有的 bucket 能夠辦別並且讓行動客戶端辨識廣播週期的架構，因此每個 bucket 都會加入以下的表頭(Header)資訊(如表 2-1 所示)。
表2-1 bucket 的表頭資訊
Bucket_ID 表示此bucket 距離廣播週期起點的位移(Offset)。
Bcast_pointer 表示此bucket 距離下一個廣播週期起點的位移。
Index_ pointer 表示此bucket 距離下一個 index segment 起點的位移。
Bucket_type 表示此bucket 是屬於 index bucket 或 data bucket。
為了讓行動客戶端可以順利地取得所需的資料項，index bucket 必須能夠引 導行動客戶端一步一步的拿到所需的資料項，因此在廣播結構中的index bucket 會由一連串包含著引導的資訊(attribute_value,offset)[6]所組成。attribute_value 是 用來判斷資料項的依據，當客戶端使用該索引時，根據行動客戶端所需要的資料 項與 attribute_value 作來判斷，下一個該取得那一個 bucket，而下一個要取得的 bucket 可能是 index bucket 也可能是 data bucket。offset 則是用來告知客戶端下一 個要取得的 bucket 距離廣播週期起點的位移，所以當行動客戶端取得 index bucket 之後，利用 attribute_value 與所需要的資料項做判斷，再透過 offset 就能 取得下一個相關的index bucket 或是 data bucket。
圖2-3 索引節點的 Attribute_value
如圖 2-3 是由 81 個資料項所構成的樹狀的索引結構，索引樹的分支度為 3，
所以每個索引上都有3 個 attribute_value 作為判斷的依據，由根索引(R)開始由上 而下的擷取方式，如果所需要的資料項是小於28，則往 A1 索引節點；如果所需 要的資料項大於等於28 且小於 55，則往 A2 索引節點；如果所需要的資料項大 於等於55 則往 A3 索引節點；以此類推利用 attribute_value 來判斷下一個所要擷 取的索引節點，最後即可取得所需的資料項。
例如所需的資料項為 48，由根索引的 attribute_value(1,28,55)開始做判斷，
48 介於 28 至 55 之間，則往 A2 索引節點，再根據 A2 的 attribute_value(28,37,46)
做判斷，48 大於 46，則往 B6 索引節點，再根據 B6 的 attribute_value(46,49,52) 做判斷，48 介於 46 至 49 之間，則往 C16 索引節點，再根據 C16 所包含 offset 值的做判斷就可以取得資料項48。
因此行動客戶端整個擷取資料項的流程為：R→A2→B6→C16→48
由於樹狀的索引結構是一個二維的架構，為了能夠在廣播通道中依序的將資
料項發送，因此我們需要一個一維架構的廣播排程來將樹狀的索引結構轉換成一 維的架構，以便在廣播頻道中依序的廣播資料項。下圖2-4 為樹狀的廣播結構，
共有9 個資料項，分支度為 3，因此需要 2 個階層共 4 個索引節點，我們根據[6,7]
所提出Tune_opt 的廣播結構，將下圖 2-4 的樹狀的廣播結構轉換成 Tune_opt 的 廣播結構，將所有的索引節點由根索引開始由上而下由左至右依序的插入到資料 項的前端(如圖 2-5 所示)，如此就能透過廣播通道來傳送資料項。圖 2-5 中根索 引R 下方所連接的表格資訊表示根索引 R 所包含的表頭資訊，索引 I3 下方所連 接的表格資訊表示索引I3 所包含的表頭資訊，資料項 D7 下方所連接的表格資訊 則表示資料項D7 所包含的表頭資訊。
I1 I2 I3
R
D2 D3 D4 D5 D6
D1 D7 D8 D9
圖2-4 樹狀的廣播結構
圖2-5 Tune_opt 的廣播結構
由於資料項的索引是一種樹狀結構，此種廣播結構能讓行動客戶端只需取得 相關的索引資訊，而不需要取得所有的索引資訊，即可以取得所需的資料項，對 於廣播排程加入索引資訊後，行動客戶端擷取資料項的程序如下：
(1) 行動客戶端嵌入廣播通道中，必須先擷取到任意一個完整的 bucket。
(2) 利用此 bucket 的表頭欄位中 index pointer 的資訊，行動客戶端可以知道下一 個索引區段起點的位移，因此行動客戶端就可離開廣播通道進入睡眠模式，
等到下一個索引區段廣播時，行動客戶端再恢復到活動模式再進入到廣播通 道中讀取索引區段的資訊。
(3) 行動客戶端取得根索引的資訊後，便可以判斷下一個所需要取得的是 index bucket 或 data bucket，再透過位移即可得知下一個要擷取的 bucket 何時會播 出，然後行動客戶端可再進入睡眠模式，等待所需要的bucket 由廣播伺服器 端播出時，再進入廣播通道中擷取bucket，若再取得的 bucket 是 index bucket 的話，則回到第2 步驟繼續執行。若取得的 bucket 為行動客戶端所要的資料 項，則完成整個資料項的擷取程序。
第三節 現存的資料廣播的方法
在資料廣播研究的領域中，主要的研究方向是如何有效的降低延遲時間與減 少行動客戶端能源消耗的議題上，目前已有許多學者提出多種有效的資料廣播方 法，而其中在[6,7]所提出的廣播架構是最基本的資料廣播方法。由 T. Imielinski 等學者所提出在行動計算廣播環境中，為了使行動客戶端能減少其行動裝置上能 源消耗，因此建構一個廣播資料項的樹狀索引架構，廣播伺服端再根據樹狀的廣 播結構來廣播資料項。圖2-6、2-7、2-8 中，展示了 latency_opt、tune_opt 與(1, m) indexing 三種資料廣播方法的廣播結構。在廣播結構中最小廣播單位為稱為 bucket[6]，而 bucket 的內容可能是資料項或是索引，由於 bucket 的大小是相同，
因此可以使用 bucket 作為衡量時間的單位。此外我們將同性質的 bucket 聚集起 來稱之為區段（Segment）。一個廣播結構包含了多個區段，而每個區段由多個 bucket 所組成。由包含廣播資料項的 bucket 所組成的區段，稱之為資料區段（Data Segment）。由包含索引資訊的 bucket 所組成的區段，稱之為索引區段（Index Segment），將所有的索引區段置入所有相對應的資料區段之前，即構成一個廣播 週期(Broadcast Cycle)。
圖2-6 Latency_opt 的廣播結構
在latency_opt 廣播方法中(如圖 2-6 所示)，由於並未使用索引方式，廣播伺 服器端只將資料項依據廣播排程播送資料項，因此行動客戶端為了取得所需的資 料項，必須一直處於活動模式中監聽廣播通道，直到取得所需的資料項，因此行 動客戶端在等待資料項廣播過程中會消耗大量的能源，造成 latency_opt 廣播方 法的調校時間過長的現象。
圖2-7 Tune_opt 的廣播結構
為了降低 latency_opt 資料廣播方法的調校時間，Imielinski 等學者提出 tune_opt 的資料廣播方法(如圖 2-7 所示)。Tune_opt 資料廣播方法主要是在資料 區段的最前端插入了一段引導的索引區段，利用索引的方式來導引行動客戶端取 得所需的資料項，因此行動客戶端能夠藉此降低處於活動模式下監聽廣播通道的 時間，有效的降低了調校時間。但是也由於加入了索引的因素，行動客戶端的擷 取程序就必須透過索引之後才能夠取得所需的資料項，所以tune_opt 的資料廣播 方法強迫行動客戶端必須等到下一個廣播週期才能取得所需的資料項，因此造成 tune_opt 資料廣播方法相對於 latency_opt 資料廣播方法會有較長的延遲時間。
圖2-8 (1, m) indexing, m=3 的廣播結構
為了平衡 latency_opt 與 tune_opt 資料廣播方法的延遲時間與調校時間，
Imielinski 等學者再提出(1, m) indexing 資料廣播方法(如圖 2-8 所示)。(1, m) indexing 資料廣播方法是將索引區段複製成數個的複本，均勻的插入資料區段 中，透過多重索引的方式使得行動客戶端可以儘早取得索引資訊，無需等到下一 個廣播週期，因此行動客戶端有機會於它首次嵌入到廣播通道的時間與下個廣播 週期開始的區間中取得所需的資料項。由於(1, m) indexing 資料廣播方法的延遲 時間與調校時間是最能被接受的，因此有許多的學者致力於改進(1, m) indexing 資料廣播方法的效能。例如，在[7]中作者使用分散式索引的方式使得延遲時間
為最低。(1, m) indexing 資料廣播方法在[6]中提到 m 值的最佳化如下所示：
m ＝
Index Data
Data 為廣播週期中 data bucket 的數量，Index 為索引區段中 index bucket 的數量。
第四節 現存解決資料遺失問題的資料廣播方法
為了要解決資料遺失問題，在[9]中提出了兩個方式(Approach)，分別稱為重 取 資 料 方 式(Reaccess approach) 與 新 增 遺 失 區 段 方 式 (Add-missing segment approach)，並用來修正原有的三個資料廣播方法－latency_opt、tune_opt 與(1, m) indexing，藉此解決資料遺失問題。對於以重取資料方式所修正的資料廣播方法，
分別稱為latency_opt-RA、tune_opt-RA 與(1, m) indexing-RA 資料廣播方法，而 經過新增遺失區段方式所修正的資料廣播方法，分別稱為 latency_opt-AM、
tune_opt-AM 與(1, m) indexing-AM。
一、重取資料方式
重取資料方式並未更改原有的廣播結構，只透過行動客戶端的擷取程序的改 變，即可解決資料遺失問題。主要的作法是當行動客戶端發現在擷取資料項的過 程中發生資料遺失時，行動客戶端就到下個廣播週期，重新擷取所需的資料項。
下面將介紹使用重取資料方式所修正的資料廣播方法，分別從廣播伺服器端的廣 播結構(Broadcast structure)與行動客戶端的擷取程序(Access procedure)來做說 明。
(一) Latency_opt-RA 資料廣播方法
latency_opt-RA 的廣播結構與 latency_opt 的廣播結構相同(如圖 2-9 所示)。
如果資料項正常播送時，行動客戶端會在他當前所嵌入的廣播週期中或是下個廣 播週期中取得所需的資料。當發生資料遺失時，行動客戶端會試著再從下ㄧ個廣
播週期中重新擷取所需的資料。
圖2-9 Latency_opt-RA 的廣播結構 Latency_opt-RA 的擷取程序則如下所示：
(1) 行動客戶端嵌入(tune in)到廣播通道中，持續的待在廣播通道中監聽廣播資料 項，直到廣播伺服器端廣播所需的資料項。
(2) 行動客戶端擷取所需資料項；如果成功取得所需資料項，結束這個程序；否 則，持續的監聽廣播通道，直到下個廣播周期重新擷取所需的資料項。
(二) Tune_opt-RA 資料廣播方法
Tune_opt-RA 的廣播結構與 tune_opt 的廣播結構相同(如圖 2-10 所示)。
Tune_opt-RA 資料廣播方法主要是利用索引的方式來導引行動客戶端取得所需 的資料項，如果行動客戶端發現在擷取資料項的過程中發生資料遺失時，行動客 戶端就必須到下個廣播週期重新擷取所需的資料項。
圖2-10 Tune_opt-RA 的廣播結構 Tune_opt-RA 的擷取程序如下所示：
(1) 行動客戶端嵌入到廣播通道中，擷取一個完整的 bucket，從所擷取的 bucket 中取得下一個廣播週期索引區段的廣播時間。
(2) 行動客戶端進入睡眠模式，在下一個廣播週期的索引區段廣播時恢復為活動 模式再嵌入廣播通道中。
(3) 從索引區段中取得所需資料項的廣播時間。
(4) 行動客戶端再一次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌 入廣播通道中。
(5) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，回到步 驟4 繼續執行從下個廣播週期中擷取所需資料項。
(三) (1, m) indexing-RA 資料廣播方法
(1, m) indexing-RA 的廣播結構與(1, m) indexing 的廣播結構相同(如圖 2-11 所示)。(1, m) indexing-RA 資料廣播方法是利用多重索引的方式來讓行動客戶端 可以更快的取得所需的資料項，但如果發生資料遺失時，行動客戶端則必須到下 個廣播週期重新擷取所需的資料項。
圖2-11 (1, m) indexing-RA , m=3 的廣播結構 (1, m) indexing-RA 的擷取程序如下所示：
(1) 行動客戶端嵌入到廣播通道中，擷取一個完整的 bucket，從所擷取的 bucket 中取得下一個索引區段的廣播時間。
(2) 行動客戶端進入睡眠模式，在下一個索引區段廣播時恢復為活動模式再嵌入 廣播通道中。
(3) 從索引區段中取得所需資料項的廣播時間。
(4) 行動客戶端再一次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌 入廣播通道中。
(5) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，回到步 驟4 繼續執行從下個廣播週期中擷取所需資料項。
二、新增遺失區段方式
新增遺失區段方式是廣播伺服端將遺失資料索引區段(Missing data index segment)與遺失資料區段(Missing data segment)加在現有廣播結構的後端，當廣播 伺服端在資料區段廣播資料的過程中，如果發生資料遺失時，廣播伺服端會在當 週期的遺失資料區段中重新廣播遺失的資料項。如果行動客戶端在擷取資料項的 過程中發現它所需要的資料項在資料區段中發生資料遺失時，行動客戶端就可以 透過遺失資料索引在遺失資料區段中取得所需的資料項，如果所需的資料項仍然 無法於資料遺失區段中取得，則行動客戶端將會在下個廣播週期，重新擷取所需 資料項。在新增遺失區段方式所修正的資料廣播方法中，為了讓行動客戶端透過 遺失資料索引的引導在遺失資料區段中順利取得資料項，我們必須在 bucket 原 有的表頭資訊中(bucket_id、bcast_pointer、index_ pointer、bucket_type)還要另外 新增一個欄位資訊為Miss_index_pointer 表示此 bucket 距離遺失資料索引區段起 點的位移。下面將介紹使用新增遺失區段方式所修正的資料廣播方法，分別從廣 播伺服器端的廣播結構與行動客戶端的擷取程序來做說明。
(一) Latency_opt-AM 資料廣播方法
Latency_opt-AM 的廣播結構(如圖 2-12 所示)，它是將 latency_opt 的廣播結 構的尾端加入一個遺失資料區段。當廣播資料項在資料區段中發生資料遺失時，
廣播伺服端會在遺失資料區段中重新廣播遺失的資料項。由於新增遺失區段的方 式變更了原有的廣播結構，使得行動客戶端能夠在他當前所嵌入廣播週期中取得 所需的資料項的機率將會有所提高，如此就能夠降低行動客戶端擷取資料項的延 遲時間與調校時間。
圖2-12 Latency_opt-AM 的廣播結構 Latency_opt-AM 的擷取程序如下所示：
(1) 行動客戶端嵌入到廣播通道中，持續的在廣播通道中監聽廣播資料項，直到 廣播伺服器廣播所需的資料項。
(2) 行動客戶端擷取所需資料項；如果成功取得所需資料項，結束這個程序；否 則，持續的監聽廣播通道，直到廣播伺服器端在遺失資料區段中重新廣播遺 失的資料項。
(3) 行動客戶端從遺失資料區段中擷取所需資料項；如果成功取得所需資料項，
結束這個程序；否則，持續的監聽廣播通道，到下個廣播週期中擷取所需資 料項。
(二) Tune_opt-AM 資料廣播方法
Tune_opt-AM 方法的廣播結構(如圖 2-13 所示)是將 tune_opt 方法的廣播結構 的尾端加入一個遺失資料索引區段與一個遺失資料區段。當廣播伺服器端發生資 料遺失時，由於tune_opt-RA 的擷取程序必須到下個廣播週期才能取得所需資料 項，因此造成延遲時間過長的現象，但是tune_opt-AM 的資料廣播方法解決了這 個問題，使得行動客戶端無須等到下一個廣播週期才能取得所需的資料項，主要 是因為廣播伺服端會在遺失資料區段中重新廣播遺失的資料項，使得行動客戶端 可透過遺失資料索引在遺失資料區段中取得所需的資料項。除此之外，行動客戶 端也能夠透過遺失資料索引來判斷是否有所需的資料項在遺失資料區段中重新 廣播，使得行動客戶端能夠提高在它當前所嵌入廣播週期中取得資料項的機率。
所以 tune_opt-AM 的資料廣播方法除了可以透過資料項的索引在資料區段中取 得所需的資料項，還可利用遺失資料項的索引在遺失資料區段中取得所需的資料 項。
: : : :
圖2-13 Tune_opt-AM 的廣播結構
當行動客戶端需要擷取資料項時，它首先到廣播通道中擷取一個完整的 bucket，藉此取得索引區段或遺失資料索引區段的廣播時間。由於 tune_opt-AM 的資料廣播方法的擷取程序必須透過取得索引的資訊後才能擷取到所需的資料 項，因此必須到下一個廣播週期才能取得所需的資料，但如果行動客戶端先取得 遺失資料索引區段(如下圖 2-14(b))，這表示行動客戶端仍有機會在當週期的遺失 資料區段中取得它所需的資料。在此時，行動客戶端根據程序 A 取得所需的資 料項。另一方面，如果行動客戶端先取得索引區段(如下圖 2-14(a))，這表示行動 客戶端就必須到下個廣播週期來擷取資料項，此時，行動客戶端使用程序 B 擷 取所需的資料項。
圖2-14 Tune_opt-AM 的擷取程序
Tune_opt-AM 的擷取程序如下所示：
程序A：從遺失資料區段中擷取資料項
(1) 行動客戶端進入睡眠模式，直到遺失資料索引區段廣播時恢復為活動模式再 嵌入到廣播通道中。
(2) 從遺失資料索引區段中判斷所需的資料項是否在遺失資料區段中再次廣播，
如果是則取得所需資料項的廣播時間，否則，直接跳到步驟5 繼續進行。
(3) 行動客戶端再次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌入 到廣播通道中。
(4) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，根據下 列程序繼續執行。
(5) 行動客戶端進入睡眠模式，直到下一個廣播週期的索引區段廣播時恢復為活 動模式再嵌入到廣播通道中。
(6) 從索引區段中，取得所需資料項的廣播時間。
(7) 行動客戶端再一次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌 入到廣播通道中。
(8) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，回到步 驟1 繼續執行。
程序B：從下一個廣播週期中擷取資料項
(1) 行動客戶端進入睡眠模式，直到下個廣播週期的索引區段廣播時恢復為活動 模式再嵌入到廣播通道中。
(2) 從索引區段中，取得所需資料項的廣播時間。
(3) 行動客戶端再次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌入 到廣播通道中。
(4) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，根據下 列程序繼續執行。
(5) 行動客戶端再次進入睡眠模式，直到遺失資料索引區段廣播時恢復為活動模 式再嵌入到廣播通道中。
(6) 從遺失資料索引區段中判斷所需的資料項是否在遺失資料區段中再次廣播，
如果是則取得所需資料項在遺失資料區段的廣播時間，否則，回到步驟1 繼 續進行。
(7) 行動客戶端再一次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌 入到廣播通道中。
(8) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，回到步 驟1 繼續執行。
(三) (1, m) indexing-AM 資料廣播方法
(1, m) indexing-AM 方法的廣播結構(如圖 2-15 所示)，同樣地它是將(1, m) indexing 方法的廣播結構的尾端加入一個遺失資料索引區段與一個遺失資料區 段。由於(1, m) indexing 的資料廣播方法本來就能夠有效的降低行動客戶端擷取 資料項的延遲時間與調校時間，再加上新增遺失區段的方式更能夠有效的解決資 料遺失問題。
圖2-15 (1, m) indexing-AM, m=3 的廣播結構
當行動客戶端需要擷取資料項時，它首先嵌入到廣播通道中擷取一個完整的
bucket，藉此取得下一個索引區段或遺失資料索引區段的廣播時間。如果行動客 戶端先取得下一個遺失資料索引區段(如下圖 2-16(a))，這表示行動客戶端已經無 法於廣播週期的資料區段中取得所需要的資料項，然而，它仍然有機會在廣播週 期的遺失資料區段中取得它所需的資料。在此時，行動客戶端根據程序 A 取得 所需的資料項。另一方面，如果行動客戶端先取得下一個索引區段(如下圖 2-16(b))，這表示行動客戶端有機會於下一個資料區段取得所需要的資料項，行 動客戶端在下一個索引區段中擷取所需資料項的廣播時間，行動客戶端會先判斷 所需的資料項是否已經被廣播，如果這個資料項還沒有被廣播的話，行動客戶端 使用程序 B 下載所需的資料項，如果這個資料項已廣播過，行動客戶端並非要 到下個廣播週期才能取得所需資料項，行動客戶端仍有機會在廣播週期的遺失資 料區段中取得所需的資料項，因此行動客戶端使用程序 A 繼續下載所需的資料 項。
圖2-16 (1, m) indexing-AM 的擷取程序 (1, m) indexing-AM 的擷取程序如下所示：
程序A：從遺失資料區段中擷取資料項
(1) 行動客戶端進入睡眠模式，直到遺失資料索引區段廣播時恢復為活動模式再 嵌入到廣播通道中。
(2) 從遺失資料索引區段中判斷所需的資料項是否在遺失資料區段中再次廣播，
如果是則取得所需資料項的廣播時間，否則，直接跳到步驟5 開始進行。
(3) 行動客戶端再次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌入 到廣播通道中。
(4) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，根據下 列程序繼續執行。
(5) 行動客戶端進入睡眠模式，直到下一個廣播週期的索引區段廣播時恢復為活 動模式再嵌入到廣播通道中。
(6) 從索引區段中，取得所需資料項的廣播時間。
(7) 行動客戶端再一次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌 入到廣播通道中。
(8) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，回到步 驟1 繼續執行。
程序B：從下一個資料區段中擷取資料項
(1) 行動客戶端進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌入到廣 播通道中。
(2) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，根據下 列程序繼續執行。
(3) 行動客戶端進入睡眠模式，直到遺失資料索引區段廣播時恢復為活動模式再 嵌入到廣播通道中。
(4) 從遺失資料索引區段中判斷所需的資料項是否在遺失資料區段中再次廣播，
如果是則取得所需資料項在遺失資料區段的廣播時間，否則，回到步驟1 繼 續進行。
(5) 行動客戶端再一次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌 入到廣播通道中。
(6) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，回到步 驟1 繼續執行。
三、改進新增遺失區段方式
為了降低行動客戶端擷取資料項的調校時間，因此我們在[16]中重新設計一 個改進新增遺失區段方式(Improved add-missing segment approach)，並使用此修 正方式修正現有的資料廣播方法。我們希望這些改進新增遺失區段方式所修正的 資料廣播方法，在調挍時間上也能夠有效的降低。
改進新增遺失區段方式是當發生資料遺失時，行動客戶端無須透過遺失資料 索引則可在遺失資料區段中取得所需的資料項。改進新增遺失區段是依照新增遺 失區段方式原有的廣播結構，但不需加入遺失資料索引區段，廣播伺服器端只需 將遺失資料區段加在現有廣播結構的尾端。由於改進新增遺失區段方式的資料廣 播方法有效的減少了廣播結構中索引區段的大小，因此整個廣播週期也跟著縮 短，所以我們認為改進新增遺失區段方式所修正的資料廣播方法在延遲時間上應 該比新增遺失區段方式所修正的資料廣播方法來的小，除此之外當發生資料遺失 問題時，行動客戶端可以不必透過遺失資料索引的方式就可以直接到遺失資料區 段中取得所需的資料項，因此以改進新增遺失區段方式所修正的資料廣播方法在 調校時間上更可以有效的降低。
當廣播伺服端在廣播資料的過程中發生資料遺失時，廣播伺服端將會紀錄下 成對記錄（bucket_ID , i），其中 bucket_ID 為發生資料遺失資料項在廣播週期中 的編號，i 值為該資料項是廣播週期中第 i 個發生資料遺失的資料項。同時廣播 伺服端會在原本準備廣播資料項的bucket 中，放入代表發生資料遺失的旗標與 i 值，並播送出去。當廣播伺服端廣播在遺失資料區段時，如果遺失資料項為該廣
播週期中第i 個發生資料遺失的資料項，此時廣播伺服端將會在遺失資料區段中 第i 個 bucket，重新廣播此資料項。當行動客戶端在擷取資料項的過程中發現所 擷取的bucket 中並未存在所需的資料項，而是存在表示資料遺失的旗標與 i 值，
此時行動客戶端就可直接到遺失資料區段中的第i 個 bucket 重新擷取資料項，如 果此資料項仍然無法於遺失資料區段中取得，則行動客戶端將會到下個廣播週 期，重新擷取所需的資料項。
我們首先介紹廣播伺服端如何維護在資料區段中發生資料遺失的資料項 是廣播週期中第幾個發生資料遺失的資料項。當廣播伺服器端開始廣播資料時，
廣播伺服器端會額外維護一個計數器（Counter），這個計數器的數值在每個廣播 週期重新開始時，將會被廣播伺服器端設為1，當廣播伺服器端在資料項的廣播 過程中發生資料遺失時，廣播伺服器端會立刻將代表資料遺失發生的旗標與計數 器中的數值放到發生資料遺失的bucket 中，並立即廣播此 bucket，接著廣播伺服 端會將計數器中的數值加1。如過在同一個廣播週期中再次發生資料遺失時，則 重複以上的步驟。
由於改進新增遺失區段方式主要是針對 Tune_opt-AM 與(1, m) indexing-AM 這兩個資料廣播方法作改良，並且Latency_opt 的廣播結構並未包含索引，因此 改進新增遺失區段方式的資料廣播方法就不適用於 Latency_opt-AM 中。對於使 用新增有序遺失區段方式的修正的tune_opt 和(1, m) indexing 的資料廣播方法，
我們在原有資料廣播方法名稱的尾端加入IAM 來命名，其名稱為 tune_opt-IAM 和(1, m) indexing-IAM。此外為了要讓行動客戶端直接到遺失資料區段中順利取 得資料項，我們在 bucket 原有的表頭資訊中(bucket_ID、bcast_pointer、index_
pointer、bucket_type)另外新增一個欄位資訊為 Miss_data_pointer 表示此 bucket 距離遺失資料區段起點的位移。下面將介紹使用改進新增遺失區段方式所修正的 資料廣播方法，分別從廣播伺服器端的廣播結構與行動客戶端的擷取程序來做說 明。
(一) Tune_opt-IAM 資料廣播方法
Tune_opt-IAM 方法的廣播結構(如圖 2-17 所示)，它是將 tune_opt-AM 方法 的廣播結構中遺失資料索引區段刪除只留下遺失資料區段。由於改良後的資料廣 播方法使用旗標與計數器的方法，廣播伺服器端會在廣播週期中依照資料項遺失 的順序，將遺失資料項在遺失資料區段中依序的重新廣播，對行動客戶端而言，
當資料遺失問題發生時，行動客戶端可以不必透過遺失資料索引的引導就可以直 接到遺失資料區段中取得所需的資料項。
圖2-17 Tune_opt-IAM 的廣播結構 Tune_opt-IAM 的擷取程序：
(1) 行動客戶端嵌入廣播通道並擷取一個完整的 bucket，藉此取得下一個廣播週 期索引區段的廣播時間。
(2) 行動客戶端進入睡眠模式，直到下一個廣播週期索引區段廣播時恢復為活動 模式再嵌入到廣播通道中。
(3) 從索引區段中，取得所需資料項的廣播時間。
(4) 行動客戶端再次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌入 到廣播通道中。
(5) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，行動客 戶端將會由bucket 中得知，遺失資料項將會在遺失資料區段中第 i 個 bucket 重新廣播，根據下列程序繼續執行。
(6) 行動客戶端進入睡眠模式，直到所需資料項在遺失資料區段中第 i 個 bucket 廣播時恢復為活動模式再嵌入到廣播通道中。
(7) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，回到步 驟4 繼續執行。
(二) (1, m) indexing-IAM 資料廣播方法
(1, m) indexing-IAM 方法的廣播結構(如圖 2-18 所示)，同樣地刪除了(1, m) indexing-AM 廣播結構中遺失資料索引區段，同樣使用旗標與計數器的方法，使 得行動客戶端不需要再透過遺失資料索引的方式，就可直接到遺失資料區段中取 得所需的資料項。
圖2-18 (1, m) indexing-IAM , m=3 的廣播結構 (1, m) indexing-IAM 的擷取程序：
(1) 行動客戶端嵌入廣播通道並擷取一個完整的 bucket，藉此取得下一個索引區 段或下個廣播週期索引區段的廣播時間。
(2) 行動客戶端進入睡眠模式，直到下一個索引區段或下個廣播週期索引區段廣 播時恢復為活動模式再嵌入到廣播通道中。
(3) 從索引區段中，取得所需資料項的廣播時間。
(4) 行動客戶端再一次進入睡眠模式，在所需資料項廣播時恢復為活動模式再嵌 入到廣播通道中。
(5) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，行動客 戶端將會由bucket 中得知，遺失資料項將會在遺失資料區段中第 i 個 bucket 重新廣播，根據下列程序繼續執行。
(6) 行動客戶端進入睡眠模式，直到所需資料項在遺失資料區塊中第 i 個 bucket 廣播時恢復為活動模式再嵌入到廣播通道中。
(7) 擷取所需資料項；如果成功取得所需資料項，結束這個程序；否則，回到步 驟4 繼續執行。
第三章 新增有序遺失區段方式
在前一章中，我們介紹重取資料、新增遺失區段與改進新增遺失區段三種方 式所修正的資料廣播方法。在本章中將介紹我們更進一步所改良的資料廣播的修 正方式，結合新增遺失區段方式與改進新增遺失區段方式而成的解決資料遺失問 題 的 方 法 ， 我 們 稱 為 新 增 有 序 遺 失 區 段 方 式(Add ordered missing segment approach)的資料廣播方法。
在[16]中所提出的改進新增遺失區段方式是利用新增遺失區段方式原有的 資料廣播架構，不需透過遺失資料索引，讓廣播伺服器端只需將遺失資料區段加 在現有廣播結構的後端。當行動客戶端在資料區段中發現所需資料發生遺失時，
由於廣播伺服器端已經在發生資料遺失的 bucket 中放入該資料項在遺失資料區 段中的廣播資訊，因此行動客戶端就可以無需透過索引的方式，直接到遺失資料 區段中取得遺失的資料項。雖然在改良後的新增遺失區段的修正方法中減少了遺 失資料索引區段，使得廣播結構大小有效的減少，並且當發生資料遺失問題時，
行動客戶端可直接從遺失資料區段中取得所需的資料項。在經過系統模擬與效能 分析之後，我們發現在調校時間上，使用改進新增遺失區段方式修正的資料廣播 方法的確優於相對應使用新增遺失區段方式修正的資料廣播方法，但是在延遲時 間上，使用新增遺失區段方式修正的資料廣播方法卻優於相對應使用改進新增遺 失區段方式修正的資料廣播方法。而當中主要的原因就是因為刪除了遺失資料索 引區段之後，當行動客戶端在遺失資料區段廣播前進入到廣播通道中時，行動客 戶端無法透過遺失資料索引區段所廣播的資訊來判斷是否有其他遺失的資料項 在遺失資料區段當中是行動客戶端所需的資料項，所以行動客戶端只好到下個廣 播週期才能擷取到所需的資料項，因此喪失了在遺失資料區段中獲取所需資料項 的機會，造成延遲時間不降反升的現象。因此在上述的情況之下，我們結合了新 增遺失區段方式與改進新增遺失區段方式的優點而提出了一個新增有序遺失區 段方式，來修正原有的資料廣播方法。
