[转载]WIFI Direct/WIFI P2P

上节说过了网卡的选型，之所以网卡的选型如此重要，主要是因为Miracast网卡相比较于普通的网卡多了个P2P功能，底层可靠了，才能很好的进行接下来的上层开发，如果我们已经有了可靠的P2P网卡以及网卡驱动，那我们接下来就可以先进行P2P部分上层代码的开发啦。

1.P2P的模型

 

图1 p2p的基本模型

P2P Group Owner: 类似AP功能，控制Wi-Fi P2P组，能让支持P2P的设备连接上。
P2P Client：连接GO的设备。

 

2一对一时候的流程

• scan阶段：两个设备均对外发送Probe Req请求帧，搜集周围所有设备或网络信息，但是设备不会响应Probe Req请求帧。
• find阶段:主要把包括listen和search两种，listen的时候p2p设备选择一个随机的间隔(默认值分别是1和3次100TU)。p2p设备再用这个随机的间隔在social频段上监听。接收匹配参数的Probe Req，并发送一个Probe res。
• search态的时候：搜索social频段，在social频段发送probe req信息，此信息包含要search的Requested设备类型，设备ID。
• group formation阶段按：GO协商：p2p设备初始化group formation或者响应来自另一个p2p设备的go协商req，GO向GC发送beacon帧，authentication，association，以及WSC和4次握手。

 

 

图2 p2p一对一流程

 

 

 

两个P2P设备互相discover，最终频率锁定在ch6上，在device1的listen段进行group形成。

图2所示为两个P2P Device的Discovery流程，其中：

 

• Discovery启动后，Device首先进入Scan Phase。在这一阶段，P2P设备在其支持的所有频段上都会发送Probe Request帧。
• Scan Phase完成后，Device进入Find Phase。在这一阶段中，Device将在Listen和Search State中切换。根据前面的介绍，每一个设备的Listen Channel在Discovery开始前就已确定。中Device 1的Listen Channel是1，而Device 2的Listen Channel是6。
• 在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）。图中，Device 1第一次在Listen State中待了2个100TU，而第二次在Listen State中待了1个100TU。
• 当Device处于Find Phase中的Search State时，它将在1,6,11频段上发送Probe Request帧。注意，只有当两个设备处于同一频段时，一方发送的帧才能被对方接收到。
• GO协商
• 发现对方后，下一步就点击进行连接，而连接的第一步就是确认各自的角色，谁做GO，谁做GC，WiFi direct通过增加ACTION帧的交互来达到此目的。

 

 

图3 WFD的GO协商过程

 

 

 

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，谁也不能妥协，那么只能以失败告终。

 

图4 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协商结束。

3.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.4次握手
WPS流程只是协商出一个公共的Key，这个Key还不能用于数据加密。4次握手的作用是以公共Key为参数协商出PTK和GTK，之后进行加密数据传输。
P2P流程图连接流程执行了两个auth和associa，在WPS结束后GC发起的deauth没有在流程图表现出来。为什么不继续4次握手来减少交互次数呢，这样做的目的是最大程度的兼容原有的Wi-Fi连接流程，投入较少的改动来实现P2P功能。

 

5.一对多时候的流程
一对多流程与一对一部分的流程比较相似，不做过多介绍了。

 

对DLNA/Airplay/Miracast/Widi感兴趣的同学可进QQ群 582349005交流。