4. 原有機制之改良
4.2. 改進之方法與其設計實作
4.2.1. 頻段挑選機制
在頻段挑選過程中一共有兩個機制，第一個機制稱為頻段評分機制，第二個則稱作 頻段感測快照機制。底下將分別針對此二機制進行詳細的設計說明與實作方式：
頻段評分機制
在頻段評分機制的設計上主要是運用一種基於歷史資料觀測的方式來進行評分，在 歷史資料觀測的部份，對於同一無線感知網路使用者，針對所使用的每一個頻段各有一 組 32 位元稱作閒置記錄的記錄值，在每次的頻段感測中，皆會更新此記錄值。而在實 作中，選擇最大 bit 數為最近一次的偵測結果，在每次進行偵測時，會先將此數值往右 遞移一位元，之後當偵測到頻段為閒置狀態時即標示為 1，而偵測到忙錄狀態時則為 0。
如圖 14 所示：
圖 14、閒置記錄與評分方式之示意圖。
圖 13 展示了一個例子，在某一個時間點，閒置記錄的記錄內容如圖中的 IDLE Record(n-1) 所示，內容為由 1010…10 循序組成，而在下一個時間點，該無線感知網路
32
使用者偵測到此頻段處於閒置狀態，則其會將該記錄往右移 1 位元，並且在最高位元的 值填入 1，即如圖 14 中 IDLE Record(n)所示。
而在進行評分值的方面，在此給與閒置記錄值的每 1 bit 一個權重，由最高的 bit 開 始為 31，依序遞減。計算方式即是將所有的位元與其權重相乘後加總，即可得到一個值。
以圖 14 為例，由 IDLE Record(n-1)可以得到其分數為 256，而 IDLE Record(n)則為 271。
若其值愈大，則代表其具有在愈近的時間點具有較多的閒置機會，或是在歷史記錄中其 閒置次數頻繁的特質。這樣的設計可以避免只有最後一個位元來決定評分的狀況。因此 在此處主要將利用這個評分標準來進行閒置頻段的評估。
而在頻段選定的部份則交由無線感知網路傳送端按照評分的分數由高到低進行評 分，並從中挑選部份頻段填入 RTSCR的控制封包內。為支援傳遞這些訊息，RTSCR的控 制封包需要進行改變，改變的內容主要是將原先儲存於原機制的欄位所佔用的 4 個位元 組改為儲存被選中的頻段。儲存方式主要是利用該欄位中一共 16 個位元分別代表不同 的頻段已挑選或未挑選。而表頭的部份則如圖 15 所示：
圖 15、修改後的 RTSCR之結構。
當無線感知網路使用者之接收端收到此 RTSCR的控制封包後，接收端即能知道傳送 端選擇那些頻段，並且也能從這些頻段中挑選適合本次傳輸之頻段。而挑選的方式除了 透過這套評分方式之外，尚還有在下個段落會提及的頻段感測快照機制。在挑選完畢之 後，接收端會將接下來想要使用的頻段按照順序填入 CTSCR的控制封包內，以告知傳送 端接下來的資料頻段切換順序，如此則可由接收端決定較有可能為空閒之頻段。而修改 後的 CTSCR 的結構則如圖 16 所示：
33
圖 16、修改後的 CTSCR之結構。
頻段感測快照機制
在上一段的無線感知網路接收端決定頻段切換順序時曾提到還需要配合頻段感測 快照機制的使用，這個機制主要是為了讓感測者能夠以較短的時間為代價，藉此取得某 些頻段的頻段使用情況。
當接收端收到 RTSCR之後，接收端會知道哪些頻段是傳送端所選擇的。此時接收端 會對這些頻段進行快速的頻段感測。對於每個頻段，其感測時間為 100 微秒，並在這 100 微秒的時間結束時更新閒置記錄值，並切換到下一頻段。在此若該頻段有任何封包傳輸，
則直接將該頻段標示為有其他使用者正在進行傳輸的情況；而未偵測到任何封包，則標 示其為閒置狀態。藉由此方法，能夠讓接收端在短時間內對於可能用到的頻段進行其最 近情況的分析，使得接收端判斷所用之資訊能夠更為準確。
4.2.2. 資料傳輸頻段感測機制之改良
在 4.1 的圖 12 中提到對於資料頻段感測時的某種特殊情境，這個情境主要發生在頻 段感測時若接收到 ACK，且在此 ACK 之後，主要使用者在短期間內均不使用此頻段。
若此時因為此 ACK 而導致頻段使用上的浪費則不太划算，因此在改善方案的部份則是 著重在觀看封包內容並判斷接下來是否該使用。
根據各個接收到封包的意義，當收到一個 RTS 封包、CTS 封包或 DATA 封包，則 代表接下來直到接收到一個 ACK 之前都不能使用此頻段。因此此處主要是利用頻段感
34
測時的最後一個封包來決定是否可以使用此頻段。但是封包的接收是需要時間的，若存 在一個封包來不及在頻段感測時間結束前被接收完畢，則為了避免誤判的狀況，因此最 後仍然不應該使用此頻段。根據以上的分析，可將決策以底下的圖來表示：
圖 17、修改後的頻段感測之決策機制。
4.2.3. SIFSCR後資料傳輸之改良
在 4.1 中，圖 13 顯示了在不考慮接收端的情況下，當 SIFSCR的等待時間過後可能 會因為隱匿終端問題而導致傳送端需要不少的時間才能返回控制封包傳輸頻段的情境。
而在解決方案的部份則是提出了「再次於同一頻段進行 RTS-CTS 握手動作」的方案做 為解決方法。
而這樣的方案主要是為了能讓傳送端迅速察覺接收端出現異常，原因主要是因為這 樣的程序所需要的時間約為 600 微秒，對比於先前提到在 DATA 為 2048 bytes 的情況下，
如此可大幅縮小反應的時間；此外，利用 RTS 與 CTS 的優點也包括了能讓其他使用者 知道這個頻段目前有其他使用者正在進行傳輸，使得本次的傳輸不會因為有其他使用者 干擾而中斷，搭配原有機制在 RTI 的處理，將會使得有意願的使用者在這段時間之後能 夠表達它們有使用此頻段的需求，使得整個無線感知網路的傳輸程序能順利完成，也能 降低對於主要使用者的干擾程度。相信這樣的改良機制能使得無線感知網路使用者在此 情境下的效能能夠提升。
35
在實作上，則只要在等待完 SIFSCR的處理函式中，針對傳送端的部份加入產生 RTS 控制封包的呼叫函式，並且讓傳送端與接收端各自將其行為狀態更動為
STATE_SEND_RTS 與 STATE_WAIT_RTS，如此在接下來的流程中，整個機制即會按照 改良後的流程運作。
到此，對於整個機制的改良已告一段落，在接下來的章節中，本篇論文將呈現以原 本的方法與改良後的方法在不同情境下的效能比較並進行分析。
36