深入理解WIFI P2P ——基本原理

P2P涉及的技术

802.11g及以上规范

为了保证一定的传输速率,P2P要求P2P Device必须支持802.11g及以上的规范。其中,安全部分必须支持WPA2

WIFI Multimedia

也就是WMM,这是一种源自802.11e的QoS服务,主要针对实时音视频数据传输。主要的应用场景就是设备之间共享媒体数据。

Wifi Simple Configuration

也就是WSCP2P Client在关联到GO之前,需要先通过WSC来协商安全信息,所以WSC也是P2P的依赖技术项。

Managed P2P Device Operation

定义了如何在企业级环境中由对应的IT部门来同一配置和管理P2P设备。

P2P Power Management

P2P设备的电源管理有关,用于节省电力损耗。

P2P Discovery

P2P所特有的,用于扫描P2P设备并进行GO协商。也是核心内容。

P2P Group Operation

讲得是GO如何管理一个Group,也就是GO的工作职责。

P2P架构

P2P架构中定义了3个组件,也就是“一个设备,两种角色”。

  • P2P Device:P2P叫中角色的实体,可以把他当做wifi设备。
  • P2P Group Owner:GO是一种角色,其作用类似于Infrastructure BSS中的AP。
  • P2P Client:另一种角色,其作用类似于Infrastructure BSS中的STA。

在组件P2P Group之前,终端都是一个一个的P2P Device。当这些P2P Device设备完成P2P协商后,其中有且仅有一个设备被协商决定来扮演GO角色,而其他的device只能充当Client的角色。

注意:由于GO功能类似于AP,所以周围不支持P2P功能的STA也能发现并关联到GO,这些STA被称为“Legacy Client”。Legacy Client不能处理P2P协议,所以P2P一些特有功能在这些设备中无法实现。

P2P Discovery

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。

Device Discovery

P2P Device Discovery虽然也是利用802.11中的Probe RequestProbe Response帧来搜索周围的P2P设备。为了加快搜索速度, 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 StateListen State之间来回切换。Search State中,P2P Device将发送Probe Request帧,而Listen State中,它将接收其他设备的Probe Request帧并回复Probe Response帧。

Discovery启动后,Device首先进入Scan Phase。在这一阶段,P2P设备在其支持的所有频段上都会发送Probe Request帧。

Scan Phase完成后,Device进入Find Phase。在这一阶段中,Device将在ListenSearch State中切换。根据前面的介绍,每一个设备的Listen Channel在Discovery开始前就已确定。例如,上图Device 1的Listen Channel是1,而Device 2的Listen Channel是6。

P2P规范对Device处于Listen State的时间也有所规定,其时间是100TU的整数倍,倍数值是一个随机数,位于minDiscoverableIntervalmaxDiscoverableInterval之间。这两个值默认为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帧。注意,只有当两个设备处于同一频段时,一方发送的帧才能被对方接收到。

  • ①中为SSID,其取值为”DIRECT-“。”DIRECT-“就是P2P规范中定义的P2P Wildcard SSID。
  • ②中为WSC IE。WSC IE中的Device Name属性表明了发送者的设备名。另外,Probe Request发送者可以利用Primary Device Type属性来搜索指定类型的接收者
  • ③中为P2P IE。和WSC IE一样,它也属于802.11规范中Vendor自定义的IE。OUI取值为0x50-6F-9A-09。其中50-6F-9A是Wi-FiAlliance组织的OUI,09代表P2P。P2P IE的组织结构也是由一个一个的Attribute组成。此处的P2P IE包含P2P Capability和Listen Channel两个属性。

这里不分析具体的帧结构了,如果有需要深入研究,可以直接下载p2p的规范对照看。

这边主要介绍一下listen channel的相关,它代表P2P Device在Listen State时将使用哪个频段:

  • Operating Class:指明Listen State时使用的频率波段的类别,此处为81。
  • Channel Number:指明Listen State使用的频段

比如我们需要强制P2P的Listen State使用11频段,假设此设备扮演GO设备,P2P Group在频段11上工作。那就需要在p2p_supplicant.conf中加入以下的参数:

p2p_oper_reg_class = 81
p2p_oper_channal = 11
p2p_listen_reg_class = 81
p2p_listen_channel = 11

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。

Public Action

GO Negotiation过程中P2P设备会利用一种名为P2P Public Action类型的帧交换信息。

提示 除了GO Negotiation外,P2P InvitationDevice DiscoverabilityProvision Discovery流程也会用到P2P Public Action帧。

GO Negotiation

GO Negotiation: 在这一阶段中, 两个Device要协商好由谁来做GO 。
GO协商共包含三个类型的Action帧:GO ReqGO RespGO Confirm

GNO req

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呢?

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

android平台中,如果收到GON req,将会有弹窗提醒用户进行下一步的连接。

下面说一下GON resp:

GNO resp

GNO confirmation

P2P Group ID用于唯一标示一个P2P Group,该属性必须包含P2P Device Address以及SSID两个字段。其中,SSID的格式遵循如下规则。

  • 开头必须是”DIRECT-xy”,xy为随机的两个大小写字母或数字,例如”2I”。
  • 规范对规定”DIRECT-xy”之后的内容,Android中会加上设备名,例如图中的”DESKTOP-5VBHCUA9172″。

GON流程执行完毕后,P2P Device的角色也就随之确定,下一步的工作就是Provisioning,即交互双方利用WSC来交换安全配置信息

整体流程图

剑气纵横三万里

“为什么要努力?” “想去的地方很远,想要的东西很贵,喜欢的人很优秀,父母的白发,朋友的约定,周围人的嘲笑,以及,天生傲骨。”

留下你的评论

*评论支持代码高亮<pre class="prettyprint linenums">代码</pre>

相关推荐