P2P Discovery的作用很簡單，就是使多個P2P Device能夠互相發現并構建一個Group。根據規范，它包括四個主要技術子項。 * **Device Discovery**：用于P2P設備搜索周圍其他支持P2P的設備。 * **Service Discovery**：該Device Discovery基礎上，P2P還支持搜索指定的服務。這部分功能屬于可選項，筆者覺得它和2.2.5節中提到的Bonjour類似。 * **Group Formation**：用于決定兩個P2P Device誰來扮演GO，誰來扮演Client。 * **P2P Invitation**：用于激活一個Persistent Group（見下文解釋），或者用于邀請一個Client加入一個當前已存在的Group。 >[info] 提示　Group分Persistent（永久性）Group和Temporary（臨時性）Group兩種。我們舉兩個簡單例子來說明二者的區別。 Temporary Group：當有文件要傳給一個同事時，雙方打開手機的Wi-Fi P2P功能，建立一個Group，然后傳輸文件，最后關閉Wi-Fi P2P。在這個過程中，GO和Client的角色分配由GroupFormation來決定，這一次的GO可能是你的設備，下一次則可能是其他人的設備。對于這種Group，在建立Group過程中所涉及的安全配置信息以及和Group相關的信息（以后會見到它）都是臨時的，即下一次再組建Group時，這些安全配置信息都將發生變化。 Persistent Group：在這種Group中，GO由指定設備來扮演，而且安全配置信息及Group相關信息一旦生成，后續就不會再發生變化（除非用戶重新設置）。Persistent Group中的GO多見于固定用途的設備，例如打印機等。如此，除了第一次通過P2P連接到打印機時相對麻煩一點（需要利用WSC協商安全配置信息）外，后續使用的話，由于P2P設備將保存這些安全信息，所以下次再使用打印機時就能利用這些信息直接和打印機進行關聯了。 由于篇幅關系，本章僅介紹上述四個知識點中最基礎的Device Discovery和GroupFormation，而Service Discovery和P2P Invitation的內容請讀者學習完本章后再仔細研讀P2P規范。 **1、Device Discovery介紹** P2P Device Discovery雖然也是利用802.11中的Probe Request和Probe Response幀來搜索周圍的P2P設備，但其步驟卻比Infrastructure BSS中的無線網絡搜索要復雜。舉一個簡單的例子，一個P2P Device除了自己要發送Probe Request幀外，還得接收來自其他設備的Probe Request幀并回復Probe Response幀。而在Infrastructure BSS中，只有AP會發送Probe Response幀。 為了加快搜索速度，P2P為Device Discovery定義了兩個狀態和兩個階段。 **①、Device Discovery工作流程** 先來看兩個狀態，分別如下。 * Search State：在該狀態中，P2P Device將在2.4GHz的1，6，11頻段上分別發送Probe Request幀。這幾個頻段稱為Social Channels。為了區別非P2P的Probe Request幀，P2P Device Discovery要求必須在Probe Request幀中包含P2P IE。 * Listen State：在該狀態中，P2P Device將隨機選擇在1，6，11頻段中的一個頻段（被選中的頻段稱為Listen Channel）監聽Probe Request幀并回復Probe Response幀。值得指出的是，Listen Channel一旦選擇好后，在整個P2P Discovery階段就不能更改。另外，在這個階段中，P2PDevice只處理包含P2P IE信息的Probe Request幀。 再來看兩個階段，分別如下。 * Scan Phase：掃描階段。這一階段和前面章節介紹的無線網絡掃描一樣，P2P Device會在各個頻段上發送Probe Request幀（主動掃描）。P2P Device在這一階段中不會處理來自其他設備的Probe Request幀。這一階段過后，P2P Device將進入下一個階段，即Find Phase。 * Find Phase：雖然從中文翻譯來看，Scan和Find意思比較接近，但P2P的Find Phase卻和Scan Phase大不相同。在這一階段中，P2P Device將在Search State和Listen State之間來回切換。SearchState中，P2P Device將發送Probe Request幀，而Listen State中，它將接收其他設備的Probe Request幀并回復Probe Response幀。 圖7-3所示為兩個P2P Device的Discovery流程。 * Discovery啟動后，Device首先進入Scan Phase。在這一階段，P2P設備在其支持的所有頻段上都會發送Probe Request幀。 * Scan Phase完成后，Device進入Find Phase。在這一階段中，Device將在Listen和Search State中切換。根據前面的介紹，每一個設備的Listen Channel在Discovery開始前就已確定。例如，圖7-3中Device 1的Listen Channel是1，而Device 2的Listen Channel是6。 圖7-3所示為P2P Device Discovery的流程示意圖。 :-:  圖7-3 P2P Device Discovery流程示意圖 在Find Phase中，P2P規范對Device處于Listen State的時間也有所規定，其時間是100TU的整數倍，倍數值是一個隨機數，位于minDiscoverableInterval和maxDiscoverableInterval之間。這兩個值默認為1和3，而廠商可以修改。選擇隨機倍數的原因是為了防止兩個Device進入所謂的Lock-Step怪圈，即兩個Device同時進入Listen State，等待相同的時間后又同時進入Search State。如此，雙方都無法處理對方的Probe Request信息（Search State中，Device只發送Probe Request）。圖7-3中，Device 1第一次在Listen State中待了2個100TU，而第二次在Listen State中待了1個100TU。 當Device處于Find Phase中的Search State時，它將在1,6,11頻段上發送Probe Request幀。注意，只有當兩個設備處于同一頻段時，一方發送的幀才能被對方接收到。 >[info] 提示：P2P規范對兩個狀態及兩個階段的描述非常細致，甚至于對每個狀態能干什么和不能干什么都有詳細說明。不過，從如何快速掌握P2P框架的角度來看，筆者覺得這些內容過于啰嗦。 了解了Device Discovery的大體工作流程后，下面我們將通過實例來看看P2P使用到的Probe Request和Probe Response幀。 **②、Probe Request幀設置** 圖7-4所示為Galaxy Note 2在測試P2P功能時發送的Probe Request幀。 :-:  圖7-4　P2P Probe Request幀實例 圖7-4所示的P2P Probe Request幀實例中有三個地方（用黑框標明）值得注意。 * ①中為SSID，其取值為"DIRECT-"。大家不要小看它，"DIRECT-"就是P2P規范中定義的P2P Wildcard SSID。 * ②中為WSC IE。WSC IE中的Device Name屬性表明了發送者的設備名。另外，Probe Request發送者可以利用Primary Device Type屬性來搜索指定類型的接收者（相關內容，讀者可參考第6章“Configuration Methods和Primary Device Type屬性”）。 * ③中為P2P IE。和WSC IE一樣，它也屬于802.11規范中Vendor自定義的IE（Element ID取值為221，參考6.3.1節WSC IE和Attribute介紹）。OUI取值為0x50-6F-9A-09。其中50-6F-9A是Wi-FiAlliance組織的OUI，09代表P2P。P2P IE的組織結構也是由一個一個的Attribute組成。此處的P2P IE包含P2P Capability和Listen Channel兩個屬性，其詳情見下文。 圖7-4所示的P2P IE中包含了P2P Capability和Listen Channel兩個屬性。其中，P2P Capability的示例如圖7-5所示。 圖7-5中所示的P2P Capability屬性表示設備對P2P各種特性支持的情況。它分為Device Capability Bitmap和Group Capability Bitmap兩項考核指標。這兩個Capability Bitmap長度都為1字節，每一位都代表一種P2P特性（這也是它們的名稱中都帶有Bitmap一詞的原因）。表7-1和表7-2分別展示了這兩個Capability中每一位的含義。 :-:  圖7-5　P2P Capability示例 :-:  表7-1 Device Capability Bitmap各個位的作用 表7-1中的P2P Client Discoverability對應于下面所述的應用場景。 * P2P Device A已經加入了一個P2P Group 1。在Group 1中，它扮演Client的角色。 * P2P Device B（不在Group 1中）指定搜索P2P Device A。由于Device A已經扮演了Client的角色，所以它不會回復Probe Response。不過，Group 1的GO卻存儲有當前與它關聯的Client信息，即Group 1的GO了解Device A的信息。 * 如果Device A支持Client Discoverability，那么Group 1的GO、Device A以及Device B將借助Device Discoverability Request/Response幀來獲取相關信息。這部分流程比較復雜，感興趣的讀者不妨閱讀參考資料[2]。 >[info] 注意　通過上面關于P2P Client Discoverability的描述可知，P2P Device Discovery的內容遠比圖7-3所示的流程復雜。實際上，圖7-3描述的只是P2P Device Discovery的一種情況。P2P規范中介紹的Device Discovery一共包含有如下幾種情況。 > * 圖7-3所示的兩個P2P Device搜索，這兩個Device都支持P2P并且當前都沒有加入P2PGroup。 > * 一個未加入Group的P2P Device搜索位于某個P2P Group中的GO。 > * 一個未加入Group的P2P Device搜索位于某個P2P Group中的Client。 > * Legacy Client搜索P2P Group中的GO。 > * 一個P2P Device搜索另一個已經加入某個Infrastructure BSS的Device（通過Concurrent Operation來同時支持P2P和STA）。 > * GO搜索周圍的P2P Device和Services。 > > 本章將只分析第一種情況，感興趣的讀者請在學完本章后再研究其他幾種情況。 表7-2所示為Group Capability Bitmap各個位的作用。 :-:  :-:  圖7-6　Listen Channel屬性 接著來看Listen Channel屬性，它代表P2P Device在Listen State時將使用哪個頻段，其內容如圖7-6所示。可知包含三個字段。 * Country String：該字段長3字節。其中，前兩字節表示國家碼（圖7-6中的"XX"代表noncountry entity，該值表示當前沒有明確的國家）。最后一字節的“04”表示后面的Operating Class定義需參考資料[5]中的表J-4。 * Operating Class：指明Listen State時使用的頻率波段的類別，此處為81。 * Channel Number：指明Listen State使用的頻段。 >[info] 提示　根據參考資料[5]的表J-4（圖7-7），Operating Class 81表示頻段的起始頻率是2.407GHz，分為13個頻段，每個頻段的間隔為25MHz。另外，表J-1定義了美國的Operating Class，表J-2定義了歐洲的Operating Class，表J-3定義了日本的Operating Class，表J-4定義了其他國家的Operating Class情況。 :-:  圖7-7　表J-4截圖 >[info] 特別注意　P2P IE還定義了一個名為Operating Channel的屬性，其組成結構和Listen Channel完全一樣，但含義卻大不相同。Operating Channel表示假設該設備扮演GO，則由它組建的P2P Group將在哪個頻段上工作。并且其頻段不限于Social Channels中指定的那三個頻段。 除了包含P2P Capability和Listen Channel兩個屬性外，Probe Request中的P2P IE還可以包含其他一些屬性。這部分知識見參考資料[6]。 最后，總結P2P規范中對Probe Request幀的要求。 * SSID IE必須設置為P2P Wildcard SSID，即"DIRECT-"。 * 必須包含P2P IE。 * 802.11 MAC幀頭的地址域[^①]中，Destination Address域（Address1）必須為廣播地址（FF：FF：FF：FF：FF：FF）或者為目標設備的P2P Device Address（特別注意，詳情見下文），BSSID域（Address3）必須為廣播地址。 >[info] 特別注意　P2P規范定義了兩種類型的地址，一種是P2P Device Address，另外一種是P2P Interface Address。一個P2P Device在加入P2P Group前，將使用Device Address開展Device Discovery等工作。對一個P2P Device而言，其P2P Device Address是唯一的（作用等同于MAC地址）。而當P2P Device加入P2P Group后，它和Group中其他成員交互時將使用P2P Interface Address。另外，由于一個P2P Device可同時加入多個P2P Group，所以在每個P2P Group中，該設備必須使用不同的P2P Interface Address。最后，當一個Group結束后，Device在該Group中使用的P2P Interface Address也就相應作廢了。一般而言，P2P Device Address和P2P Interface Address不同。以筆者的Galaxy Note 2為例，其P2P Device Address為92：18：7c：69：88：e2，而P2PInterface Address為92：18：7c：69：08：e2。 接著來看Probe Response幀。 **③、Probe Response幀設置** 圖7-8所示的P2P Probe Response幀包含WSC IE和P2P IE。在P2P IE中，除了有P2P Capability屬性外，還包含一個名為P2P Device Info的屬性。P2P Device Info用于描述發送設備的一些情況。示例中，該屬性的取值如圖7-9所示。 :-:  圖7-8　P2P Probe Response幀示例 :-:  圖7-9　P2P Device Info示例 仔細觀察圖7-9，讀者會發現，P2P Device Info包含了一些第6章介紹WSC時提到的屬性，例如Primary Device Type、Config Methods等。關于WSC屬性，可回顧第6章WSC IE和Attribute的相關介紹。P2P Device address字段用來描述發送設備的P2P Device Address。 >[info] 注意　圖7-9中所示的WSC屬性中，Primary Device Type和Config Methods這兩個屬性沒有包含對應的Attribute ID以及Length字段，只包含了Value字段，而Device Name屬性則包含了Attribute ID、Length以及Value字段。 以上介紹了P2P Device Discovery的流程及相關的Probe Request/Response幀和P2P IE等內容。值得指出的是，本節是以兩個未加入P2P Group的P2P Device互相搜索為例來介紹DeviceDiscovery流程的，它屬于P2P規范Device Discovery各種case中較簡單的一種。 >[info] 提示　根據筆者閱讀P2P規范的心得，P2P Device Discovery實際所包含的內容非常豐富，而且難度比較大。在此，建議讀者在學完本章后再去研讀P2P規范。 **2、Group Formation介紹** 當P2P Device A通過Device Discovery找到周圍的一個P2P Device B后，Device A就可以開展Group Formation流程以準備構造一個P2P Group。Group Formation也包含兩個階段，分別如下。 * **GO Negotiation**：在這一階段中，兩個Device要協商好由誰來做GO。 * **Provisioning**：GO和Client角色確定后，兩個Device要借助WSC來交換安全配置信息。此后，Client就可以利用安全配置信息關聯上GO。這個流程和第6章介紹的WSC流程一樣，這部分內容請讀者參考第6章。 GO Negotiation過程中P2P設備會利用一種名為P2P Public Action類型的幀交換信息，所以下面先來認識一下P2P Public Action幀。 >[info] 提示　除了GO Negotiation外，P2P Invitation、Device Discoverability和Provision Discovery流程也會用到P2P Public Action幀。 **①、P2P Public Action幀** Action幀是802.11管理幀的一種，其Type和SubType取值可參考3.3.5節幀類型、From/To DS介紹。Action幀的作用如其名稱中的"Action"所示，發送方利用Action幀攜帶一些請求信息，從而使得接收方能對應進行一些處理。 Action幀Frame Body的結構比較簡單，僅包含Category和Action Detail兩個部分，ActionDetail隨Category的不同而變化。常用的Category[7]如下。 * 值為0，表示Spectrum Management，用于Spectrum Measurement。 * 值為4，表示Public，P2P規范會使用這種類型的Action幀。 * 值為5，表示Radio Management，它和Radio Measurement有關。 * 值為127，表示Vendor Specific，它和具體的廠商有關。P2P規范也會使用這種類型的Action幀。 如上所述，P2P將使用Public Action和Vendor Specific這兩種類型的Action幀。本節先介紹其中的Public Action幀。 802.11中Public Action幀又有多種子類型，而P2P屬于Public Action中的Vendor Specific子類型。P2P使用的Action幀Frame Body的組成結構如表7-3所示。 :-:  :-:  表7-3 P2P Public Action結構 表7-4所示為OUI Subtype取值，不同的Subtype代表不同的P2P Public Action幀。 :-:  表 7-4 OUI Subtype取值 下面來看GO Negotiation流程，包含三次P2P Public Action幀交換。 **②、GO Negotiation流程** 圖7-10為GO Negotiation涉及的三次幀交換流程。 :-:  圖7-10　GO Negotiation流程 由圖7-10可知，GO Negotiation（以后簡稱GON）流程包括GON Request、GON Response和GON Confirmation三次幀交換。這三次幀交換并不涉及什么復雜的計算，只是雙方交換一些信息，從而誰來扮演GO。另外，圖7-10也列出了這三個幀中可包含的一些P2P和WSC屬性信息。 下面將直接分析這三個幀的內容。 * 1）首先是GON Request，實例如圖7-11所示。GON Request幀中P2P IE包含了一些之前沒有提到的屬性，下面分別介紹。 首先是GO Intent屬性，該屬性代表發送設備扮演GO的渴望程度，其內部包含一個名為GO Intent的字段。該字段長1字節，目前使用的僅是該字節的前八位。 :-:  圖7-11　GON Request實例 :-:  圖7-12　GO Intent屬性 圖7-12所示為圖7-11中GO Intent屬性的取值情況。 * 第0位叫做"Tie Breaker"（意思為決勝因素），Tie Breaker的取值為隨機的0或1。 * 第1～7位為Intent值，取值為0～15。值越高，代表越想成為GO。15表示該發送設備必須充當GO的角色。Intent默認值為7。 在GON三次幀交換中，GON Request和GON Response都攜帶GO Intent，分別代表了交互雙方想成為GO的渴望程度，那么到底誰會成為GO呢？為此，規范制訂了一個游戲規則，如圖7-13所示。 :-:  圖7-13　GO角色扮演規則 由圖7-13可知： * 如果Device A的GO Intent小于Device B的GO Intent，則Device B將成為GO。 * 一般情況下，Device A和Device B的GO Intent都將使用默認值（值為7）。這種情況下，TieBreaker的取值是關鍵，該字段值為1的Device A將成為GO。由于Tie Breaker為隨機值，所以兩個設備的Tie Breaker取值相同的幾率非常低。 * “一山不能容二虎”，如果兩個設備都想扮演GO（如GO Intent都為15），則GON失敗，誰都成為不了GO。 來看GON Request幀中第二個P2P屬性Configuration Timeout，該屬性實例如圖7-14所示。Configuration Timeout屬性包含兩個長度為1字節的字段，分別是GO Configuration Timeout和Client Configuration Timeout，它們表明Device進入GO或Client角色的超時時間（這兩個字段的取值為10ms的倍數）。 例如，圖7-14中的GO Configuration Timeout字段取值為100，對應超時時間為1000ms，表示Device如果要扮演GO的話，必須在1秒內完成相關準備工作。 :-:  圖7-14　Configuration Timeout屬性 :-:  圖7-15　Channel List屬性 下面來看Channel List屬性，它代表發送設備支持的Wi-Fi頻段信息，圖7-15所示為此屬性的實例。 Channel List屬性的組成比較簡單，包括一個Country String和一個或多個Channel信息。由于筆者的Galaxy Note 2同時支持2.4GHz（對于Operating Class為81）和5GHz（對于Operating Class為124）兩個頻段，所以Channel List包含了兩個Channel信息。 >[info] 提示　圖7-15中Channel List字段中列舉的是十六進制的頻道號。其中，5GHz段包含4個頻道，分別是149（0x95）、153（0x99）、157（0x9D）和161（0xA1）。關于這些信息見參考資料[5]。 圖7-11中最后一個比較重要的屬性就是Intended P2P Interface Address，代表P2P設備加入Group后將使用的MAC地址。 在Android平臺中，當某個設備收到GON Request幀后，將彈出一個如圖7-16所示的提示框以提醒用戶。如果用戶選擇“接受”，則系統將繼續后續的工作，否則將終止Group Formation流程。 :-:  圖7-16　GON Request接收者提示框 * 2）接著來看GON Response幀，圖7-17為實例。GON Response幀也包含一些新的P2P屬性。首先來看其中的Status屬性，該屬性代表某一個Action幀的處理結果，值為0表示處理成功，其他值表示失敗。 另一個比較重要的屬性是P2P Group ID，其實例如圖7-18所示。P2P Group ID用于唯一標示一個P2P Group，該屬性必須包含P2P Device Address以及SSID兩個字段。其中，SSID的格式遵循如下規則。 * 開頭必須是"DIRECT-xy"，xy為隨機的兩個大小寫字母或數字，例如"ny"。 * 規范對規定"DIRECT-xy"之后的內容，Android中會加上設備名，例如圖中的"Android_4aa9"。 :-:  圖7-17　GON Response幀實例 :-:  圖7-18　P2P Group ID屬性 >[info] 注意　只有會成為GO的P2P Device在其發送的Group Response幀中才會包含P2P Group屬性。 * 3）最后看GON Confirmation幀，它是對GON Response的確認。圖7-19為GON Confirmation幀實例。 :-:  圖7-19　GON Confirmation幀實例 圖7-19所示的GON Confirmation幀比較簡單。不過，如果發送者將扮演GO角色，其發送的GON Confirmation幀必須包含P2P Group ID屬性。 >[info] 提示　P2P規范對GON三個幀包含的P2P屬性及WSC屬性都有明確要求，讀者可通過參考資料[8]來學習相關知識。 GON流程執行完畢后，P2P Device的角色也就隨之確定，下一步的工作就是Provisioning，即交互雙方利用WSC來交換安全配置信息，這部分工作在第6章已經詳細介紹過了，此處不贅述。細心的讀者可能會發現，P2P Public Action幀中還存在著"Provision DiscoveryRequest/Response"類型的幀，它們是干什么用的呢？來看下文。 **③、Provision Discovery介紹** Provision Discovery也和WSC有關。第6章中曾介紹WSC中的Configuration Methods屬性，它代表了Wi-Fi設備所支持的WSC配置方法。WSC定義了一共13種配置方法。圖7-20是該屬性的內容。 :-:  圖7-20　Config Method屬性 了解上述信息后，請讀者思考一個問題。兩個P2P Device如何知道對方使用的是哪種WSC配置方法呢？顯然，如果雙方使用不同的WSC配置方法，這個Group就無法建立。 為了解決這個問題，P2P規范定義了Provision Discovery（PD）流程，該流程就是為了確定交互雙方使用的WSC方法。 Provision Discovery包含PD Request和PD Response兩次幀交換，其中起到決定作用的信息是WSC IE的Config Method屬性。圖7-21所示為PD Request和PD Response幀實例。 :-:  圖7-21　PD Request/Response幀實例 圖7-21中的左圖為PD Request幀，右圖是PD Response幀。根據P2P規范： * PD Request幀的發送者在WSC IE的Config Method屬性中設置想使用的WSC配置方法，注意，一次只能設置一種WSC配置方法。圖7-21的PD Request幀發送者使用了Push Button方法。 * PD Request幀的接收者如果支持PD Request幀發送者設置的WSC配置方法，則它將在回復的PD Response幀中對應設置該WSC配置方法。例如圖7-21的右圖也設置了Push Button位，表示PD Response幀發送者支持PBC。 * 如果PD Request幀的接收者不支持發送者設置的WSC配置方法，它回復的PD Response幀中，Config Method值為0。這樣，PD Request幀發送者將重新選擇一種新的配置方法，然后再次通過PD Request幀向對方發起請求以判斷對方是否支持這個新的配置方法。 簡而言之，如果PD Request接收者支持發送者設置的WSC配置方法，則它在PD Response幀中將設置相同的Config Method屬性值，否則設置Config Method值為0。 >[info] 提示　讓筆者頗感納悶的一件事情是，當PD Request接收者不支持發送者設置的WSC配置方法時，它為什么不在PD Response幀中設置Config Method為自己所支持的WSC方法，而僅是通過設置Config Method值為0來簡單告訴發送者其設置的配置方法無效呢？感興趣的讀者不妨對此問題展開討論。 由于WSC配置需要用戶參與，所以PD另外一個作用就是提醒用戶執行相應的動作。例如讓用戶輸入PIN碼等。 注意，Provision Discovery不屬于Group Formation，它的出現是為了解決如下所述的一個問題。 為了達到最好的用戶體驗，P2P規范要求Group Formation（即GON和Provisioning兩個部分）須在15秒內完成。但WSC安全配置往往需要用戶參與（例如輸入PIN碼）。這些操作比較費時，所以WSC規范（Provisioning遵守WSC規范）對此設置的時間限制是2分鐘。也就是說，光Group Formation中的Provisioning就可能耗費最長2分鐘。如何解決2分鐘和15秒之間的矛盾 呢？P2P規范提出了Provision Discovery這一方法，其作用如下。 * PD用于Group Formation之前，以提前邀請用戶輸入WSC安全配置所需信息（例如讓用戶輸入PIN碼等）。 * PD獲取的安全信息（如PIN碼）可直接用于后續Group Formation的Provisioning，從而避免了在Provisioning過程中讓用戶輸入PIN碼。 根據規范，Group Formation只包含兩個部分。 * GO Negotiation，在此過程中，P2P Device將利用GO Intent來確定誰將扮演GO，誰將扮演Client。GO Negotiation涉及三次幀GON幀交換。 * GO和Client角色確定后就相當于確定了Infrastructure BSS中的AP和STA，下一步工作就是雙方通過WSC流程交換安全配置信息。在P2P中，該部分稱為Provisioning。 Provision Discovery是為了加快Group Formation速度而設計的一種方法，它能在GroupFormation正式開始前通知用戶輸入與WSC安全配置相關的信息。 [^①]:關于MAC幀頭地址域，以及管理幀的地址域情況，參考3.3.5節。