第二章 文獻探討
2.4 上傳
2.4.2 上傳時機
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
20
2.4.2 上傳時機
N. Haderer 等人[9]認為，雖然新一代的行動裝置提供了非常強大的計算能力，但是能源 問題仍舊是進行行動感測的主要障礙。考量到能耗問題，為減少與伺服器端之間通訊出 錯的風險，裝置應在充電時才進行上傳。Rui Guo 等人[8]認為當裝置充電時上傳，對大 部份參與者而言，此時與行動裝置之間不會有所互動，裝置於此時也可提供充足的電力 與資源，促使 APP 順利完成數據的上傳。但是，因為部份參與者有可能在習慣上在行 動裝置充電時保持在關機狀態，或是每次充電時，都恰好處於一個完全沒有網路連線服 務的環境，而造成無法執行上傳。所以，該研究認為在裝置閒置時執行上傳較佳，因為 此時系統處於最低耗能的運作，而且參與者與行動裝置之間也不會互動，造成影響。
本研究認為上傳時機與感測實驗的性質有關，各種上傳機制面對不同的感測數據，
都應該有其相對的優缺點，因此本研究在實作上，將此上傳時機的選擇列為可設定之項 目之一，讓研究者於建立感測實驗時，自行考量並選擇適用的上傳機制項目。其項目包 括：
1. 畫面閒置時上傳：行動裝置畫面閒置時進行上傳。
2. 充電時上傳：行動裝置接上電源時進行上傳。
3. 時間限制上傳：每隔一段時間進行感測數據的上傳。
4. 筆數限制上傳：感測數據累積一定筆數後，立即進行上傳。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
21
第三章 系統架構與實作
從前述之文獻探討，我們得以知道許多的實際做法及其考量。而在此章節中，我們將說 明系統的架構與實作細節。
3.1 項目屬性代碼表
要實作可設式的行動感測平台，對於所有感測項目進行整理及分類是首要之任務，我們 依據各項目的型態、特性、用途予以標示分類，並定義代碼。如表 6 所示。
我們將所有的感測資訊共分為三類：
1. 感測器(Sensors)：屬於手機內部基礎運作元件，它維持了手機的基本協調運作、
使用者之間的溝通，及外在環境變化資訊的接收。
2. 裝置(Devices)：為比較具體性的元件，是使用者較能直接感受到之項目，甚至 可以適當做出設定或調整。
3. 行為資訊(Behavior)：屬於軟體元件上之記錄，會因使用者的操作行為及習慣而 改變之內容。基於隱私考量，我們對於行為資訊中較敏感之項目，並不提供直 接記錄，例如：在撥接資訊上，我們刻意以記錄收話、撥話之次數，取代記錄 電話號碼等資訊。簡訊部份的處理亦然，只記錄簡訊次數，而不將簡訊號碼及 內容進行收集，盡可能減少個資洩露問題。
‧
(Sensors)加速度感測器
(Accelerometer) acc
X 軸偏移值 ax
Y 軸偏移值 ay
Z 軸偏移值 az
方向感測器
(Orientation Sensor) ori
水平旋轉角 ox
縱向旋轉角 oy
橫向旋轉角 oz
磁性感測器
(Magnetic Sensor) magn
X 軸 mx
Y 軸 my
Z 軸 mz
溫度感測器
(Temperature Sensor) temp 攝氏溫度 celsius 距離感測器 (Devices)
全球行動通訊系統
經度(longitude) longitude 緯度(longitude) latitude
速度(speed) accuracy 方向(bearing) speed 精確度(accuracy) bearing
高度(altitude) altitude
電源資訊 pow 外接電源狀態 powact
‧
(Behavior)網頁瀏覽資訊
(Brower) browser 網頁標頭 title
網頁網址 url
撥接計數
(Phone Calls Count) call
收話次數 incomingcount 撥話次數 outcomingcou
nt 收話總時數 callinalltime 撥話總時數 calloutalltime 撥接資訊
(Phone Calls Info) calact
撥出號碼(加密) callnumber 撥入號碼(加密) calltime
撥出時間(秒) receivenumber 撥人時間(秒) receivetime
‧
本（Script），簡稱為 ECF:DSL，以進行各別描述，包含下列四項定義：1. 感測項目及屬性：所要處理的感測器及其屬性，如：GPS 的經緯度。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
25
表 7：ECF:DSL 依目標問題簡單分析
類別 內容
收集 手機通話訊號強度取得 GSM 資訊 收集 所處位置的經緯度取得 GPS 資訊 條件 是否位於中研院院區分析 GPS 資訊 頻率 設定 15 秒感測一次
上傳方式 螢幕閒置或充電中
圖 8：ECF:DSL 感測項目、頻率、過濾條件與上傳時機等定義
根據表 7，我們可知 GSM 共包含 SPN 及 GSM RSSI 兩項屬性，後者為必要資訊，
前者則考量往後或許會針對各不同行動服務公司，做出其他的分類統計分析，因此我們 也一併加入。而在 GPS 的部份，我們需要經度及緯度，如此才能在地圖上標示出行動 感測之定點。在過濾條件上，由於我們需要判斷是否位於中研院院區內，因此需要針對
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
26
GPS 的經緯度設定門檻，限定於該地區之內。而在頻率及上傳方式的部份，我們分別設 定了 15 秒感測一次，及螢幕閒置或充電中進行感測數據的上傳。如圖 8 所示。
在 ECF:DSL 中，定義了關鍵字來表達各部份的資訊，如表 8。項目的感測頻率，則 伴隨於每一個感測項目之後，在實際使用上，每個感測項目都可以設定不同的頻率，以 執行收集。另外，在過濾條件的判斷式的制定原則上上，我們加入了常見之邏輯運算子，
例如：大於(>)、小於(<)、等於(=)、大於等於(>=)、小於等於(<=)…等等。基於以上所述，
我們可將圖 8 轉換為 ECF:DSL 敘述，如圖 9 所示。
表 8：ECF:DSL 主要關鍵字對照表
關鍵字 意義
log 感測項目
where 過濾條件
uploadpolicy 上傳時機
圖 9：感測定義轉換為 ECF:DSL 內容
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
27
本研究在 ECF:DSL 之語法設定上已盡量簡化，但對於研究者來說，如此的處理方 式或許對研究者來說，仍然不夠友善。即使研究者可以深入了解整個語法規則，但對於 項目屬性表的比對查詢上仍然可能有所困擾，因此，我們提供 GUI 方式協助研究者產生 ECF:DSL。
3.2.2 感測實驗定義 GUI
在平台的實作上，我們提供 GUI 輔助研究者進行感測實驗定義，並產生 ECF:DSL。如 圖 10 所示，研究者可透過本研究所建立之實驗設定管理網站，除了可以建立實驗名稱、
實驗說明、啟動/關閉等基本資訊外，還可以建立感測實驗的項目、頻率、過濾條件等實 驗的細部設定資訊。如此的方式可提供大部份的感測實驗定義之使用。然而，為了因應 少數可能在設定上較為複雜之實驗，我們也提供 ECF 腳本（Script）編輯區，讓研究者 可以針對較為特別的實驗內容做出設定。如圖 11 所示。
圖 10：定義感測項目、頻率與過濾條件之 GUI
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
28
圖 11：ECF Script 編輯區塊
3.2.3 ECF 之發布
於文獻探討中曾有說明，本研究採用拉式法處理 ECF 之發布。在感測實驗定義完成後，
客戶端之參與者可透過 APP 連線至伺服器端取得 ECF。我們採用 RESTFul Web Service 處理此部份。RESTFul 是一個使用 HTTP，並且遵循 REST 原則的 Web Service，因此具 備跨平台之能力。我們透過它，在伺服器端上建立了授權服務及 ECF 服務。
如圖 12 所示，客戶端為取得 ECF，必須進行下列流程：
1. 客戶端請求授權，伺服器端授與 ID 及認證碼：在進行 ECF 的取得之前，系統 會要求參與者手機必須先通過授權取得客戶端 ID 及驗證碼，此舉是為了便於辨 識所收到的感測內容來自於同一客戶端。雖然，有許多研究或產品在此識別機 制的實作上，採用的是記錄行動裝置上的 IMEI。然而，基於隱私考量，我們刻 意不記錄此編碼。
2. 客戶端請求實驗列表，伺服器端比對條件並予以回應 ECF：當參與者之手機中 已具備此客戶端 ID 後，便可連線進行 ECF 之取得。客戶端在請求 ECF 時，必
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
29
須帶入授權所取得之客戶端 ID、驗證碼，及客戶端行動裝置的作業系統版本、
行動裝置型號等資訊。ECF 服務接收到來自客戶端的請求時，將依據所提供的 資訊內容進行實驗適用性的比對，並將適用之感測實驗加以包裝，成為以 JSON 形態表示的 ECF，再提供給客戶端。文件格式如圖 13 所示。共包括各實驗的編 號、名稱、說明及以 ECF:DSL 所描述的實驗內容。
如以上所述，便完成了實驗之發布。交予客戶端之 APP 著手 ECF 之分析及 執行，並進行數據的上傳。
圖 12：感測驗之發布流程
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
30
圖 13：ECF 之內容範例
3.3 實驗記錄檔(ELF)
ELF 和 ECF 相同，皆採用 JSON 文件之形式呈現。當客戶端準備上傳資料時，APP 便 會從讀取行動裝置上暫存之 log，轉換為 ELF。ELF 之內容包含：實驗編號、客戶端 ID、
感測項目與內容，及感測時間。
圖 14：ELF 之內容範例
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
31
由圖 14 所示，由於不同感測實驗可能具有相同的感測項目或屬性，因此，ELF 必 須載明實驗 ID。同時，也必須具備客戶端 ID 用以辨識。另外， ELF 於感測項目、屬 性等之描述上與 ECF:DSL 同樣參考項目屬性代碼表進行描述。同時也載明了感測時間，
以做為時效性之參考。以上述規格製定 ELF 之後，為了保障感測數據的安全，在上傳的 實際運作上，將經過加密及解密處理。
3.4 使用 MQ 調節上傳
在平台的運作上，有一個情況需要特別注意及考量；由於伺服器有其負載上限，當客戶 端參與者日益眾多，隨著資料上傳 ELF 數目大量增加，很可能造成伺服器一時無法負荷 的狀況。如圖 15 所示。系統若出現問題，將致使執行效率變差，甚至導致當機，造成 ELC 上傳失敗或遺失。
圖 15：伺服器因客戶端上傳 ELF 而負荷過重
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
32
因此，為了因應大量 ELF 的上傳數據處理，本研究採用訊息佇列(Message Queue，
簡稱 MQ)來做為兩端之間傳輸數據的緩衝處理。MQ 是一種訊息傳送服務，具備三項主 要之特點：
1. 非同步通訊協定：由於採取非同步處理，所以當客戶端送出數據後，不需等待 伺服器端之回應。可以使兩邊不會因為相互等待而使得效率降低。
2. 先進先出之處理方式：由於先進先出，先送達之資料，可確保被優先處理，不 會有無限等待之問題發生。
3. 保證訊息送達：沒有被取出的資料將永遠保持於 MQ server 之中，等候被領出，
因此不會時間過久被刪除或遺失之問題。
圖 16：使用 MQ 調節 ELF 上傳
如圖 16 所示，我們於兩端之間設置 RabbitMQ[18]以解決此問題。RabbitMQ 為一套 由 Erlang 程式語言所撰寫之 MQ server，遵循 Mozilla Public License 開源協議。因此，
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
33
客戶端上傳 ELF 時，不直接上傳至伺服器端，而且發送 ELF 訊息至 RabbitMQ 上先暫
客戶端上傳 ELF 時，不直接上傳至伺服器端，而且發送 ELF 訊息至 RabbitMQ 上先暫