理論上，Wi-Fi Direct屬於純軟體協議，也就是說不需要額外的硬體支援，只要支援802.11g、n或者ac的裝置都可以實現Wi-Fi Direct的基本功能。但一些高階功能，比如Wi-Fi Direct電源管理需要非常精細的定時管理和狀態切換，Concurrent模式需要對多個源MAC地址進行高效的過濾，這些都靠軟體實現會比較費勁。所以不要太指望老裝置通過軟體升級來實現Wi-Fi Direct，就算能實現也是效率低下或者功能殘缺。

基本概念

• Wi-Fi Peer-to-Peer：簡稱P2P，Wi-Fi Direct別名
• P2P Device：支援P2P的裝置，在組協商完成之前都叫P2P Device
• P2P Group Owner：簡稱GO，組協商成為SoftAP的P2P Device稱為P2P GO
• P2P Group Client：簡稱GC，組協商成為Station的P2P Device稱為P2P GC

流程圖

首先，來看一下Wi-Fi Direct連線的詳細流程，下面這張圖涵蓋了Wi-Fi Direct的大部分功能，包括裝置的發現、組協調、認證關聯、WPS以及4次握手。（點選圖片可以檢視大圖 :)）

裝置發現

裝置發現是Wi-Fi Direct最關鍵的一個功能，它包含scan和find兩個了功能。scan是為了快速的發現已有的GO，注意scan是全通道掃描。find又分為search和listen兩個階段，這兩個階段交叉執行，協議建議find持續兩分鐘。search階段和scan類似，區別在於search只掃描1、6、11三個通道，並且對接收到的probe resp和beacon幀要判斷是否包含P2P IE。listen階段隨機在1、6、11三個通道監聽，響應包含P2P IE的probe req。listen的時間為n個100TU（time unit)，802.11規定1TU=1024微秒，約1毫秒，n是一個隨機整數，所以listen持續的時間約為100毫秒的整數倍。這裡隨機數的目的是讓雙方都能發現對方，否則如果雙方剛好同時處於search和listen狀態，那麼永遠也掃描不到對方，而隨機數的出現總能讓雙方快速發現對方。

Listen通道

前面說了Wi-Fi Direct裝置總是在1、6、11通道進行scan和listen，listen通道是在Wi-Fi Direct開啟時隨機生成，工作時固定在這個通道，直到Wi-Fi Direct關閉。有兩個方法可以知道對方的listen通道，一個是通過在哪個通道接收到probe resp來確定，另一個是通過分析probe resp裡的P2P IE，有一個listen channel欄位來確定。一般使用第二種方法，因為有一些不標準的P2P裝置，在scan階段也會回覆probe resp，這樣的話第一種方法就會得到錯誤的Listen通道。

GO協商

發現對方後，下一步就點選進行連線，而連線的第一步要確認各自的角色：誰做GO，誰做GC。Wi-Fi Direct通過增加Action幀的互動來達到此目的，這個互動非常簡單，如下圖如示：

GO協商共包含三個型別的Action幀：GO Req、GO Resp、GO Confirm。GO Req和GO Resp包含GO Intent的IE，是一個0到15的整數值，通過這兩個值的大小來確定GO，具體方法如下圖。如果Intent不相等時，誰大誰做GO；如果相等時且小於15時，根據GO Req的隨機數Tie Breaker來決定，Tie Break為1就自己做GO，否則對方做GO；如果相等且等於15，GO協商失敗，這種情況說明A和B都必須成為GO，誰也不能妥協，那麼只能以失敗告終。

事實上，一般情況下GO協商會有5個幀互動，P2P流程圖已經清晰的展現出來了，一開始會讓人比較迷惑，下面舉例說明。假設有兩個P2P裝置A（Listen通道為1）和B（Listen通道為11），在A的P2P介面點選B進行連線，這時A首先會在11通道傳送GO Req，傳送需要持續一段時間，因為B可能會處於Search狀態，所以持續的時間至少要大於B的Search時間；直到B切換為Listen狀態，才能收到 GO Req，收到後立即在11通道回覆GO Resp並給上層應用傳送對應訊息，應用提示使用者是否同意A的連線。注意B剛剛回復的GO Resp包含的狀態是fail:information is unavailable，A收到這個訊息後不做任何動作，繼續等待。直到使用者點選B的同意後，B會再發起GO Req，由於A是連線發起方，他不用再去提醒使用者同意，直接響應成功的GO Resp。最後B通過GO Confirm確認GO協商結束。

WPS流程

Wi-Fi Direct採用WPS PBC方式來協商金鑰，我們知道當手機和AP進行WPS連線時，需要先按一下AP上的WPS按鈕，再點選手機上的WPS按鍵，兩者會自動建立連線。其實按AP的WPS按鈕的作用是讓他在後續兩分鐘的Beacon幀WPS IE裡置上一個PBC標誌，手機端WPS按鍵用於啟動WPS連線流程，如果掃描到的Beacon幀有PBC標誌就開始連線和WPS金鑰協商。

Wi-Fi Direct省去了WPS按鍵流程，協商為GO的P2P裝置轉換為GO狀態時自動在Beacon幀裡增加PBC標誌，GC也自動啟動WPS連線流程。這裡隱藏著一個問題，如果當前環境有AP剛好處於PBC狀態或者當前有多組P2P裝置在連線，那麼很有可能GC掃描到的AP列表裡有一個以上的AP包含PBC標誌，引起PBC Overlap異常，導致P2P連線失敗。這個問題概率很小，但使用WPS方式的裝置都會存在，需要引起重視，當然P2P可以根據之前GO協商的MAC地址進行區分來避免。

4次握手

WPS流程只是協商出一個公共的Key，這個Key還不能用於資料加密。4次握手的作用是以公共Key為引數協商出PTK和GTK，之後進行加密資料傳輸。

如果仔細看P2P流程圖會發現連線流程執行了兩個auth和associa，在WPS結束後GC發起的deauth沒有在流程圖表現出來。為什麼不繼續4次握手來減少互動次數呢，我覺得這樣做的目的是最大程度的相容原有的Wi-Fi連線流程，投入較少的改動來實現P2P功能。

Wi-Fi Direct已經漸漸的成為手機的標準功能，隨著主流Wi-Fi晶片的支援和越來越多P2P應用的興起，我們可以在更多的應用場景看到他的身影，比如印表機、相機、家用電器，甚至物聯網。

轉載至：http://blog.weenas.com/?p=56