WifiAware实现及协议模型

一 协议介绍

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

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

为了以高能效不断地执行发现功能,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在什么场景下发送, 协议中没有明确的规定).

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

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

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

(2) 加入cluster

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

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中的各个角色功能:

1. Master发送NAN sync beacon和 NAN discovery beacon
2. Sync仅仅在DW内传送NAN sync beacon
3. Normal角色什么beacon也不发送(服务发现帧是会发送的).

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

三 服务发现协议

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

1. Discovery window (DW)

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

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

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

1. 服务发现

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地址).

（1）NAN 调度

在一个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信道

（2）数据传送

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

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

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

五 android实现架构

(1) android实现结构简介

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

大体结构如下:

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

1. 接口使用介绍

接口中的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)

参考资料:

https://wenku.baidu.com/view/55b070ca6c175f0e7dd1371c.html

NeighborAwarenessNetworking_TechnicalSpecification_v2.0.pdf

Wi-Fi_CERTIFIED_Wi-Fi_Aware_Technology_Overview_Simplified Chinese.pdf