第一章 序論
1.5 論文結構
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
9
1.4.3 兩端之介接
伺服器端與主要透過 Web Service 方式進行資料交換。當研究者至實驗設定網站上進行 設定而產生 ECF 之後，便可將之散布至客戶端。如圖 2 所示。
另一方面，當客戶端啟動感測且收集資料後，會依據 ECF 檔所定義之上傳時機，
處理數據的上傳。上傳資料時，客戶端的 APP 會先依原始記錄產生實驗記錄文件 (Experiment Log File，簡稱 ELF)，並予以加密，之後同樣透過 Web Service，將數據遞 送至伺服器端，再由伺服器端負責接收之模組，進行後續之處理。如圖 3 所示。
圖 3：系統實驗數據上傳示意圖
1.5 論文結構
本論文主要分為五個章節，第一章為序論，主要在於介紹整個研究的源起與概略性解說，
包括研究背景、研究動機、問題描述、研究目標及各章節之概述。第二章為文獻探討，
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
10
將針對本研究相關之理論、技術與研究，做出探討。第三章為系統架構，將介紹本系統 組成元件、系統運作流程、實驗設定檔之設計，及系統模組功能性的描述。第四章為實 驗與評估，透過進行模擬實驗之進行，驗證系統運作之效能。最後，我們在第五章提出 結論及未來發展。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
11
第二章 文獻探討
本研究主要針對行動感測的可設定式進行實作，故先從行動感測知識背景進行了解，並 針對各研究之實作方法進行比較，包括：行動感測類型、實驗設定策略、實驗發布策略 等。
2.1 行動感測類型
行動感測相關研究發展至今，許多學者提出不同之架構，其中，以參與感測(Participatory Sensing)和機會感測(Opportunistic Sensing)最具有代表性。以下分別介紹。
2.1.1 參與感測(Participatory Sensing)
參與感測最早是由 J. A. Burke 等人[12]所提出，其運作可以分為三層：
1. 感測層：包括參與者與設備，負責任務的進行與數據的收集。
2. 傳輸層：介於感測層及處理層之間，負責將要進行之任務資訊發佈至感測層，
而將感測而得來之數據，上傳至處理層。
3. 處理層：負責處理數據，進行整理、分析，以產出重要之資訊。
顧名思義，參與感測最重要之要素在於人們的參與，透過人們的加入協助判斷及收 集數據，才能得以擴大其感測分析之範圍，獲得涵蓋面廣，甚至巨量之數據。相對的，
它的缺點也在於過度依賴人們，易造成參與者的負擔，必須適當的吸引群眾的興趣，或
‧
2.1.2 機會感測(Opportunistic Sensing)
機會感測是另一種方式。與參與感測的差別，在於機會感測強調的不是人們的介入，而
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
13
查人們在使用 APP 上的行為，該研究之實作進行了幾項特定的項目之感測，包括：收 集 GPS 以得知使用 APP 時的地點，及收集 APP 執行時所透露的資訊。其用意是收集參 與者在何時、何地，開啟了何種 APP 等資訊。數據收集之後，透過分析使用者經驗，
藉以提供強化與提昇智慧型手機服務的參考。由於該研究的將處理邏輯固定寫入 APP，
所以其功能特定。此研究與序論章節中所舉之例子：Cheng-Yu Lin 等人所提出的 TPE-CMS [3]，及 Vpon[5]之方式，都無法提供研究人員進行感測實驗項目內容的抽換，
或是自由搭配選擇，亦即無可設定性。因此，我們可定義此類的行動感測為片面式行動 感測。
在圖 4 中，我們採用不同顏色，代表各種不同功能的片面式行動感測 APP。從中可 看出，每當為了收集不同目的之感測數據，因為感測實驗項目與判斷邏輯有所不同，無 法重新利用，所以必須專案重製專業開發人員必須不斷的發展出不同的 APP 程式以因 應需求。而客戶端也必須安裝不同套的 APP 才能進行感測實驗。
圖 4：片面式行動感測運作示意圖
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
14
圖 5：全面式行動感測運作示意圖
2.2.2 全面式行動感測
相對於片面式行動感測，另有一類方式可稱為全面式行動感測。例如，Rui Guo 等人[8]
提出的 MobileSens 是一種可以將 Android 智慧型手機上之眾多感測器，一次全面性的進 行數據收集。相較於片面式行動感測所存在的缺陷，全面式行動感測不失為一種解決方 案；專業開發人員只需要開發一套 APP，參與者也只需要安裝一套 APP，即可進行收集 全部的感測項目、上傳所有項目的感測數據。示意如圖 5。
但是，此方式在運作彈性上也受到了限制：
1. 無法提供彈性化的選擇：以研究者角度來看，因為做法上採用一次性的全面感 測，所以完全不需要進行感測實驗定義，但是相對的，研究者也無法依據自己 的實際需求決定，描述數據收集項目及條件範圍。
2. 虛耗資源：與目的無關的數據也被一併的感測收集，不論是對於系統的整體處 理運作效能上，或是資料的儲存空間上，甚至對於行動裝置的電力等，都造成
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
15
了虛耗與浪費。
3. 欠缺隱私考量：被收集的感測數據中可能包含了許多參與者不想被收集，或是 研究者也不願去碰觸的敏感數據，可能造成個人隱私安全上的危害。
N. Haderer 等人[9]所提出的 AntDroid，則提出了較具彈性的做法；為了協助研究者 對於實驗的描述，該研究提出了一種名為 ANTDROID 腳本語言(ANTDROID Script Language)的方案，此種語言是屬於 JavaScript 的延伸，該研究利用此種語言原生支援 JSON(JavaScript Object Notation)之特性，在處理時將實驗定義轉化為 JSON(Javascript Object and Array notation)文件進行傳遞。JSON 是一種輕量級的數據交換格式，可減少 通信傳輸的負荷。相較於可擴展標記語言( eXtensible Markup Language，簡稱 XML)，在 Android 上處理 JSON 文件較有效率，而且若有必要，JSON 也可以很容易的轉換為 XML 格式。如表 4 所示，透過研究者編寫及註冊 ANTDROID 腳本語言，將它發佈到 ANTDROID 引擎上，進行感測數據收集的任務。
表 4：AntDroid: WiFi 網路感測範例
N. Haderer 等人[9]所提出之方式，是一種對於全面式感測的改善方案。在可設定性 上，由於採用腳本語言(Script Language)來描述感測實驗的細節描述，對於整體系統架構 上，帶來相當大的彈性空間。但是，並非所有領域的研究者都擁有程式撰寫能力，雖然
‧
本研究採用特定領域語言(Domain-Specific Language，簡稱 DSL)來描述實驗的定義，
DSL 是系統開發人員為了解決特定領域的問題所定義的專用語言。根據實驗設定之需求，
我們設計了自己的 DSL 規格，並採用 GUI 來輔助實驗的建立；在研究者充份了解此 DSL 的規則的情況下，系統允許研究者自行撰寫這個 DSL 的程式來精確定義想要進行的感 測實驗，但最主要的，我們讓研究者能夠透過與 Web 小工具(widget)之間的互動方式，
自動產生相對應的 DSL 程式，取代直接編寫程式碼的方式。接著，DSL 程式會透過特 定的機制，進行包裝成為 JSON 文件後，進行實驗的發布。我們將此文件命名為實驗設 定檔(Experiment Configuration File，簡稱 ECF)。細節說明請詳見 3.2 實際設定檔(ECF)。
2.3 實驗發布策略
當描述實驗內容的可設式文件確立之後，系統必須要提供特定的發布策略，才能夠將此 份文件部屬至各客戶端以實際運作、執行感測任務。文獻中，關於實際發布策略可以大 致歸納為推式法(push-based approach)及拉式法(pull-based approach)兩類。
2.3.1 推式法(push-based approach)
T. Das 等人[14]所提出的 PRISM 是一款以 Mobile Phone 為基礎的應用平台，它採用推式 法，由伺服端主動的發布感測任務至所有的客戶端上。由於 PRISM 提供即時感測任務 的執行，需要針對每一個客戶端節點保持立即性的監控與溝通。伺服器端依據參考手機 目前的位置、剩餘電力等狀況，即時判斷並發布執行命令，以避免客戶端接收到不符合 現有條件的感測任務，其架構如圖 6 所示。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
17
推式法在實際運作上有所條件限制。首先，伺服器端為了維持與客戶端之間的即時 溝通，必須時時監控每一個客戶端的狀況，並根據客戶端所回傳之資訊隨時判斷及計算，
通常需要具備一定強度規模的軟硬體環境條件，用以因應系統運作時所帶來的高度負荷，
否則就得減少或是嚴格限制客戶端的數量，以減經伺服器之負擔，因此，其擴充性較差。
除此之外，由於伺服器端必須隨時分析客戶端之資訊，因此兩端之間必須持續保持網路 通訊暢通之狀態，否則感測任務無法順利運作。
圖 6：PRISM 架構圖
2.3.2 拉式法(pull-based approach)
N. Haderer 等人[9]所提出的 AntDroid，採用的是拉式法，此種方式不從伺服器端主動發 布實驗至各行動節點，也不時時監控客戶端的資訊，而是相反過來，透過特定機制，由 客戶端向伺服端要求取得感測任務資訊。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
18
圖 7：推式法與拉式法之示意圖
本研究之實驗部署同樣地採用拉式法，原因是此種做法相對上較具有彈性；在實作 上，可以將「能否執行實驗」之判斷邏輯，交由客戶端上 APP 進行處理，如此可以大 量減輕伺服器端負擔，卻又能達到相同之效果。另一方面，客戶端的感測任務也可以在 沒有網路連線的狀況下進行；對於連線之需求，排除定義上需要網路才能進行的感測實 驗之外，在整體系統架構上，只在取得及更新實驗、上傳感測數據時會需要網路連線。
我們建立了一系列的 RESTful Web Service 機制，讓客戶端在具備連線的狀態下，可以 透過這個機制，向伺服器端進行註冊，透過手機型號及作業系統之比對，取得適用之 ECF。細節說明請詳見 3.2.3 ECF 之發布。
2.4 上傳
客戶端執行了感測實驗之後，最重要的便是將感測的結果上傳至伺服器端。為此，兩端 必須確立上傳的規格及時機，才能順利產生及解析感測實驗的結果。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
19
2.4.1 上傳規格
Rui Guo 等人[8]將感測記錄，依據其內容、性質及感測方式，歸納分為 19 類，並予以 分別命名。當上傳啟動時，暫存於裝置內的數據，將先轉換成特定的 JSON 文件。此 JSON 文件有固定的四對鍵值，分別代表日期、時間、資訊類別、及以識別手機的國際移動設 備辨識碼(International Mobile Equipment Identity number，IMEI)。另外最後一個鍵值是
Rui Guo 等人[8]將感測記錄，依據其內容、性質及感測方式，歸納分為 19 類，並予以 分別命名。當上傳啟動時，暫存於裝置內的數據，將先轉換成特定的 JSON 文件。此 JSON 文件有固定的四對鍵值，分別代表日期、時間、資訊類別、及以識別手機的國際移動設 備辨識碼(International Mobile Equipment Identity number，IMEI)。另外最後一個鍵值是