在 SunSPOT 上實作 WPAN-ATP 後，接著進行實驗來觀察協定的行為。觀察重點有 二：基於速率的流量控制(rate-based flow control)、封包遺失回復(packet loss resilient)。
在實際環境中，使用 SunSPOT 進行傳送接收實驗，網路拓撲由一個感測裝置和一
26
實驗 1-3：傳送時間間隔設為 25 ms，接收回應延遲設為 50 ms。
觀察重點：
1. 傳送端/接收端在延遲(delay/latency)和 queue 長度之變化與關係。
2. 接收端如何根據應用程式回應延遲(application response latency)和 RxQueue 的 長度來決定建議速率(suggest rate)。
3. 傳送端 如 何 根據 lowpan 傳輸 延遲 (lowpan Tx latency) 和接收 端建議 速 率 (receiver suggest rate)來調整傳送速率(transmission rate)。
4. 傳送速率和傳送端傳輸量(throughput)的關係。 包含 4 個 SACK 週期。除了傳輸量(throughput)的資料每秒取樣一次之外，其他 資料皆每 SACK 週期取樣一次。
本實驗中定義：
Rx propagation delay：
從資料封包進入傳輸層開始，到資料存入 RxQueue 為止的時間間隔。此數值反 映 WPAN-ATP 處理接收封包的速度。
Tx propagation delay：
從應用程式傳送資料開始，到資料封包下送到 lowpan 層為止的時間間隔。此 數值反映 WPAN-ATP 處理傳送封包的速度，以及 TxQueue 的 queuing delay。
lowpan Tx latency：
從資料封包下送到 lowpan 層開始，到 lowpan 回應傳送成功為止的時間間隔，
27
1. 從傳送端送出的封包序號(sequence number)看到資料封包重傳。
2. 傳送端的資料封包重傳和接收端的資料封包排序。
3. 傳送端 queue 的長度變化，尤其是 ReTxQueue 的封包累積。
4. 接收端 queue 的長度變化，尤其是 OrderingQueue 的封包累積。以及封包序號 和 OrderingQueue 長度的變化與關係。
圖示說明：
圖的橫軸以秒(sec)為單位。除了送出的封包序號每次傳送取樣一次之外，其他皆每 SACK 週期取樣一次。
本實驗中定義：
last Rx sequence number：
每次取樣時，到該時間點為止，最後接收到的封包序號。
last sequence number in RxQueue：
每次取樣時，到該時間點為止，RxQueue 中最後一個封包序號。在此序號以前 的封包已排好順序。
28
(實驗1-1) 傳送時間間隔：25 ms，接收回應延遲：8 ms。
圖 17 : [實驗 1-1] 接收端的延遲(latency/delay)和佇列(queue)
圖 18 : [實驗 1-1] 傳送端的延遲(latency/delay)和佇列(queue)
29
圖 19 : [實驗 1-1] 建議速率(suggest rate)的決定
圖 20 : [實驗 1-1] 傳送速率(transmission rate)的調整
30
圖 21 : [實驗 1-1] 傳送端的傳輸量(throughput)和傳送速率
分析：
(1) 從圖 17可見，由於接收端的處理速度夠快，所以延遲情況變化不大，而且 queue 的 長度在大部分的時間為 0。開頭的高起是起始速率所致，起始速率預設值為 32 pkts/s，
對應的延遲值為 1000 / 32 = 31.25。
(2) 從圖 18和圖 21可見，由於傳送速率(transmission rate)高於應用程式的傳送速度，所 以 TxQueue 長度不會大幅成長。ReTxQueue 長度維持在 2 上下是因為 queue 中有已 送出尚未 ACK 的資料封包，若有封包遺失的情況，ReTxQueue 長度會較顯著成長。
(3) 根據 3.7 中的接收端流量控制方法，根據應用程式回應延遲(application response latency)和 RxQueue 的長度來決定建議速率(suggest rate)。從圖 19中可見，在接收端 處理速度較快的情況下，queue 的長度大多為 0，建議速率直接由應用程式回應延遲 主導，即表 1流量控制中的正常模式(Normal)。
(4) 根據 3.7 中的傳送端流量控制方法，根據下層的傳輸延遲(Tx latency)和接收端的建議
31
速率(receiver suggest rate)來調整傳送速率。從圖 20 可見，接收端建議速率高於 lowpan 傳輸延遲(lowpan Tx latency)的對應速率，傳送速率取二者中較小者，也就是 傳送速率由 lowpan 傳輸延遲主導。這表示傳送速率的瓶頸在傳送端。
(5) 從圖 21中可見，傳送速率表示資料傳送的最高速度限制，當傳送端應用程式傳送的 頻率不高時，實際的傳輸量(throughput)會低於傳送速率。
32
(實驗1-2) 傳送時間間隔：25 ms，接收回應延遲：25 ms。
圖 22 : [實驗 1-2] 接收端的延遲(latency/delay)和佇列(queue)
圖 23 : [實驗 1-2] 傳送端的延遲(latency/delay)和佇列(queue)
33
圖 24 : [實驗 1-2] 建議速率(suggest rate)的決定
圖 25 : [實驗 1-2] 傳送速率(transmission rate)的調整
34
圖 26 : [實驗 1-2] 傳送端的傳輸量(throughput)和傳送速率
分析：
(1) 從圖 22可見，RxQueue 有慢慢累積封包的現象，表示接收端應用程式的處理速度稍 小於資料封包到達的速率。RxQueue delay 會隨著 queue 長度增加而變長。
(2) 從圖 23可見，Tx propagation delay 曲線和 TxQueue length 曲線有些相似，表示造成 Tx propagation delay 增加的主因是 TxQueue 的佇列延遲(queuing delay)。
(3) 從圖 24可見，當 RxQueue 的長度在自身容量的一半以下時，建議速率(suggest rate) 由應用程式回應延遲(application response latency)主導。
(4) 從圖 25可見，接收端建議速率低於 lowpan 傳輸延遲(lowpan Tx latency)的對應速率，
所以傳送速率(transmission rate)由接收端建議速率主導。這表示資料傳輸的瓶頸在接 收端。此外，傳送速率相較於建議速率來得平穩，表示表 2中的邊界速率(margin rate) 發揮作用。
(5) 從圖 26可見，當傳送和接收的速度接近(傳送稍快於接收)時，實際傳輸量(throughput) 受傳送速率限制，和圖 21比較，可以看到 throughput 略低。
35
(實驗1-3) 傳送時間間隔：25 ms，接收回應延遲：50 ms。
圖 27 : [實驗 1-3] 接收端的延遲(latency/delay)和佇列(queue)
圖 28 : [實驗 1-3] 傳送端的延遲(latency/delay)和佇列(queue)
36
圖 29 : [實驗 1-3] 建議速率(suggest rate)的決定
圖 30 : [實驗 1-3] 傳送速率(transmission rate)的調整
37
圖 31 : [實驗 1-3] 傳送端的傳輸量(throughput)和傳送速率
分析：
(1) 從圖 27可見，RxQueue 有累積封包的現象，表示接收端應用程式的處理速度小於資 料封包到達的速率。RxQueue delay 會隨著 queue 長度增加或減少而變長或縮短。圖 中，RxQueue 長度陡降是因為流量控制發揮作用(見(6)之說明)。
(2) 從圖 28可見，TxQueue 的長度快速成長，且在 2 秒後達到滿 queue 的情況，表示傳 送速率低於應用程式資料傳送的速度。Tx propagation delay 曲線和 TxQueue length 曲線有些相似，表示造成 Tx propagation delay 增加的主因是 TxQueue 的佇列延遲 (queuing delay)。圖中，Tx propagation delay 的高起是因為流量控制所致(見(6)之說 明)。
(3) 從圖 29可見，當 RxQueue 的長度在自身容量的一半以下時，建議速率(suggest rate) 由應用程式回應延遲(application response latency)主導；當 RxQueue 的長度超過自身 容量的一半時，建議速率調降為接收速率的一半，即進入表 1中的速率調降模式(Rate
38
Down)。
(4) 從圖 30可見，接收端建議速率低於 lowpan 傳輸延遲(lowpan Tx latency)的對應速率，
所以傳送速率(transmission rate)由接收端建議速率主導。這表示資料傳輸的瓶頸在接 收端。此外，傳送速率相較於建議速率來得平穩，表示表 2中的邊界速率(margin rate) 發揮作用。
(5) 從圖 31 可見，當傳送快於接收時，實際傳輸量(throughput)受傳送速率限制，和圖 21 比較，可以看到 throughput 明顯較低。此外，在 throughput 的低點可以看到傳送速率 大幅調降產生的影響。
(6) 圖 29說明接收端 RxQueue 長度過半觸發速率建議(rate suggestion)過程中的速率調降 (Rate Down)，配合圖 30和圖 31，可以說明傳送端根據建議速率降低傳送速率，讓 實際傳輸量(throughput)下降，所以接收端有時間消化 RxQueue 中的資料，queue 的 長度下降。接著看圖 28和圖 31，傳輸速率下降導致資料封包待在 TxQueue 中的時 間拉長，反映在 Tx propagation delay 曲線的高起處。
39
(實驗2-1) 封包遺失率：0.20
圖 32 : [實驗 2-1] 傳送端資料傳送與重傳
圖 33 : [實驗 2-1] 資料傳送和接收的情況
40
圖 34 : [實驗 2-1] 傳送端的佇列(queue)
圖 35 : [實驗 2-1] 接收端的佇列(queue)
41
分析：
(1) 從圖 32可見，傳送端送出的封包序號大致構成一條斜率為正的直線，不過這條線出 現許多斷裂，封包序號重複的部分就是資料封包重傳。
(2) 圖 33中有三條曲線：第一條是傳送端送出的封包序號(sequence number)；第二條是
接收端最後收到的封包序號(last Rx sequence number)；第三條是 RxQueue 中最後一 個封包序號(last sequence number in RxQueue)。第二條和第三條的距離愈大，表示接 收端收到愈多需要等待排序的封包，這是封包遺失所致。此外，從圖中可以發現第 傳送端送出的順序相同，OrderingQueue 的長度大幅增加表示出現封包遺失。觀察 last Rx sequence number 和 last sequence number in RxQueue 這兩條曲線。OrderingQueue 累積時，兩條線的距離較大，表示出現封包遺失，新進的資料封包必頇等待排序；
OrderingQueue 長度下降時，兩條線的距離接近，表示收到符合順序的資料封包，在 OrderingQueue 中等待排序的封包也依序移到 RxQueue。
42