如圖 2-5 所示，節點 B 正在傳輸訊息給節點 A，接著節點 C 也企圖 傳輸訊息給節點 D，然而既然節點 C 可以感測到節點 B 的訊號能量與傳 輸行為，節點 C 就會等到節點 B 的傳輸行為結束，才繼續進行與節點 D 的傳輸行為。但理論上，節點B 與 A 之間的通訊行為，以及節點 C 與 D 之間的通訊行為，兩者應該彼此獨立，且同時發生，這類無效率的通道使 用，即是無遮蔽節點問題。
即便是小規模的點對點網路，都會因為使用相同的頻道，而遇到上述 的問題，首先，隱藏節點導致的封包碰撞難以偵測甚至是避免，因為無線 收發器(wireless transceiver)通常只允許半雙工（half-duplex），無法通時 收發資料，因而有許多的研究往全雙工以及多重頻道（multi-channel）的 方向出發，想要避免相關的問題，截至目前為止，比較成熟的處理機制為 RTS/CTS 淨空機制（RTS/CTS clearing procedure），下一節會有進一步的 討論。
再來即是無遮蔽節點所造成的無效率頻道使用，其實這與隱藏節點問
題一樣，都是由於所有的網路節點都使用相同的頻道，對於頻道空間而 言，這些網路行為太過擁擠，造成效率的低落。
而我們交通控制系統，若使用同一頻道通訊，則會因為市區道路的建 築物遮蔽了部份的頻道能量，更突顯了上述問題，對我們的網路系統所造 成的衝擊。本論文即是為了解決上述的問題，而提出了新的改善辦法，藉 以提昇網路品質，完成可靠的通訊介面。
2.4 RTS/CTS 淨空程序
這個機制使用了 RTS(Request to Send)訊框還有 CTS(Clear to Send)訊 框，使用 RTS 訊框基本上有兩個目的：預約頻道的使用權，並且令收到 的此訊框的非目地工作站，停止網路傳輸行為。以圖2-6 為例，節點 A 發 出了 RTS 訊框，接收端節點 B 以 CTS 訊框回應，如同 RTS 封包，CTS 也會要求接收範圍內的其他工作站（如節點C）保持靜默，一旦完成了了 這兩個訊框的交換程序，表示節點 A 與節點 B 附近的工作站知道媒體已 經被保留，因而訊框的傳送就可以進行而不會受到干擾。
圖2-6：RTS/CTS 淨空程序示意圖
然而我們可以發現節點 C 在這個程序裡面，沒有任何的網路行為，
亦即 RTS/CTS 機制只能解決隱藏節點的問題，對同頻道下的無遮蔽節點 問題，卻無能為力。因此，我們可以瞭解，RTS/CTS 淨空程序只能大致 改善小型點對點網路的網路品質，但對於較大型且為數眾多的點對點網路 而言，並無法增進頻道空間的有效使用。而且使用了 RTS/CTS 程序，實 際的傳輸過程也會因為多了些程序而造成延遲，以及頻寬消耗，因而本論 文，在第四章會針對交通控制系統架構下的網路品質問題，提出以 CAP 方法搭配AODV 繞徑協定的頻道使用方式。