一、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
詩詞作品 (2)