WIFI Direct/WIFI P2P

技术交流有兴趣请加:
 音视频技术交流群:308601278
 无线投屏技术交流群:582349005
 
 本文可在找到相关详细内容 必捷网络|因必捷而简单
 商务合作请至邮件[email protected] 

 

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

1.P2P的模型

WIFI Direct/WIFI P2P_第1张图片

 

图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次握手。

 

WIFI Direct/WIFI P2P_第2张图片

 

图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帧的交互来达到此目的。

 

WIFI Direct/WIFI P2P_第3张图片

 

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

WIFI Direct/WIFI P2P_第4张图片

 

图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交流。

 

 

你可能感兴趣的:(Miracast)