android wifi aware,WifiAware实现及协议模型

一协议介绍

wifiAware即Neighbor Awareness Networking(NAN), 为wifi联盟基于802.11协议之上定制的相邻设备发现协议.html

以上为一个标准的NAN集合, 集合内部包含了若干已经关联的设备.(这里的关联不是指wifi AP-STA的那种关联, 仅是构建一个基本集合, 并无association request/response).android

为了以高能效不断地执行发现功能,Wi-Fi Aware 吸收了与低占空比“介质访问控制(Medium Access Control,简称MAC)”协议和自适应集群有关的工做成果。Wi-Fi Aware 经过协议创建公共“时钟”,以保持全部节点都接受相同的时间调度,所以下降了能耗,同时该技术还有足够强的应对变化的能力,即便某个设备移动到可及范围之外,也能保持群组不受影响。简而言之, 就好像是将组内的成员按期汇集汇集到一次开会并同步信息, 只不过cluster内同步的信息简洁, 会议的时间也只不过几十上百毫秒.安全

Wi-Fi Aware 设备无需经过 Wi-Fi 接入点(AP),就可自主检测、提醒和链接其余设备。Wi-Fi Aware 应用能够配置为,提醒用户,附近有运行相同应用的设备。发现功能能够基于距离等各类参数执行,例如,当另外一个运行相同应用的设备距离不到 10 英尺(约 3.048 米)远时,提醒用户。应用也能够配置为,创建与另外一个设备点对点的安全数据链接,以进行应用数据交换。数据结构

Wifiaware不影响设备使用P2P或STA功能.架构

二设备发现和加入

(1)发现

根据协议介绍, 设备发现为被动的接收已经存在的cluster按期发布的beacon来加入已经存在的cluster. 同时为了节省信道资源, Beacon discovery仅仅在6ch发送. 5G信道为wifiaware中的可选操做, 当工做在5G信道时, 低频扫描信道固定为44ch, 高频扫描固定为149信道, 低频高频都支持的设备, 扫描固定在149ch. 此外, 协议规定, 不只Beacon能够做为让NAN device发现cluster的信标帧, 包含NAN信息的probe response也可让NAN device发现cluster. (Probe response在什么场景下发送, 协议中没有明确的规定).oop

这里有一个问题, 想要加入一个cluster的NAN device能够经过接收Beacon discovery来加入cluster. 若是当前环境中没有任何cluster存在, 岂不是存在全部NAN device一直处于被动扫描状态? 这一点协议中提供了将两个cluster合并的操做和单个设备建立cluster的实现, 以下加密

协议中隐晦的代表, 当一个NAN设备准备加入一个cluster中时, 会进行被动扫描且可能建立一个cluster. (当时读协议的时候纠结这个问题，再协议里找了2天才发现这句话)以下:spa

Upon activating NAN functionality, a NAN Device shall perform passive scanning and may start a NAN Cluster.code

(2) 加入cluster

当一个单独的device设备收到probe response时, 会根据收到的probe response中的time offset在cluster的DW时间中wake up, 便可在cluster中交换信息. (beacon可能会因为cluster中的设备数量致使超出设置的阀值致使被丢弃, 具体情景须要再研究).orm

Cluster合并就是当两个cluster处于互相发现的状况下, 低cluster grade的将合并入高cluster grade的cluster中. 并在加入新cluster前发送NAN sync beacon告知其它NAN加入新的cluster.

最终获得的cluster初步构成了一个小型的服务集合, 能够经过互相发送action帧来获取详情的服务内容. 也达成了适合IOT的基本单元(相似局域网, 不过这里cluster的结构相似数据结构中的图, 而局域网更像是树).

一个NAN device能够加入多个cluster.当NAN device处于两个cluster的发现范围内, 那么加入两个或多个cluster成为了可能.

(3) Cluster管理

Cluster中分别有三种角色, master, sync, normal.

这三个角色分别承担cluster中的各个角色功能:

Master发送NAN sync beacon和 NAN discovery beacon

Sync仅仅在DW内传送NAN sync beacon

Normal角色什么beacon也不发送(服务发现帧是会发送的).

三个角色之间能够互相转换, 转换的因素不少. 这里很少赘述. 能够参考wifiaware协议3.3. Sync beacon在每一个DW内最多发送一次, 主要用于同步cluster内的时钟. Discovery beacon同一master角色下的50TUS - 200TUS内被当前master发送一次. Master角色更换后, 会不会沿用以前的时间间隔.

三服务发现协议

Wi-Fi Aware 设备上的应用利用“发布型(Publish)”和“订阅型(Subscribe)”消息交换信息。Wi-Fi Aware 服务经过订阅(搜索)发现其余服务,经过发布(发送)广播表示其存在的信息和提供的内容。一旦检测到设备和想要的服务,发出检测的设备就可向这些检测到的设备发送提示信息。

