一、hidden terminal problem隱藏節點問題:
影響: 造成網路的流量降低。
說明:
(1)以Fig. 1.圖為例，node A 正在傳送broadcast data給node B，
此時node C要傳送broadcast data，於是listen一backoff時間，
C 並不知道node A正傳送data，便以為目前沒有host 在傳送data，
便也將data 傳送出去，此時在node B 便發生了碰撞。
這樣的問題不但造成了網路的頻寬浪費，並且也不可靠。
(2)以Fig. 1.為例，node A 要傳送data 給node B 於是發出RTS，但是node C 由於距離node A 比較遠，
所以並不知道node A 正發出RTS 給B，所以對node C 而言，它並沒有收到任何的訊號，
所以並不知道目前有任何host 正在傳送data。因此，當它有data要傳送給node B 時，
便先傳送RTS 訊框給B，此時，在node B 便發生了碰撞，造成了node A 和node C 都收不到CTS。
解決:
IEEE 802.11提出虛擬載波偵測 (Virtual Carrier Sense):
虛擬載波偵測是利用一個NAV (Net Allocation Vector)，
這一個向量記錄著host 須要多久的時間來完成傳送data，
而使其它的 host 根據這資訊能夠知道channel 目前是否忙碌。
在利用RTS/CTS 送收控制訊框時，
在RTS 及CTS 訊框中都夾帶著一個傳送端預定傳送data 所需時間的欄位，
而當別的host 看到傳送端送出的RTS 訊框或是接收端送出的CTS 訊框時，
就會將所需的時間紀錄自己的NAV 中，如此一來，時間未歸零前，
就表示目前host不能夠傳送任何訊框，因為channel 是正被使用中的。
不過，利用了NAV 的機制並沒有完全的解決了DCF 效能不佳的問題。
IEEE 802.11 使用 802.11 RTS / CTS的 握手封包確認和克服部分隱藏節點問題。 RTS / CTS的不是一個完整的解決方案，並可能進一步降低流量，但適應確認從基站也可以協助你。
比較明確的是與隱藏點RTS / CTS的每個封包通信是有效的（甚至短訊框，或超過頂端高RTS / CTS的訊框）。
其他的方法可以用來解決隱藏節點問題是：
提高發射功率從節點
使用 全向天線
消除障礙
移動節點
增強軟件使用協議
使用 天線分集
附CAMA/CA圖:
二、exposed terminal曝露節點問題:
影響: 造成網路上channel 的使用率不佳，造成網路的流量降低。
說明:
(1)以Fig. 1.為例，目前node B 正傳送data給node A，
此時，node C 要傳送data 給除了node B 之外的其它host，
但是，node C 並沒有辦法送出RTS 訊框，因為node C 偵測到目前有node B 正在傳遞data，
因此便要等到node B 傳送完後才能開始嘗試傳送，但是即使node B 目前正在傳送data，
node C 傳送data 給其它host 並不會造成在node A 發生碰撞，其實nodeC 是可以傳送訊息的，
這便是exposed terminal problem。
解決:
802.11 RTS / CTS的機制，有助於解決這個問題只如果節點是同步的，
數據包大小和數據速率是相同的兩個節點的傳輸。
當一個節點聽到一個RTS從鄰近的節點，而不是相應的CTS，
該節點可以推斷，這是一個裸露的節點，是允許傳輸給其他鄰近的節點。
如果節點不同步（或如果包大小不同或數據速率是不同的）
問題可能會出現發送者將CTS或聽不到的ACK數據在傳輸過程中的第二個發件人。
資料來源:
在Ad hoc 無線通訊網路上利用競爭方式的廣播通訊協定-中山大學資工論文-p.5頁-http://etd.lib.nsysu.edu.tw/ETD-db/ETD-sea...3102-154706.pdf
維基百科:http://en.wikipedia.org/wiki/Hidden_node_problem
維基百科:http://en.wikipedia.org/wiki/Exposed_terminal_problem
(1)只有A、C同時發送RTS給B的情況下才會發生碰撞，發生碰撞時會採用二進制指數退回算法,退回下一個隨機時間。
(2)B點要傳送RTS給A，因為距離遠的C是聽不到A回應給B的CTS和ACK的資訊，
但C會聽到B發出去的RTS，所以C知道A不在自己的範圍內。
C發一個RTS給D，D回應CTS給C，D知道B不在傳輸範圍內。
所以C和D可以互相傳送，不受B向A發送干擾。
資料來源:169頁的第一段(簡體字，有興趣的可以自己看)
http://books.google.com.tw/books?id=9-kAI9...s%20nav&f=false
其它補充:
工作站欲傳輸訊框：須一直監聽媒介
RTS與CTS攜帶媒介使用時間資訊(Network Allocate Vector, NAV)
其他工作站使用此時間資訊，NAV，來估計須等待的時間。
使用此法判斷媒介忙碌與否又稱：虛擬載波偵(virtual carrier sense)
資料來源:31頁
http://mail.knu.edu.tw/~gchen/Wireless/chap03.pdf
RTS/CTS & Hidden node problem & IEEE 802.11
RTS/CTS 是否能減少碰撞
是，RTS即Request to Send，CTS 即 Clear to Send，
舉例來說，有A、B兩站台，而B在收到了A的RTS中的NAV(也就是Duration欄位中的時間)
(還有其後的CTS裡面也有NAV)因為RTS, CTS與ACK之間要等待的時間稱為SIFS(短間隔時間)，
而透過競爭媒介所等待的時間稱為DIFS(DCF IFS)，所以當你的站台A送出RTS，
AP回應CTS以後，A就開始丟資料，AP就開始回應ACK, 這些都是在SIFS等待時間內傳送，
沒有啟用該機制的B站則會偵測到虛擬載波的時候不傳送任何訊框, 直到AP傳送回最後一個ACK(正面回應)，
其中的NAV(Duration)即為0，則B站與A站，又回到了媒介競爭模式。
因此可以有效的解決碰撞。
資料來源:
http://dcalab.csie.thu.edu.tw/wiki/index.p...%26_IEEE_802.11
詩詞作品 (2)