介質使用權的競爭機制

802.11 也像 Ethernet 的 MAC，是分散式的系統，沒有一個專門 做中央控制的設備，只要 Station 有東西想傳，就檢查 medium 是不 是可用的，如果檢查後發現 medium 已經 idle 超過一段 DCF

inter-frame space (DIFS)的時間，就馬上傳送封包出去; 如果 medium 有人用，就等到 medium 再次變成 idle 後，經過一個 DIFS 並跑完 back-off 程序後再傳送;所謂的 back-off 程序，是說當 medium 變成 idle 且經過 DIFS 後，會有一段叫做 back-off window(或 是 contention window)的時段，這個時段被切成許多個 time slot，

(每個 slot 的長度是 10us)，Station 會隨機選一個 slot，並在該 slot 試著去使用 medium，而所有的 Stations 中，誰選到最前面的 slot 就有權利使用 medium.下圖是 back-off window 的示意圖:

DIFS

backoff window 會隨著嘗試使用 medium 失敗的次數(retry count) 而增加，這是為了減少 Station collision 的機會.而當 backoff window 到了預設的上限就不會增加了，如同圖中第 5 次到第 6 次的 情形.而當該 Station 搶到了 medium 存取權，backoff window 就會 重置.如果該 Station 一直搶輸，到逹一個預設的次數，那想傳送的 這個封包就會當作被丟掉(discard).

5.4.1.2 Network Allocation Vector (NAV) & Request To Send/Clear To Send (RTS/CTS)

在成功地取得 medium 的使用權後，Station 發出的封包裡有個 NAV 的欄位，裡面的數值告訴其它人他會使用 medium 多久的時間，

當然這段時間包括了數個 SIFS，傳 Frame 的時間以及該 Frame 的 ACK frame 時間等等的時間.其它人會從 NAV 開始倒數，只要還沒倒數至

0，都表示 medium 還在使用中.圖 5.29 是 NAV 功能的示意圖:

圖 5.29 NAV 示意圖

傳送端 Station 的 RTS 和接收端的 CTS 封包也有 NAV 的欄位.兩 者的 NAV 長短不同，但結束的時間點一樣，會同時倒數至 0.聽到 RTS 和 CTS 的 Station 可以知道 medium 何時才能用，而不會在有人使的 情況下去干擾別人.這個機制在多個網路重疊的情況下也有用，就算 是屬於不同的網路，只要是用同一個 physical channel 的 Stations 都會看 NAV 來動作.

下圖是 RTS/CTS 運作的示意圖:

圖 5.30 RTS/CTS 運作示意圖

和 C 彼此無法知道對方的存在，但 Station B 在 Station A 和 Station C 的信號範圍內.

如果沒有 RTS/CTS， Station A 和 Station C 同時要和 Station B 通訊的話，會造成 collision. Station B 無法正常地和任一者通 訊，但 Station A 和 Station C 也不知道問題出在哪; 但加了 RTS/CTS 的機制後，Station B 的 CTS 就會讓 Station C 知道 Station B 正在 和別人傳輸資料中，Station C 就不會去干擾 Station B.

NAV 屬於 virtual carrier-sensing，是用來逹到 Carrier sensing function 的一種方式， Carrier sensing function 的另一種方式是 physical carrier-sensing，此種方式會根據 medium 的不同和使用 的調變方式不同而改變，在 RF-based media 的情況下， physical carrier-sensing 比 virtual carrier-sensing 貴得多， 所以多數 的系統以 NAV 來作 Carrier sensing function.

如果傳送的封包長度大於 RTS threshold 這個參數，傳送端在傳 送封包之前會先送出一個 RTS 的封包，RTS 會設定 NAV 長度到 Data 的 ACK 結束.接收端會回應一個 CTS，此 CTS 封包內的 NAV 也會設定 到 Data 的 ACK 結束.RTS threshold 這個參數通常是在驅動程式的 設定軟體中更改.

5.4.1.3 Fragmentation

802.11 為了減少同一個頻帶其它訊號的干擾，會對封包進行切割 (Fragmentation).因為此頻帶的干擾源多是短時間，高能量地突然產 生，所以把封包切成小段可以減少被干擾的封包的數量.至於多大的 封包要被切割，取決於 fragmentation threshold 這個參數，大於這 個長度的封包就會被切成數個小的封包再傳送.

RTS/CTS 再配合 fragmentation，的情形如下圖.

Sender

5.4.1.4 Error Recovery

