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节。