DW是cluster后所出的时间周期和信道, 是标识这个cluster的基本属性. 基本就是在DW期间, cluster内的各个设备会发送一个同步信标, 而后能够进行服务发现请求. DW结束, 全部设备进入休眠状态, 只有cluster的master会发送6ch的beacon discovery. (这里的休眠仅仅是指再也不进行wifi aware服务, 而不是真正的sleep. DW以外的时间是进行数据交互或P2P/wifi数据交换的时间段)

在一个同步的集群中,全部设备之间都要针对发现窗口进行时间同步(上图)。同步集群是同步至同一发现窗口的一组 Wi-Fi Aware 设备。创建与同步集群的链接以后,设备发送订阅型和发布型消息,在附近寻找感兴趣的设备。

为一个同步的集群保持时序的设备称为“锚定主设备(Anchor Master)”,设备之间会交替承担“锚定主设备”的角色。

Publish: 主动广告或回复subscribe消息.

Subscribe: 主动探测cluster内的其余设备可用的serivce, 使其回应publish, 被动等待符合上层请求的publish消息回复上层应用.

Follow-up: 传送/接收服务的特定信息.

主动publish对应被动subscribe:

被动publish对应主动subcribe:

四数据传输

在服务发现阶段, 若是扫描到一个或多个能够配对的服务. 那么能够简历简单的NAN data path(NDP)和NAN data link(NDL)来进行数据通讯. 须要代表的是, 若是一个NAN想要和多个符合服务条件的NAN设备通讯, 那么须要创建多个NAN management interface(也就是多个对应的驱动接口和虚拟的mac地址).

在一个cluster内必然会存在不少NAN设备, DW以内, 全部的NAN设备启动. 进行时间同步和服务发现. 在对这些设备完成TSF同步和服务发现的同时, 也要考虑另一件事情 --- 发送数据.

因此, 在服务发现后还须要交换一下FAW( further available window)和ULW(Unaligned Windows). 这两已经创建起NPL的一个或多个NAN设备能够在协商的FAW内在对应的信道上wake up并进行数据传送. 当FAW时间结束, NAN设备从新进入sleep状态已节省电量(这里的sleep直wifiaware sleep, 在此休眠时间内. 设备能够进入P2P或STA模式).

以下图所示, 须要说明的是, 3个STA构建了4个NDL分别是:

NDL1: STA1 STA2 STA3在6信道

NDL2: STA1 STA2 STA3在149信道

NDL3: STA2 STA3在36信道

NDL4: STA1 STA2在11信道

进行数据传输的两个NAN设备分为发起者(Initiator.)和回应者(Responder). 发起者发送Data Path Request NAF给回应者, 回应者回复Data Path Response给发起者. 这样双方确认了NDP setup的健全模型进而开启数据传输.

下边是使用非加密方式传送数据的协议模型:

使用加密方式传送数据, 对比非加密方式多了4次握手的过程. 具体的加密方式在服务发现阶段就要进行说明.

与WifiP2pManager同样, wifiAware功能有独立的Manager和后台service实现基本功能.在使用时, 能够自行discovery的参数或使用默认参数. 基本的callback必须实现.

大致结构以下:

wifiAwareStateManager简单维护了三个状态, 采用简单的消息循环机制在两个状态之间来回切换. 具体以下:

接口中的attach所谓发现设备, 可使用默认的configRequest, 也能够自行定制

public void attach(@NonNull AttachCallback attachCallback, @Nullable Handler handler)

Publish对应协议中的publish方法, 告知底层服务内容以响应subscribe, 相似蓝牙的UUID.

public void publish(int clientId, Looper looper, PublishConfig publishConfig, DiscoverySessionCallback callback)

Subscribe对应协议中的subscribe方法,意在主动/被动探测cluster内的服务内容

public void subscribe(int clientId, Looper looper, SubscribeConfig subscribeConfig, DiscoverySessionCallback callback)

对应协议中的data request,用于建立与对端设备的链接,以后能够收发数据.

须要networkType为NetworkCapabilities#TRANSPORT_WIFI_AWARE

public void requestNetwork(NetworkRequest request, NetworkCallback networkCallback,int timeoutMs, int legacyType, Handler handler)

Publish或subscribe以后, 会获得对端的handle用于发送数据

DiscoverySession#public void sendMessage(@NonNull PeerHandle peerHandle, int messageId,@Nullable byte[] message, int retryCount)

NeighborAwarenessNetworking_TechnicalSpecification_v2.0.pdf

Wi-Fi_CERTIFIED_Wi-Fi_Aware_Technology_Overview_Simplified Chinese.pdf