如果封包傳送中發生錯誤了，意即傳送端沒有收到接收端回傳的 ACK，那傳送端就要重送，每次重送會增加 retry count(沒有搶到 medium 使用權也會增加此 count). 當 count 到逹一個預設的上限，

就會丟棄這個封包，並向上層報告.Retry counter 又分為 short retry count 和 long retry count. Short 是指傳送的封包長度小於 RTS threshold; 反之就是 long.

Retry Count 重置只要滿足下列條件之一:

Short retry count:

1. 送出 RTS 後，收到對應的 CTS.

2. 送出 short 封包後，收到 ACK.

3. 收到 Broadcast or multicast 封包.

Long retry count:

1. 送出 Long 封包並收到 ACK.

2. 收到 Broadcast or multicast 封包.

會把 Retry count 分成兩種的原因是，網路管理者可以調低 Long retry count 來減少網路中較大的封包的數量，如此一來需要的

buffer space 也會比較小，在網路負荷比較重的時候，這麼做可以 提高網路的強健度.

5.4.1.5 Point Coordination Function (PCF)

802.11 的標準也提供了一種叫 Point coordination

function(PCF)的 medium 存取機制，這是一種為了提供即時服務而強 制由 AP 來控制誰能有存取 medium 的權利.

在存取 medium 時有兩種模式:一種是 contention-free period，

也就是 PCF 的機制;另一種是 contention period，是跑 DCF 的機制.

但現在市面上的產品很少有提供 PCF 的，所以我們在 PCF 的部份也不

再多著墨.

5.4.1.6 Broadcast and Multicast

雖然我們的傳輸平台並沒有使用廣播和群播的功能，但這裡還是 提一下;在廣播和群播的情況下，傳送端不會需要接收端回 ACK，傳 送的封包也不會被切割更小的 frame.因此廣播和群播都是單一步驟 就能完成的傳輸動作，NAV 會設定成 0.如圖 4 所示: 當 medium 變為 可用狀態持續了 DIFS 後，經過 backoff window 傳送端 Station 送出 了一個廣播/群播的封包，NAV 是 0，所以傳完該封包後，經過一個 DIFS，其它 Station 就開始跑 contention window，準備下一次搶 medium 傳封包的程序.

5.4.2 無線環境下系統使用者數目上限之分析

在 5.3.4 小節，我們經由量測發現，當 client 數量超過 6 個之 後，系統提供服務的情況變得不穩定，有時會顯示找不到 server，

