Multi-AP
Specification
Version 1.0
EasyMesh认证即基于Multi-AP标准
WI-FI联盟专有-如有更改,恕不另行通知
经本文所述条款,可在Wi-Fi联盟的许可下使用本文档。使用本文档即表示您同意这些条款。 除非明确将本文档指定为批准的规范,否则本文档正在开发中,不是批准的Wi-Fi联盟规范。 本文档随时可能修订或删除,恕不另行通知。 本文档中包含的信息可能由您自行承担风险。 Wi-Fi联盟对本文档中的错误或遗漏不承担任何责任。 此版权许可并不构成对产品或服务的认可。 除非Wi-Fi联盟明确允许,否则不得使用Wi-Fi Alliance商标和认证标记。
Wi-Fi联盟尚未对此文件进行独立知识产权(“ IPR”)审查以及此处包含的信息,并且不对知识产权做任何陈述或保证,包括但不限于专利,版权或商业秘密权。 本文件可能包含哪些发明您必须在制造,使用或出售发明之前从第三方获得许可。
Wi-Fi联盟拥有本文档的版权,并保留其中的所有权利。 本文档的用户可以结合本文所述的授权使用来复制和分发本文档的副本,只要其中的全部或部分副本包括本文所述的版权声明和免责声明文本即可。 除非事先获得Wi-Fi联盟的书面许可,否则禁止对本文档进行任何其他使用以及对该文档的所有其他复制和分发。 未经授权的使用,复制或分发是对Wi-Fi Alliance版权的侵犯。
WI-FI联盟不做任何陈述或保证(无论是明示或暗示),并且WI-FI联盟不对任何直接,间接,惩罚性,特殊,偶然,继发性或继发的或由于此类原因造成的损害负责。 与本文档以及本文档中包含的任何信息的使用有关。
目录
1、总览 5
1.1范围 5
1.2目的 5
2 引用 5
3 定义和缩写 6
3.1.1 Shall/should/may/might单词的使用 6
3.1.2 约定 7
3.1.3 定义 7
3.1.4缩写词和首字母缩写词 9
4 架构 11
4.1多AP架构 11
4.1.1多接入点示例部署 12
5 Multi-AP接入 15
5.1 1905按钮配置方法 16
5.2 Backhaul STA接入过程 16
6 Multi-AP 发现 19
6.1 Multi-AP controller discovery 19
6.2 Multi-AP service discovery 20
6.3 客户端关联和解除关联通知 21
7 Multi-AP 配置 22
7.1 AP 配置 22
7.2 AP operational BSS reporting 25
7.3 Policy configuration 25
8 信道选择 27
8.1 信道优选的查询和报告 27
8.2 信道选择请求和报告 29
9 能力信息上报 32
9.1 AP capability 32
9.2 Client capability 33
10 Link metric collection(链路度量采集) 34
10.1 Backhaul link metrics 34
10.2 Per-AP link metrics 35
10.2.1 Link metric measurements from the AP 35
10.3 Per-STA measurements 36
10.3.1 Associated STA link measurements from the AP 36
10.3.2 Unassociated STA RCPI measurements from the AP 38
10.3.3 802.11 beacon measurements from the client 39
10.4 Combined infrastructure metrics 41
11 Client steering 41
12 Backhaul优化 41
13 Multi-AP messaging security 43
14 Four-address MAC header format 43
15 Multi-AP control messaging reliability 43
16 Higher layer data payload over 1905 43
17 Multi-AP control messaging 43
1、总览
1.1范围
本文档是Wi-Fi CERTIFIED EasyMesh™(Wi-FiAlliance®认证计划)对于Multi-AP的技术规范。
该规范定义了Wi-Fi®接入点(AP)之间的控制协议以及必要的数据对象来启用导入配置,和控制多个AP。
该规范也定义在Multi-AP网络内的Wi-Fi接入点之间路由流量的机制。
1.2目的
本规范的目的是为了使来自不同供应商的Wi-Fi接入点(AP)设备能够在同一个Wi-Fi网络部署。
2 引用
[1] IEEE Computer Society, “IEEE Standard for Information Technology – Telecommunications and Information
Exchange Between Systems – Local and Metropolitan Area Networks – Specific requirements Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” (IEEE Std. 802.11-2016)
(https://standards.ieee.org/findstds/standard/802.11-2016.html)
[2] IEEE Std 1905.1™-2013, IEEE Standard for a Convergent Digital Home Network for Heterogeneous Technologies
(https://standards.ieee.org/findstds/standard/1905.1-2013.html)
[3] IEEE Std 802.3™-2015, IEEE Standard for Ethernet (http://ieeexplore.ieee.org/document/7428776/)
[4] TR-181 Device Data Model for TR-069 2016, Issue: 2 Amendment 11 Issue Date: July 2016 (https://www.broadband
forum.org/technical/download/TR-181_Issue-2_Amendment-11.pdf)
[5] Wi-Fi Simple Configuration Technical Specification 2.0.6 (https://www.wi-fi.org/members/certification-programs )
3 定义和缩写
3.1.1 Shall/should/may/might单词的使用
shall表示强制性要求。 必须执行所有强制性要求,以确保与其他Multi-AP产品的互操作性。
shold表示示建议的方法或措施。
may表示允许的方法或行动,没有任何暗示。
might表示可能性或建议。
3.1.2 约定
除非另有说明,否则TLV中信息元素和属性内字段中的位和字节顺序应遵循约定执行。
忽略一词应用于描述其值未经接收者验证的比特,字节,字段或参数。
保留一词应用于描述对象(位,字节或字段或其分配的值),其用法和解释将在将来由本规范或其他技术规范/公告定义。 除非另有说明,否则保留对象应设置为零。 保留对象的接收者应忽略其值,除非该对象在以后定义。 本技术规范定义的对象的发送者不得使用保留的代码值。
3.1.3 定义
表1中的定义适用于本规范。
术语 |
说明 |
Air Time |
The time-frequency spectral resources, normalized to the operating bandwidth of the BSS. Therefore, if the predicted bandwidth of backhaul transmissions is less than the BSS operating bandwidth (e.g. due to dynamic bandwidth adjustment and/or HE OFDMA allocation), this is factored in to the percentage of air time indicated. 时间频谱资源,是BSS拥有的带宽。 因此,如果回程传输的预测带宽小于 BSS工作带宽(例如,由于动态带宽调整和/或HEOFDMA分配),这取决于指示的广播时间百分比。 |
backhaul link |
A Wi-Fi or wired logical Ethernet link between two Multi-AP devices in a Multi-AP network. 这里指建立的Mesh链路,可以为有线或无线。 |
backhaul SSID |
A Wi-Fi SSID used for a Wi-Fi backhaul link that is either the same or different from the fronthaul SSID. 用于无线Mesh链路连接的SSID,可以与接入点的SSID同一个或不同的SSID。 |
backhaul STA |
A STA on a Multi-AP device with a Multi-AP Agent that provides Wi-Fi connectivity with other Wi-Fi access points over the backhaul link. 可以通过无线连接到Wi-Fi AP点,并建立backhaul link的客户端 |
fronthaul AP |
An access point (AP) of a Multi-AP device that provides Wi-Fi connectivity to client stations (STAs) and/or backhaul STAs. Multi-AP设备的接入点(AP),它提供到下挂客户端站(STA)和/或backhaul STA建立Wi-Fi连接。 |
Inoperable channel |
A channel that a device is temporarily not able to operate on due to reasons such as regulatory restrictions or radio environment. 由于法规限制或无线环境等原因,设备暂时无法在其上运行的信道。 |
logical Ethernet link |
A wired connection that may be Ethernet, Multimedia over Coax Alliance (MoCA), power line communication (PLC) or equivalent. 有线连接,可能是以太网,同轴电缆多媒体联盟(MoCA),电源线路通讯(PLC)或同等功能。 |
Multi-AP Agent |
A Multi-AP compliant logical entity that executes AP control functions and provides Multi-AP specific control information. 符合Multi-AP的逻辑实体,执行AP控制功能并提供多AP特定的控制信息。 |
Multi-AP Controller |
A Multi-AP compliant logical entity that implements logic for controlling the operation of the Multi-AP network. 符合Multi-AP的逻辑实体,该逻辑实体实施用于控制可操作的多AP网络。 |
Multi-AP device |
A Multi-AP physical entity that may contain a Multi-AP Controller only, a Multi-AP Agent only or both Multi-AP Controller and Multi-AP Agent. Multi-AP物理实体设备,可以仅包含Multi-AP控制器的,或者仅一个Multi-AP代理,或者一个Multi-AP控制器和多点AP代理。 |
Multi-AP network |
A Wi-Fi network deployment comprising of one or more Multi-AP devices. 一种Wi-Fi网络部署,包括一个或多个Multi-AP设备。 |
multiple virtual radio operation |
Time slicing operation of the physical radio between multiple virtual radios, each operating on a different band or channel. 物理无线在多个虚拟无线之间的时间分片操作,每个虚拟无线在不同的频段或信道上运行。 |
Non-operable channel |
A channel that a device is permanently not capable of operating on. 设备永久无法运行的通道。 |
Steering Mandate mechanism |
A mechanism to mandate a Multi-AP Agent to attempt steering of one or more associated STAs. 一种授权多AP代理尝试操纵(踢掉)一个或多个关联的STA的机制。 |
Steering Opportunity mechanism |
A mechanism to provide a time window for a Multi-AP Agent to steer one or more associated STAs. 针对Multi-AP Agent的,一种以时间窗来控制(踢掉)一个或多个关联的STA的机制。 |
|
|
3.1.4缩写词和首字母缩写词
缩写 |
全称 |
说明 |
1905 |
|
IEEE Std 1905.1™-2013, IEEE Standard for a Convergent Digital Home Network for Heterogeneous Technologies |
AC |
Access category |
|
AL |
Abstraction layer |
|
BSS |
Basic service set |
|
BTM |
BSS transition management |
|
CMDU |
Control message data unit |
|
DFS |
Dynamic frequency selection |
动态频率选择,一般用于避开雷达使用的频段 |
DL |
Downlink |
|
EIRP |
Effective isotropic radiated power |
|
EUI |
Extended unique identifier |
|
GI |
Guard interval |
无线帧的保护间隔 |
HE |
OFDMA High efficiency orthogonal frequency-division multiplexing |
|
HLE |
Higher layer entity |
|
HT |
High throughput |
|
IE |
Information element |
|
MID |
Message identifier |
|
MU |
Multi-user |
多用户 |
OFDMA |
Orthogonal frequency-division multiplexing |
正交频分复用 |
PBC |
Push-button configuration |
|
PPDU |
Physical layer protocol data unit |
|
RCPI |
Received channel power indicator |
|
RSSI |
Received signal strength indicator |
|
SU |
Single user |
|
TBTT |
Target beacon transmission time |
|
TU |
Time units |
|
UL |
MU-MIMO Uplink multi-user multiple input multiple output |
|
WPS |
Wi-Fi Protected Setup |
|
|
|
|
4 架构
4.1多AP架构
Multi-AP网络由两种类型的逻辑实体组成:
- 一个Multi-AP控制器(Multi-AP Controller)和
- 一个或多个Multi-AP代理(Multi-AP Agent)
Multi-AP Controller是Multi-AP网络中的逻辑实体,其实现用于控制前传AP和Multi-AP网络中的回程链路。
一个Multi-AP网络必须有一个Multi-AP控制器。
这个Controller从Multi-AP前传AP接收客户端和回传链路的测量和能力的数据,发关相关的命令和操作到Multi-AP代理设备上。
Controller提供了引导接入功能,以便将Multi-AP设备加载并配置到Multi-AP网络上。
Multi-AP Agent是一个逻辑实体,能执行从Multi-AP控制器接收的命令,报告的的前传AP、下挂客户端、以及连接到Controller或其他Multi-AP Agent的backhaul Link的链接测量质量和功能数据。
Multi-AP Agent的接口是Wi-Fi子系统,支持前Fronthaul APs、和backhaul STA来获取链路质量和功能数据,支持修改配置更改、执行控制功能。
在Multi-AP设备之间定义了逻辑Multi-AP控制接口,通过该接口可以进行配置和控制前传AP和回传链路。 Multi-AP控制接口存在于Multi-AP控制器和多AP代理, 也可以存在于两个Multi-AP代理之间。
Multi-AP设备可能只包含一个Multi-AP Controller,一个Multi-AP Agent或同时包含Multi-AP Controller和Multi-AP。
两个Multi-AP Agen通过backhal link 回程链路相互连接,可以是Wi Fi链路哐以太网链路。在任何时间内,两个Multi-AP设备之间只允许一个活动的回程链路。
一个Multi-AP设备包含了一个或多个用于客户端STA连接的FrontHaul APs 和/或 一个用于建立backhaul Links的Backhaul STA。因此支持backhaul link,则Multi-AP Agent还包括一个 Backhaul STA,以便用于与另一个上游Front AP的Wi-Fi建立backlink(请参见图2)。
具有Multi-AP Agent功能的Multi-AP设备在树形拓扑中通过一跳或多跳相互连接。在多AP网络中,树形拓扑可确保在网络中,任何两个多接入点设备之建立单一的backhaul link路径(超过一跳或多跳),也就是没有环路。
4.1.1多接入点示例部署
图1显示了具有两个Multi-AP设备的Multi-AP部署的示例。
图2显示了另一个Multi-AP部署示例,其中有四个Multi-AP设备以树形拓扑组织,其中
Multi-AP设备之间最多两跳。
图3显示了另一个多ap部署示例,其中包含四个多ap设备和部署在单独设备上的Controller控制器实体。
5 Multi-AP接入
Muti-AP接入是指Multi-AP Agent过Wi-Fi或有线接入到Multi-AP网络中的的二层连接的过程。
该规范定义了一种强制性方法(请参阅第5.1节),通过该方法,Multi-AP设备(包括一个multi-AP agent,backhaul STA)可以接入到一个Multi-AP网络。
请注意,Backhaul STA可能是使用额外方法(using out of band method(s))提供backhaul凭证。
一旦任建立了第二层连接,Multi-AP Agent开始按照第6.1节的方法发现Multi-AP Controller。
5.1 1905按钮配置方法
具有Backhaul STA的Multi-AP Agent必须支持[2]的[1905]按钮配置(1905 PBC)方法,参照第5.2节扩展。
5.2 Backhaul STA接入过程
一个Backhaul STA的加入者使用5.1节中定义的PBC加入方法,来指示现有的Multi-AP Agent为Backhaul STA(请参见图4)。
在图4中,假设有一个Multi-AP Controller已经使用1905扩展方法(遵循7.1的1905 AP-自动配置程序)配置了一个支持BSS backhaul STA连接的Multi-AP Agent。(请参见图4)。
如果Multi-AP Agent运行的BSS已配置为支持Backhaul BSS角色,但尚未配置为支持Fronthaul BSS角色,Multi-AP Agent不得在那个BSS上广播Wi-Fi保护设置(WPS)支持。
如果Multi-AP Agent操作一个或多个已配置为支持FrontHaul BSS的BSS,则多AP代理应至少在其中一个BSS上支持WPS。
如果Backhaul sta从其Backhaulsta接口发送(或重新)关联请求帧,则应在帧中包括包含Multi-AP ie(见表3)的多ap扩展子元素,其中子元素值第7位被设置为1以指示它是BackHaul sta。
如果Multi-AP Agent操作已配置了一个支持Fronthaul BSS的BSS,则Multi-AP代理应包括Multi-AP IE,该IE包含Multi-AP扩展子元素,子元素值的第5位设置为1,在Fronthaul BSS发送到STA的所有(重新)关联响应帧中后,便于这些STA将自己标识为backhaul STA。
如果Multi-ap Agent操作已配置了一个支持Backhaul bss的bss,则多ap代理应包括包含多ap扩展子元素的多ap ie,该子元素值的位6设置为1,在Backhaul BSS发送到STA的所有(重新)关联响应帧中后,便于这些STA将自己标识为backhaul STA。
如果回程sta在wps交换期间从其回程sta接口发送m1消息(参见[5]),则它应在m1消息中包括多ap扩展子元素,作为wi-fi联盟供应商扩展属性的一部分,子元素值的位7设置为1,以指示它是回程sta。
如果多AP代理在WPS过程中从STA接收到带有多AP扩展子元素位7的M1消息,作为Wi-Fi联盟供应商扩展属性设置为1的一部分,则多AP代理应使用与BackHaul SSID相关的凭据(即SSID和密码)配置 Backhaul STA。
如果Multi-AP Agent 的Backhaul STA通过WPS功能被另一个多AP代理配置了网络凭据,并且回程STA在WPS过程结束时已被AP Deauth(取消认证,WPS的最后一步),则多AP代理的Backhaul STA应使用配置的凭据与Backhaul SSID关联。
6 Multi-AP 发现
发现方案用于发现多ap网络中的多ap和多ap控制器代理,其基于在[2]中定义的发现功能的扩展。
6.1 Multi-AP controller discovery
多AP网络应为多AP网络配置一个控制器。
如果多ap设备可以通过带外机制(例如通过ui或服务提供商配置)配置为控制器,则该配置应存储在非易失性存储器中,并且该配置应在设备重启后使用。
本规范扩展了1905 AP自动配置搜索/响应过程(见[2]第10节),以允许发现多AP控制器。多AP控制器应与1905注册器功能位于同一物理设备中。
为了发现多AP控制器,多AP代理发送1905 AP自动配置搜索消息(参见[2]第6.3.7节)。多AP控制器以1905 AP自动配置响应消息响应(见[2]第6.3.8节)。
多AP代理应在1905 AP自动配置搜索消息的SearchedRole TLV中设置标识。
根据第17.1.1节,多AP代理应在1905 AP自动配置搜索消息中包括支持的服务TLV和搜索的服务TLV。
多AP代理应在1905 AP自动配置搜索消息的支持服务TLV中指示多AP代理。
多AP代理应在1905 AP自动配置搜索消息中的SearchedService TLV中指示多AP控制器。
如果多AP控制器接收到SearchedRole设置为Registrar、SearchedService设置为多AP控制器的1905 AP自动配置搜索消息,则应根据第17.1.2节在1905 AP自动配置响应消息中包含支持的服务TLV。多ap控制器应在1905 ap自动配置响应消息的supportedrole tlv中指示注册器。多AP控制器应在1905 AP自动配置响应消息的支持服务TLV中指示多AP控制器。
6.2 Multi-AP service discovery
此规范扩展了1905拓扑查询/响应过程(参见[2]的第8节),以允许发现多ap设备提供的多ap特定功能。
为了发现多ap设备的多ap特定功能,多ap控制器或多ap代理向多ap设备发送1905拓扑查询消息(根据[2]的第8节)。多AP设备以1905拓扑响应消息响应(根据第17.1.4节)。
多AP控制器或多AP代理应在1905拓扑响应消息中包括支持的服务TLV。如果多ap设备包括多ap代理,则多ap代理应在1905拓扑响应消息中的受支持服务tlv中指示多ap代理。如果多ap设备包括多ap控制器,则多ap控制器应在1905拓扑响应消息中的受支持服务tlv中指示多ap控制器。
如果多ap代理发送拓扑响应消息,并且至少有一个802.11客户端与多ap代理操作的任何bss直接关联,多AP代理应根据第17.1.4节在消息中包括关联客户端TLV,以指示与多AP代理操作的每个BSS直接关联的所有802.11客户端。详见A.2。
6.3 客户端关联和解除关联通知
此规范扩展了1905拓扑通知消息,以允许其他多ap代理快速了解客户端(re)关联和解除关联事件。
如果Wi-Fi客户端在多AP设备上加入或离开BSS,则多AP代理应根据第17.1.5节在1905拓扑通知消息中包括客户端关联事件TLV。
7 Multi-AP 配置
7.1 AP 配置
本规范扩展了1905 ap自动配置过程,使多ap控制器能够在多ap代理的每个无线上配置802.11接口(即bss)。
多AP代理应根据第17.1.3节为其每个无线发送单独的AP自动配置WSC消息。
多AP代理应使用AP无线基本能力TLV中的无线唯一标识符指示802.11配置的无线(见第17.2.7节)。
多AP代理应将AP自动配置WSC消息中M1中的MAC地址属性设置为多AP设备的1905 AL MAC地址。
多AP代理应在AP自动配置WSC消息中设置M1中的身份验证类型标志属性,以指示对WPA2个人和开放系统身份验证类型的支持。
如果多ap控制器接收到包含m1的wsc tlv,然后,它应在1秒内响应:1)在AP无线标识符TLV中标识的无线上为每个配置的BSS配置一个或多个M2,或2)一个M2 在Multi-AP Extension子元素中将第4位(拆除位)设置为1,根据第17.1.3节指示在AP无线标识符TLV中标识的无线上配置零BSS。
根据第17.1.3节,多AP控制器应包括一个包含M2(见[5])的WSC TLV,用于在AP自动配置WSC消息中AP无线标识符TLV中标识的无线上配置的每个BSS。每m2中规定的n2 nonce应是唯一的。多AP控制器应在M2中设置身份验证类型属性,以指示WPA2™个人或开放系统身份验证。
多AP控制器指示BSS是否支持表4中列出的多AP扩展子元素中的多AP回程连接和/或Front连接,作为图4中所示AP自动配置WSC消息的一部分。
多AP扩展子元素在具有供应商扩展名的Wi-Fi联盟供应商扩展名属性中携带属性id设置为0x1049,供应商id设置为0x00372a,子元素id设置为0x06。见[5]表29。
如果bss支持BackHaul连接,则多ap控制器应在自动配置信息wsc中包含一个多ap扩展子元素,该子元素值的位6设置为1的m2。如果BSS支持FrontHaul连接,多ap控制器应在ap自动配置wsc中包括多ap扩展子元素包含m2,子元素值的位5设置为1。Wi-Fi联盟供应商扩展属性应为在包含m2的自动配置 wsc消息中,由keywrappkey加密的configdata中携带。
为了方便作为加入者的一个或多个Back haul sta连接到多ap网络,多ap控制器应指示在多ap代理中的任何一个上的至少一个bss被设置为支持多ap Backhaul连接。
如果触发,多AP控制器应根据第17.1.3节在AP自动配置WSC消息中M2包括一个多AP扩展子元素,其中位6 Backhaul BSS和位5 Fronthaul BSS设置1。
多AP控制器应该限制AP自动配置WSC消息中包含M2的WSC-TLV的数量不超过AP无线基本能力TLV中由该无线支持的BSS(S)的最大数目的值。多ap控制器应将ap autoconfiguration wsc消息中ap radio identifier tlv中的radio unique identifier字段设置为与接收到多ap代理的ap autoconfiguration wsc消息中ap radio basic capabilities tlv中指定的相同字段的值。
如果多AP代理接收到包含一个或多个M2的AP自动配置WSC消息,则应验证每个M2(基于其1905 al-mac地址)并在相应的无线上为m2中的每一个配置bss。如果多AP代理当前正在操作一个操作参数与接收到的任何M2都不完全匹配的BSS
AP自动配置wsc消息,它将拆除该bss。如果多ap代理接收到ap autoconfiguration wsc消息,该消息包含一个m2,该m2具有多ap扩展子元素,子元素值的位4(删除位)设置为1(见表4),则该代理应删除无线唯一标识符指示的无线上的所有当前操作的bss,并应忽略m2中的其他属性。
如果多AP代理接收到AP自动配置续订消息,则它应根据第17.1.3节为其每个无线发送一条AP自动配置WSC消息,在一秒钟内作出响应,而不考虑AP自动配置续订消息中支持的频带TLV中指定的值。
7.2 AP operational BSS reporting
多ap代理在1905拓扑响应消息中指示其当前可用的无线Bss。多ap设备将每个BSS视为在[2]中指定的ieee 802.11“本地接口”。
多ap代理应在1905拓扑响应消息中的设备信息类型tlv中,指出每个BSS作为单独的(802.11)本地接口,工作在pwr_on或pwr_save模式。
多AP代理应将1905拓扑响应消息中设备信息类型TLV中本地接口字段的MAC地址设置为BSSID
。根据第17.1.4节,多AP代理应在1905拓扑响应消息中包括AP操作BSS TLV。多ap代理应在1905拓扑响应消息中的ap操作bss tlv中,在其每个无线上指示其当前以pwr_on或pwr_save模式运行的所有bss。
7.3 Policy configuration
多AP策略配置请求消息使多AP控制器能够在多AP代理上配置与多AP控制相关的策略。
如果触发,多AP控制器应根据第17.1.8节向多AP代理发送多AP策略配置请求消息。
如果多AP代理接收到多AP策略配置请求消息,则根据第17.1.32节,多AP代理应在1秒内响应1905 ACK消息。
第17.2.11节中定义的Steering策略TLV包含与Steering相关的策略。本地Steering列表(不允许连接的STA列)表指示这些STA需要被踢掉,但需得到多AP控制器的转向指令时才能被Steering(见第11.1节)。BTM Steering Disallowed STA列表示要使用客户端关联控制机制来Steering 这些STA(请参阅第11.6节)。Steering Policy(转向策略)字段在无线初始化时被设置。“通道利用率阈值”和“RCPI Steering阈值”的字段在代理启动的每个无线接口Steering过程-中使用。
第17.2.12节中定义的度量报告策略TLV包含链接度量报告相关策略。ap metrics reporting interval字段指示是否启用定期ap metrics reporting,如果启用,则指示周期。sta metrics reporting rcpi threshold和ap metrics channel utilization reporting threshold字段指示是否对sta和/或ap metrics启用基于阈值的度量报告,如果启用,则指示每个无线的相应阈值。
8 信道选择
多ap系统通过控制消息中使用信道选择的参数配置多ap代理。
8.1 信道优选的查询和报告
Multi-AP Controller 通过信道优先查询和信道优先报告消息向Multi-AP Agent进行查询操作。
Controller 应该按照17.1.9规定向Agent发送一个信道优先查询的消息。
如果多AP代理收到一个信道优选查询消息,则它应在17.1.10节中在一秒钟之内以一个信道首选项报告消息做出响应。
信道优选报告消息应包含与在信道优选查询消息中收到的MID相同的消息。
信道优选报告消息应包含有关发送报告的多AP代理的给定无线暂时无法在其中运行的所有信道的信息 ,或不希望针对Multi AP代理程序指定的每个受支持的操作类别进行操作(第17.2.7节中的“ AP无线基本功能TLV”中的“每个操作类别”字段)。
另外,信道优选报告消息应包含有关多AP代理的给定无线在其自身的潜在操作信道中的每一个与多AP代理的另一无线的操作信道之间所需的信道间隔(如果有)的信息,其中两个无线可能有一个正在发射,而另一个则同时在接收或发射。
注意:在AP无线基本功能TLV中报告了Multi-AP Agent的无线现在(永久)无法运行的频道。
信道优选报告消息不包括有关每个AP无线基本功能TLV所对应的多AP代理的无线不支持的操作类别的信息。
如果多接入点控制器从多接入点代理接收到信道优选报告消息,则多接入点控制器应理删除与该多接入点的所有无线有关的所有(如果有的话)先前存储的信道偏好信息。 AP代理并将其替换为“信道优选报告”消息中包含的信息。如果信道优选报告未指定多AP代理为给定无线指定的支持的操作类别中的特定信道的优先,则多AP控制器应推断多AP代理指示最高优先(相对应得分15)对应的无线可操作信道。如果信道优选报告包含零个信道首选项TLV和零个无线操作限制TLV,则多接入点控制器应推断多接入点代理针对所有信道和所有支持的工作类别指示最高优先级(优先级分数15)。 Multi-AP代理确定和重新评估其信道优选的机制是特定实现的。但是,当在信道优选报告中指示首选项时,Multi-AP代理应指示可操作信道,但以下情况除外:
•如果无线设备由于检测到雷达而无法在操作等级的频道上操作,则该频道应指示为不可操作频道
•如果存在无线无法在某个信道上正常运行BSS的情况(例如,由于强干扰),则该信道应被指示为不可操作信道。
如果Multi-AP Agent的信道首选项发生更改,则它将向Multi-AP控制器发送未经请求的信道首选项报告,指示Multi-AP Agent的当前首选项。
如果Multi-AP代理检测到任何信道的DFS状态发生变化,则它应根据17.2.13节的表18,向控制器发送未经请求的信道首选项报告,为该信道设置适当的DFS相关原因码。
如果多接入点控制器收到未经请求的信道首选项报告消息,则它必须在一秒钟内以1905确认消息做出响应。
8.2 信道选择请求和报告
信道选择请求消息包含有关Multi-AP控制器对Multi-AP Agent无线的信道优选、操作等级、发射功率的限制的信息。
如果触发,则多AP控制器应按照17.1.11节发送信道选择请求消息。
如果多AP控制器发送信道选择请求消息,则它应为多AP代理指定可操作的非DFS信道中的至少一个“可操作”选项(即,多AP代理没有明确表明不可操作的信道)。这个选项中的信道来源于最近从多AP代理收到的信道首选项报告消息和AP无线基本能力TLV信息。
如果多接入点控制器发送了信道选择请求消息,则不应指定首违反最近从Agent收到的信道偏好报告消息中指示的无线操作限制的选项。
如果多接入点控制器发送信道选择请求消息,则它应指定优先级,其中要考虑到由多接入点代理在最新的信道优先级报告消息中指示的相应优先级值。
除非有必要进行负载平衡或其他网络管理要求,否则Multi-AP Controller应避免使用Multi-AP Agent已说明的不可操作信道。
如果Multi-AP代理从Multi-AP控制器接收到信道选择请求消息,则Multi-AP代理应删除与无线有关的所有(如果有的话)先前存储的信道偏好信息。 AP代理并将其替换为消息中包含的信息。
Multi-AP代理应将信道偏好信息存储在非易失性存储器中。
如果重新启动Multi-AP Agent,则它可能会继续使用在重新启动之前从Multi-AP Controller接收到的最新信道首选项信息,或者可能刷新任何先前接收到的信道首选项信息并假定所有支持的通道都是首选的,直到从Multi-AP Controller中接收到新的信道首选项信息。
如果一个信道选择请求消息没有为多无线代理为给定的无线指定支持的操作类别中的特定信道的优先选择,则多无线代理应推断多无线控制器指示最高优先级的信道(优先级得分15)。
如果信道选择请求消息包含零个信道首选项TLV,则多AP代理应推断多AP控制器指示所有多AP代理的无线支持的所有信道和操作类别的最高优先级(优先分数15) 。
Multi-AP代理不得在当前存储的Multi-AP Controller首选项信息指示为不可操作的信道和操作级别上操作无线。
如果多AP代理从多AP控制器接收到一个信道选择请求消息,则它应尝试在每个信道选择请求消息指示为该无线的最高优先级的信道之一上操作其每个无线。
如果Multi-AP Agent尝试操作或已经在操作某个信道上的无线,并且该信道变为不可操作的信道,则Multi-AP Agent应该考虑最近接收到的Channel Selection Request中指示的相应优先级值 消息(如果有)。
Multi-AP Agent选择操作通道和操作类别的确切机制是特定于实现的。
如果多AP代理执行信道可用性检查(CAC),则在决定首先检查哪些信道时,应考虑“信道选择请求”消息中的信道优先级。
Multi-AP Agent应该以无线能够操作并允许其根据适用的法规运行的最大标称发射功率来操作无线。
如果多AP代理收到包含发送功率限制TLV的信道选择请求消息,则它将相应无线的标称发送功率限制为TLV中指定的值。
如果多AP代理接收到一个信道选择请求消息,则它应在一秒钟之内向多AP控制器发送一个信道选择响应消息(第17.1.12节),以指示每个无线设备该多AP代理是接受还是接收。 拒绝请求以及拒绝的原因(如果合适)。 信道选择响应消息应包含在信道选择请求消息中接收到的相同的MID。
如果多接入点代理发送了一个信道选择响应消息,指示接受了多接入点控制器对给定无线的请求,则多接入点代理应对其无线的工作信道,工作等级和发射功率进行必要的调整。 然后,无论是否进行了任何调整,均应按照第17.1.13节的要求发送操作信道报告消息,其中包含有关每个Multi-AP Agent无线的当前操作参数的信息。
如果多接入点控制器接收到一个工作信道报告消息,则它必须在一秒钟之内以1905确认消息做出响应。
如果多接入点代理自行改变无线的工作信道,工作等级或标称发射功率(即不响应于接收到的信道选择请求消息),则它应发送未经请求的工作信道报告根据第17.1.13节发送给Multi-AP Controller的消息,指示相应无线的新操作参数。
注意:如果通过以下方式发送支持的运行类别元素,则在“运行频道报告TLV”中指定的运行类别等于“支持的运行类别”元素的“运行类别”字段中指示的值(根据[1]的9.4.2.54节)。 在相应无线的BSS中运行的AP。 这包括与无线当前正在其中操作的每个信道带宽相对应的操作等级(例如,对于VHT80 AP通常为20、40和80MHz的操作等级)。 使用主要频道时,“ 20 MHz操作等级”指示该主要频道。
9 能力信息上报
9.1 AP capability
Multi-AP Controller通过AP能力查询和报告消息来获取Multi-AP设备上所有AP无线的能力信息。
如果被触发,则多AP控制器应按照第17.1.6节的要求发送AP能力查询消息。
如果一个多AP代理收到一个AP能力查询消息,则它应在17.1.7节中在一秒钟内以一个AP能力报告消息作出响应。
一个多AP代理应在AP能力报告消息中包含一个AP能力TLV。
一个多AP代理应在AP能力报告消息中为每个AP无线包括一个AP无线基本能力TLV。
如果AP无线支持802.11高吞吐量能力,则多AP代理应在AP能力报告消息中包括该无线的AP HT能力TLV。 如果AP无线支持802.11非常高吞吐量能力,则MultiAP代理应在AP能力报告消息中包括该无线的AP VHT能力TLV。 如果AP无线支持802.11高效率功能,则多AP代理应在AP能力报告消息中包括该无线的AP HE能力TLV。
如果由Multi-AP Agent管理的AP无线能够进行多种虚拟无线操作(请参阅表1),则Multi-AP代理应在功能TLV中使用唯一的无线唯一标识符分别标识每个虚拟无线,并指出功能信息仅与AP能力报告消息中的能力TLV中指示的虚拟无线有关。
AP能力报告消息应包含与AP能力查询消息中收到的MID相同的MID。
9.2 Client capability
多AP客户端能力查询和客户端能力报告消息使多AP控制器能够获取与多AP代理相关联的客户端STA的能力信息。
如果被触发,则多AP控制器应按照17.1.14节发送客户端能力查询消息。 如果被触发并受支持,则多AP代理应按照17.1.14节发送客户端能力查询消息。
如果多AP代理收到客户端功能查询消息,则应在1秒内按照第17.1.15节的要求发送客户端功能报告消息。客户端能力报告消息应包含与客户端能力查询消息中收到的MID相同的MID。如果客户端能力查询消息中指定的STA与多AP代理操作的任何BSS不相关(错误情况),则多AP代理应将客户端能力报告TLV中的结果代码设置为0x01第17.2.19节中的内容,并在客户端能力报告消息中包含第17.2.36节中包含的错误代码TLV(原因代码设置为0x02)和STA MAC地址字段。如果客户端能力查询消息中指定的STA与由Multi-AP代理操作的任何BSS关联,并且Multi-Agent无法报告客户端的能力,则Multi-AP代理应在客户端中设置结果代码能力报告TLV为0x01,并在客户端能力报告消息中包含错误代码TLV,原因代码设置为0x03。
10 Link metric collection(链路度量采集)
10.1 Backhaul link metrics
本部分定义了用于传达每个正在运行的Multi-AP device 的BSS相关的backhaul link信息的协议。
1905链路量度信息传播协议用于查询和报告回程链路的链路量度
(e.g. link between a Multi-AP Agent AP interface and a Multi-AP Agent backhaul STA interface, or between two Multi-AP Agent Ethernet interfaces. See [2]).
如果被触发,则Multi-AP Controller和Multi-AP Agent应向Multi-AP Agent发送1905链路度量查询消息。
注:关于1905 Transmitter链路度量TLV中的字段的补充说明如下:
MacThroughputCapacity字段是Multi-AP Agent操作AP上报backhaul link的下行MAC数据速率(Mb/s),或Multi-AP Agent操作backhaul STA上报backhaul link的上行MAC数据速率(Mb/s)。如果信道空时和BSS的运行带宽为100%,则可用。
注:关于1905 Receiver link 链路度量 TLV中字段的补充说明如下:
RSSI是根据Multi-AP Agent操作AP上报的PPDU的RCPI计算得出,或Multi-AP Agent操作backhaul STA上报的Beacon RSSI计算得出。
10.2 Per-AP link metrics
本部分定义了用于Multi-AP Agent的协议,以传达有关其正在运行的每个BSS(前传和/或回传)的per-AP度量标准信息。 这些指标总体上与BSS有关,不包括特定于可能与BSS相关的STA的指标(请参阅第10.3节)
10.2.1 Link metric measurements from the AP
如果触发,则Multi-AP Controller应(shall)按照第17.1.16节的规定向Multi-AP Agent发送AP度量查询消息。
如果Multi-AP Agent收到AP度量查询消息,则它(shall)在1秒钟内以AP度量响应消息(第17.1.17节)做出响应,该消息包含针对第17.2.22节中针对每个BSS的一个BBS规定的一个AP度量TLV。AP Metrics Response消息应(应)包含与AP Metrics Query消息中收到的相同的MID。
如果Multi-AP Agent收到一个“ AP度量报告间隔”字段设置为非零值的度量报告策略TLV,则它应向Multi-AP Controller发送一个AP度量响应消息,其中包含每个BSS的一个AP度量TLV,其中,它在字段中指定的每个报告间隔运行一次。
如果Multi-AP Agent收到带有AP度量信道利用率报告阈值字段的度量报告策略TLV,则对于给定的无线电,该Multi-AP Agent应连续测量该无线电的信道利用率 implementation-specific 测量周期,并且如果最近测量的信道利用率在两个方向上都超过了报告阈值(关于以前的计量),它将向Multi-AP Controller发送AP度量响应消息,该消息包含该无线电上每个BSS的一个AP度量TLV。
如果Multi-AP Agent发送了AP指标响应消息,并且最近接收到的(如果有的话)指标报告策略TLV已将指定无线电的关联STA流量统计包含策略设置为1。Multi-AP Agent还应为与在该无线电上报告的BSS关联的每个STA包括一个关联的STA流量统计TLV,除非它已在前10秒内发送了包括相应STA流量统计TLV在内的先前的AP指标响应消息。在这种情况下,它可能包括或省略STA Traffic Stats TLV。
如果Multi-AP Agent发送了AP指标响应消息,并且最近接收到的(如果有的话)指标报告策略TLV已将指定STA的关联STA链路指标纳入策略设为1,对于与在该无线电上报告的BSS关联的每个STA,Multi-AP Agent还应包括一个关联的STA链路度量TLV。
在报告STA流量统计信息时,Multi-AP Agent应(should)报告与维持AP吞吐量性能相对应的最新计数器信息,并且应报告不超过10秒的计数器信息。
NOTE:
10.3 Per-STA measurements
本部分定义了Multi-AP Agent基于每个STA传达链路度量信息的协议。
10.3.1 Associated STA link measurements from the AP
本小节定义了一种协议,供Multi-AP Agent报告Multi-AP Agent AP与关联的STA之间的上下行链路的链路质量度量。
如果触发,则Multi-AP Controller应根据第17.1.18节向Multi-AP Agent发送关联的STA链路度量查询消息
如果一个Multi-AP Agent收到一个关联的STA链路度量查询消息,则它应在一秒钟之内做出响应,其中包含一个用于指定STA的关联的STA链路度量TLV(17.1.19)。响应消息应包含同样的MID。
如果指定的STA不与任何BSS关联,由Multi-AP Agent(一个错误场景)操作的Multi-AP应将关联的STA链路度量TLV中报告的BSSIDs字段数设置为零(17.2.24),并包括一个错误代码TLV(原因代码字段设置为0x02)和STA MAC地址字段(根据17.2.36节)。
如果Multi-AP Agent收到针对给定无线电的STA度量报告RCPI阈值字段设置为非零值的度量报告策略TLV,Multi-AP Agent应监视与在该无线电上运行的BSS相关的每个STA的上行RCPI,如果最近的STA上行RCPI已经越过了STA度量报告RCPI阈值,包括两个方向的滞后边界(相对于以前的测量)
Multi-AP Agent应将关联的STA链路度量响应消息发送给包含与该STA对应的关联STA链路度量TLV的Multi-AP Controller。除非STA Metrics Reporting RCPI Hysteresis Margin Margin Override字段设置为非零值,该字段是最近收到的与给定无线电有关的度量报告策略TLV(如果有的话)
Multi-AP Agent应使用非零实现特定的滞后裕度,以避免相关的STA链路指标的过度产生响应消息,该响应消息是由于RCPI阈值附近的上行链路测量的快速波动引起的Multi-AP Agent不应使用大于5Db的滞后裕度。
如果在最近接收到的“度量标准报告策略” TLV中,“ STA度量标准报告RCPI滞后裕量替代”字段设置为非零值,当确定何时为基于RCPI阈值的报告发送关联的STA链路度量响应时,Multi-AP Agent应使用为STA度量报告RCPI滞后余量覆盖字段指定的值作为RCPI滞后余量。
当Multi-AP Agent为计算估计MAC数据速率和用于STA度量报告的上行RCPI或SNR值时,这些值可以使用特定于实现的平滑函数。当配置了非零STA Metrics Reporting RCPI阈值时,Multi-AP Agent应该对上行RCPI测量进行足够的平滑,以避免由于测量噪声引起的关联STA链路度量响应消息的过度生成。
如果一个Multi-AP Agent发送了关联的STA链路度量响应消息,它必须根据最近测量的上行链路和下行RCPI或SNR值为关联链路的下行链路设置估计MAC数据速率度量值和上行链路的值。
估计MAC数据速率是指在信道空时和业务带宽为100%时,在链路上可以实现的MAC层吞吐量的估计。Multi-AP Agent用来计算估计的MAC数据速率的算法是特定于实现的。
公式:
10.3.2 Unassociated STA RCPI measurements from the AP
这一部分定义了Multi-AP Agent为未关联的STAs报告上行RCPI的协议。
如果触发,Multi-AP Controller和Multi-AP Agent应按17.1.20节向Multi-AP Agent发送每节17.1.20的未关联的STA链路度量查询消息。
Multi-AP Controller和Multi-AP Agent不得将未关联的STA链路度量查询消息发送至没有明确在AP Capability TLV中表示支持未关联的STA链路度量的Multi-AP Agent。
如果一个Multi-AP Agent表明支持未关联的STA链路度量,它收到一个未关联的STA链路度量查询消息,它必须在一秒内用1905标准确认消息进行响应,并试图为指定的STA测量上行RCPI。
如果未关联的STA链路度量查询消息中指定的任何一个STA与Multi-AP Agent操作的BSS相关(错误场景)关联,则多STA代理应包含一个错误代码TLV,其原因码字段设置为0x01,而STA Ack消息中的STA MAC地址字段包含在1905 标准Ack消息中(17.2.36)。
Multi-AP Agent应尝试在其无线电设备的当前工作信道上测量RCPI,如果它在AP能力TLV中用非相关的STA链路度量位表示支持,应尝试在查询中指定的其他通道和操作类上测量RCPI。
当Multi-AP Agent为未关联的STA链路度量报告测量RCPI值时,这些值可以使用特定于实现的平滑函数随时间的推移进行平均值。
如果Multi-AP Agent收集了一个或多个上行RCPI度量,它将按17.1.21节发送一个未关联的STA链路度量响应消息。
一个Multi-AP Agent可以在一个或多个未关联的STA链路度量响应消息中发送上行RCPI测量信息,这些测量可以在某些测量可用或可能绑定到一个独立的STA链路度量响应消息之后立即发送。
如果Multi-AP Agent在某些特定于实现的超时后无法在未关联的STA链接度量查询消息中指定的所有STA上获得任何RCPI度量值,Multi-AP Agent应将未关联的STA Link Metrics Response消息中包含的STA字段的数量设置为17.2.26节的零。
如果Multi-AP Controller接收到一个未关联的STA链路度量响应消息,那么它应该在一秒内用1905 标准的Ack消息做出响应。
10.3.3 802.11 beacon measurements from the client
本小节定义了请求Multi-AP Agent从关联的STA获取802.11信标报告测量值的协议,并使用来自该STA的Beacon报告进行响应,主要目的是获取由AP在BSS中传输的Beacon或Probe响应帧的下行RCPI测量值,以此作为指导决策的基础,然而,该机制也可用于从那些BSSs中运行的AP发送的Beacon或Probe响应帧中获取信息元素。
如果触发,Multi-AP Controller和Multi-AP Agent应将每节17.1.22的信标指标查询消息发送给Multi-AP Agent。
如果一个Multi-AP Agent接收到一个Beacon度量查询消息,那么它应该在一秒钟内用一个1905标准Ack消息进行响应。
如果Beacon Metrics Query消息中的指定STA与由Multi-AP Agent操作的任何BSS没有关联(错误场景),Multi-AP Agent必须包括一个错误代码TLV,原因代码字段设置为0x02,以及1905标准Ack消息中17.2.36节中的STA MAC地址字段。
如果指定的STA表示支持802.11 beacon报告,Multi-AP Agent应执行下列操作:
Send an 802.11 Beacon request to the STA.
如果STA表示支持主动和/或被动802.11信标测量,Multi-AP Agent可以将信标请求中的测量模式字段设置为活动, 或被动,除非存在主动QoS敏感的业务流,Multi-AP Agent预期会受到主动或被动测量的不当影响,在这种情况下,可以请求Beacon Table模式。
如果查询中的SSID Length字段的值是非零,则802.11 Beacon请求中必须包含一个SSID子元素,并将其设置为查询中SSID字段的值。否则,一个SSID子元素不应该包括在内。
信标请求中的操作类、信道号、BSSID和报告详细信息字段应设置为查询中指定的相应值
如果查询中的AP频道报告字段数(h)的值大于零,且查询中的信道号字段的值为255,那么在802.11 beacon请求中必须包含h AP信道报告子元素,每个元素都包含指定的操作类和信道列表。
如果Multi-AP Controller或Multi-AP Agent发送一个Beacon度量查询消息,它的目标应该是通过以下方式将可能对指定STA的持续流量造成的干扰降至最小:
尽量减少需要STA扫描的频道数量,以便只对感兴趣的BSS运行的信道进行测量
将Specify SSID字段设置为1,除非需要在当前关联的ESS之外的BSS报告
避免将Reporting Detail字段设置为value 2,并将Reporting Detail字段设置为value 1时将请求的Element IDs的数量减到最小
如果Multi-AP Agent从STA收到信标报告,它将根据第17.1.23节向Multi-AP Controller发送一个信标响应消息,并包含来自STA的信标报告中的所有测量报告。
如果一个Multi-AP Controller接收到一个信标指标响应消息,那么它必须在一秒钟内用一个1905标准Ack消息做出响应。
注:Beacon度量报告消息中的测量报告消息包含一个实际测量开始时间字段,指示STA执行报表中指示的度量的时间。如果STA仅支持Beacon Table模式(其中STA使用缓存的信标报告测量值做出响应),则此测量时间可能早于Multi-AP Agent接收到Beacon Metrics查询的时间。
10.4 Combined infrastructure metrics
本部分定义了用于Multi-AP Controller的协议,以传达有关Multi-AP网络中所有BSS和所有回程链路的组合指标。通常,在指示Multi-AP Agent执行local steering of client(s)之前,Multi-AP Controller会将此信息提供给Multi-AP Agent。
如果被触发,则Multi-AP Controller应按照第17.1.24节的规定向Multi-AP Agent发送组合基础架构度量消息。如果Multi-AP Controller发送组合基础架构度量消息,则它将包括来自Multi-AP网络中相应Multi-AP Agent的最新接收到的TLV。
如果Multi-AP Agent接收到组合基础设施度量消息,那么它必须在一秒内用1905标准Ack消息进行响应。
11 Client steering
12 Backhaul优化
在Multi-AP 网络中,Multi-AP Agent的backhaul STA 连接到一个 BSS 访问backhaul 连接。Multi-AP 可能在接入时从多个候选BSS 中选择,随后Multi-AP控制器可能希望将Multi-AP代理移动到不同的 BSS 中。
如果被触发,则根据第17.1.29节,Multi-AP控制器应发送Backhaul Steering请求消息,以请求Multi-AP Agent将其backhaul STA连接到其他BSS。
如果一个Multi-AP Agent收到一个Backhaul Steering请求消息,则它(shall)必须在一秒钟之内以一个1905 Ack消息响应Multi-AP控制器,并尝试与该消息中指定的目标BSS(重新)关联。 在Multi-AP Agent成功与目标BSS关联或自接收到回程控制请求消息起10秒钟后,Multi-AP Agent应按照第17.1.30节的要求向Multi-AP Controller发送Backhaul Steering响应消息。如果Multi-AP Agent与Backhaul Steering请求消息中指定的目标BSS关联成功,则Multi-AP Agent应将Backhaul Steering响应TLV中的result code设置为0x00。
如果Multi-AP Agent与Backhaul Steering请求消息中指定的目标BSS关联失败,则Multi-AP Agent应将Backhaul Steering响应TLV中的result code设置为0x01,并在Backhaul Steering响应消息中包含一个Error Code TLV,将reason code设置为0x04、0x05或者0x06,参照第17.2.36节。
通常,当Multi-AP Agent执行Multi-AP Controller请求的控制时,由于数据路径更改和控制的持续时间,与Multi-AP Agent关联的STA上可能会有短暂的用户数据中断(类似于通过在STA上使用BSS过渡管理消息进行控制)。 如果Multi-AP Agent的fronthaul BSS与它的backhaul STA在同一信道上工作,并且Multi-AP Agent收到了Backhaul Steering请求消息,要求STA切换到其他信道,在发生信道切换时,与Multi-AP Agent的fronthaul BSS关联的客户端上可能存在连接中断。在这种情况下,如果可能,Multi-AP Controller应该尝试降低影响或避免此类中断(例如,在触发Backhaul Steering之前,如果有其他的fronthaul BSS,将clients steering至另一个fronthaul BSS)。
如果一个Multi-AP Controller 接收Backhaul Steering响应消息,那么它应该在一秒钟内回复一个 1905 Ack 消息给消息的发送者。
13 Multi-AP信息安全
This specification utilizes multiple security layers.
此规范利用了多层安全协议
A Multi-AP device wishing to join a network of Multi-AP devices satisfies the onboarding authentication of its network connectivity.
一个Multi-AP设备要加入Multi-AP网络,需满足网络的接入认证。
For example, Wi-Fi connectivity uses WPA2-Personal.
比如,WiFi链接使用WPA2-Personal加密。
Multi-AP messaging is protected against out-of-network eavesdropping through utilization of encryption feature(s) of its underlying network connectivity.
利用基础网络的加密功能保护Multi-AP的信息免遭网络外的窃听。
A Multi-AP interface is considered authenticated when the underlying networking
technology encryption mode has been successfully configured.
如果基础网络的加密模式已成功配置则认为Multi-AP的接口已认证。
For configuration of messaging for Multi-AP Agent credentials related to a BSS, the Wi-Fi Simple Configuration V2 mechanism (see section 7.1 of [5]) is used as a further layer of protection against unauthorized access and disclosure.
针对BSS相关的Multi-AP Agent的信息配置,Wi-Fi Simple Configuration V2机制(请参阅[5]的7.1节)被用作防止未经授权访问和泄露的另一层保护。
14 Four-address MAC header format
The address handling description applies immediately after a Multi-AP Agent has connected to a Multi-AP network using an onboarding method per section 5.
一个Multi-AP Agent使用第5节的接入方法连接到Multi-AP网络后应立即应用地址处理说明。
14.1 Wi-Fi回传帧和地址处理
Wi-Fi backhaul frame and address handling
If a Multi-AP device receives a Multi-AP IE from another Multi-AP device, then thereafter a Multi-AP device frame formats shall be compliant with section 9 of [1] with the following exceptions:
如果一个Multi-AP设备从另一个Multi-AP设备接受到了Multi-AP IE,Multi-AP设备的帧格式应该遵从第9章节[1],除了以下的例外:
14.1.1接收端要求
If source address (SA field) has the same value as the IEEE MAC individual address of the backhaul STA (TA field), a Fronthaul AP shall support receiving both Four-Address and Three-Address MAC header format Data frames from a backhaul STA.
如果源地址(SA字段)与回程STA的IEEE MAC单独地址(TA字段)具有相同的值,则前传AP应支持从回程STA接收四地址和三地址MAC头格式数据帧。
If source address (SA field) has a different value than the IEEE MAC individual address of the backhaulSTA (TA field), a Fronthaul AP shall support receiving Four-Address header format Data frames from a backhaul STA.
如果源地址(SA字段)的值与回程STA的IEEE MAC个人地址(TA字段)的值不同,则前传AP应支持从回程STA接收四地址报头格式数据帧
If destination address (DA field) has the same value as the IEEE MAC individual address of the backhaul STA (RA field),a backhaul STA shall support receiving both Four-Address and Three-Address MAC header format Data frames from a Fronthaul AP.
如果目的地址(DA字段)的值与回程STA的IEEE MAC单独地址(RA字段)的值相同,则回程STA应支持从Fronthaul AP接收四地址和三地址MAC报头格式数据帧。
If destination address (DA field) has a different value than the IEEE MAC individual address of the backhaul STA (RA field), a backhaul STA shall support receiving Four-Address MAC header format Data frames from a Fronthaul AP.
如果目的地址(DA字段)的值与回程STA的IEEE MAC单独地址(RA字段)的值不同,则回程STA必须支持从Fronthaul AP接收四地址MAC报头格式数据帧。
14.1.2 发送端要求
If a backhaul STA sends a Data frame to an associated Fronthaul AP with a source address (SA field) different from the IEEE MAC individual address of the backhaul STA, then the backhaul STA shall set the To DS B8 field to one and From DS B9 field to one in the MAC Frame Control field, per section 9.2.4.1 of [1].
如果回程STA以与回程STA的IEEE MAC单独地址不同的源地址(SA字段)向关联的Fronthaul AP发送数据帧,则回程STA应将To DS B8字段设置为1,并且From DS B9根据9.2.4.1节[1]将MAC帧控制字段中的“ 1”字段更改为1。
If a backhaul STA sends a Data frame to an associated Fronthaul AP with a source address (SA field) same as the IEEE MAC individual address of the backhaul STA, then the backhaul STA shall either:
如果回程STA使用与回程STA的IEEE MAC个人地址相同的源地址(SA字段)向关联的Fronthaul AP发送数据帧,则回程STA应当:
• Follow the Three-Address MAC header procedures of [1], or
• Set the To DS B8 field to one and From DS B9 field to one in the MAC Frame Control field, per section 9.2.4.1 of [1].
•遵循[1]的三地址MAC标头过程,或者
•根据[1]的9.2.4.1节,在MAC帧控制字段中将To DS B8字段设置为1,将From DS B9字段设置为1。
The backhaul STA shall set the RA field ("Address 1" (per Table 9-26 of [1])) in the Data frame sent over the backhaul link to the IEEE MAC individual address of the AP or group address. The backhaul STA shall set the TA field ("Address 2" (per Table 9-26 of [1])) in the Data frame sent over the backhaul link to the IEEE MAC individual address of the Backhaul STA.
回程STA应将通过回程链路发送的数据帧中的RA字段(“地址1”(根据[1]的表9-26))设置为AP的IEEE MAC单独地址或组地址。 回程STA应在通过回程链路发送到回程STA的IEEE MAC单独地址的数据帧中设置TA字段(“地址2”([1]的表9-26))。
If a Fronthaul AP sends a Data frame to an associated backhaul STA with a destination address (DA field) different from the IEEE MAC individual address of the backhaul STA, then the Fronthaul AP shall set the To DS B8 field to one and From DS B9 field to one in the MAC Frame Control field, per section 9.2.4.1 of [1].
如果前传AP将数据帧发送到关联的后传STA,且其目的地址(DA字段)与该后传STA的IEEE MAC单独地址不同,则前传AP必须将To DS B8字段设置为1,并将From DS B9设置为 根据[1]的9.2.4.1节,将MAC帧控制字段中的“ 1”字段更改为1。
If a Fronthaul AP sends a Data frame to an associated backhaul STA with a destination address (DA field) same as the IEEE MAC individual address of the backhaul STA, then the Fronthaul AP shall either:
如果前传AP使用与后传STA的IEEE MAC个人地址相同的目的地址(DA字段)向关联的后传STA发送数据帧,则前传AP应:
• Follow the Three-Address MAC header procedures of [1], or
• Set the To DS B8 field to one and From DS B9 field to one in the MAC Frame Control field, per section 9.2.4.1 of [1].
•遵循[1]的三地址MAC标头过程,或者
•根据[1]的9.2.4.1节,在MAC帧控制字段中将To DS B8字段设置为1,将From DS B9字段设置为1。
The Fronthaul AP shall set the RA field ("Address 1" (per Table 9-26 of [1])) in the Data frame sent over the backhaul link to the IEEE MAC individual address of the backhaul STA or group address. The Fronthaul AP shall set the TA field ("Address 2" (per Table 9-26 of [1])) in the Data frame sent over the backhaul link to the IEEE MAC individual address of the Fronthaul AP.
前传AP必须将通过回传链路发送的数据帧中的RA字段(“地址1”(根据[1]的表9-26))设置为回传STA的IEEE MAC单独地址或组地址。 前传AP必须在通过回传链路发送到前传AP的IEEE MAC个人地址的数据帧中设置TA字段(“地址2”([1]的表9-26))。
14.1.3有线回传帧和地址处理
Wired backhaul frame and address handling
Data frames shall be carried with Ethernet frames and handled per section 3 of [3].
数据帧应随以太网帧一起传送,并按[3]的第3节进行处理。
15 Multi-AP control messaging reliability
16 Higher layer data payload over 1905
17 Multi-AP control messaging
多AP控制消息使用[2]中定义的1905 CMDU格式来承载。 1905 CMDU包头包括“消息类型”字段,用于标识CMDU中携带的消息的类型。 多AP控制消息使用了1905消息保留的类型值。 多AP的TLV的定义均在1905 tlv Type值范围内。
后面请参照原版英文规范,基本为协议字段,没必要翻译。