有時成功連上了 server，但實際上卻沒有傳輸資料.理論上 54Mbps 的 802.11g 網路頻寬應該要能容納 400 多個 130kbps 的連線，(Server 和一個 Client 間的串流會佔掉 130kbyte/sec 的頻寬，因為每 40ms 要傳出一張畫面.這張畫面會被分割成 5~6 個封包，一個封包是

1024byte)，但實測發現只能提供 6~8 個使用者同時使用，接下來我 全部所花的時間): 731us， 279us， 256us， 659us， 191us，這是 從傳送端送到 AP 花的時間;若再加上 AP 傳到 client，又還要多一倍 的時間，所以傳 5 個封包會用掉 2*(731+279+256+659+191)us = 4.23ms; 然而，無線網路的錯誤率比有線網路高許多(約每 20 個封包 /contention time 以及其它控制訊號的時間.且同一筆資料要先從 server 到 AP，再從 AP 到 client，等於同樣的資料用了兩次頻寬.

我們取 4 個觀測到的樣本，RTS/CTS/UDP data/ACK 花的時間如(表

除了 RTS/CTS/ACK 之外，還要考慮亂數決定的 contention time，

也就是在 back-off window 花了幾個 slot time 當作 contention time，這也會降低實際會在傳 Data 的頻寬，最後可以得到 Data 所分

在前面兩章已經看過 online 平順演算法的做法和效能，在這章 我們希望這套做法可以實際增進傳輸系統的效能，重點是如何將演算 法加入系統中.

5.1 小節介紹整個系統的架構，5.2 小節說明我們的程式是做在 大

架構的哪一個區塊中，以及如何和系統互動.另外我們希望能夠找出 系統可以容納的用戶數目上限以及網路對平順演算法的影響，所以做 了許多觀測.在 5.3 小節我們將這些觀測結果做了整理並分析其原 因.

5.4 小節更深入地探討無線網路的運作機制，在說明完 802.11 MAC 之後，我們試著分析系統用戶上限(無線網路環境下)比預期低很 多的原因.

第六章 結論

本論文主要是延伸已有的 stored video 平順演算法，使其也能 夠處理即時產生的影音資訊.我們一開始先回顧基本的平順演算法，

說明其運作方式及特性，接著再探討即時資料和已存好的資料在平順 處理上有何差異，針對這些不同之處改進原有的演算法.

從最單純的 fix size & non-overlapping window smoothing 到 需要高運算量但效能更好的 sliding window smoothing，我們詳細 地說明為何要做這些改變，最後可以發現，stored video 只是 online 把 window size 取成無窮大的一個特例.

再來是未來可以努力的方向:目前系統只能處理影像，還需要加入聲 音的部份才算完整.還有就是多個 client 同時存取同一台 camera 的 影像時，最省力的作法是讓一個 thread 集中處理，再 multiplex 給 各個 client;但目前的作法是多來一個 user 就多建一個 thread，這 個部份還有改進的空間.

參考文獻

[1] J.D.Salehi ， Z.-L. Zhang ， J.F.Kurose ， and D.

Towsley，＂Supporting stored video: Reducing rate Varibility and end-to-end resource requirements through optimal smoothing，＂

IEEE/ACM Trans. Networking， vol. 6， pp. 397-410，1998

[2] S. Sen， J. L. Rexford， J. K. Dey， J. F. Kurose， and D. F.

Towsley， “Online smoothing of variable-bit-rate streaming video，＂ IEEE Transactions on Multimedia 1997.

[3] W.Feng and S.Sechrest， “Smoothing and buffering for delivery of precorded compressed video，＂in Proc. Of the IS&T/SPIE Symp.

On Multimedia Comp. and Networking， pp. 234-242， Feb. 1995.

[4] Z.-L. Zhang， J. F. Kurose， J. D. Salehi， and D. Towsley，

“Smoothing ， Statistical Multiplexing ， and Call Admission Control for Stored Video，＂ IEEE Journal on Selected Areas in Communications， Vol. 15， No. 6， August 1997， pp. 1148-1166.

[5] W.Feng and S.Sechrest “Critical bandwidth allocation for delivery of compressed video＂， Comp. Comm.， vol. 18， pp.

709-717， Oct. 1995.

[6] O. Hadar ， S. Greenberg ， “Statistical Multiplexing and Admission Control Policy for Smoothing Video Streams Using e-PCRTT Algorithm，＂ The International Conference on Information Technology: Coding and Computing 2000， pp 272-277.

[7] W.-C. feng and J. L. Rexford ， “Performance Evaluation of

Smoothing Algorithms for Transmitting Prerecorded Variable-Bit-Rate Video，＂ IEEE Transactions on Multimedia， Vol.

1， No. 3， September 1999， pp 302-313.

[8] J. Zhang and J. Hui， “Applying Traffic Smoothing Techniques for Quality of Service Control in VBR Video Transmissions，＂ Computer Communications， April 1998， pp. 375-389.

[9] S. Sahu， S.-L. Zhang， J， Kurose and D. Towsely， “On the Efficient Retrieval of VBR Video in a Multimedia Server ， ＂ International Conference on Multimedia Computing and System 1997， pp. 46-53.

[10] J. M. Mcmanus and K. W. Ross ， “Video-on-Demand Over ATM:

Constant-Rate Transmission and Transport，＂ IEEE Journal on Selected Areas in Communications， Vol. 14， No. 6， August 1996，

pp. 1087-1098.

[11] W. Feng and J. Rexford， “A comparison of bandwidth smoothing techniques for the transmission of prerecorded compressed video，＂ in Proc. IEEE INFOCOM，pp. 58-66， April 1997.

[12] W.-C. Feng， F. Jahanian and S. Sechrest， “An Optimal Bandwidth Allocation Strategy for the Delivery of Compressed Prerecorded Video，＂ Multimedia Systems， Vol. 5， No. 5， 1997， pp. 297-309.

[13] Ming-Sheng Hsieh， “A smoothing Algorithm in Variable Bit Rate Streaming＂ A thesis for the Degree of Master of Science in

Communication Engineering， August 2004.

[14] W.-C. Feng ， “Rate-Constrained Bandwidth Smoothing for the Delivery of Stored Video ， ＂ SPIE Multimedia Computing and Networking Conference Feb 1997.

[15] Chan-Wei Lin ， “Smoothing Algorithm for Video Streaming in Packet Based Transmission System，＂ A thesis for the Degree of Master of Science in Communication Engineering， August 2005.