1. easymesh是什么

简单的理解是AP client模式+一定规则的自动配置。easymesh协议即Multi-AP specification。是Wi-Fi联盟标准化各个厂家互联的一套标准。类似capwap协议作用（AC，AP连接标准化协议RFC5415/RFC5416，规范不同厂家的AC和AP互联）。
典型应用举例：

 

应用举例

2. easymesh网络结构

easymesh网络有两个逻辑实体：

• Controller

A Multi-AP Controller is a logical entity in a Multi-AP network that implements logic for controlling the fronthaul APs and backhaul links in the Multi-AP network. 

管理整个multi-ap网络拓扑，管理所有的agent（包括间接连接的agent）。控制整个网络的fronthaul aps和backhaul links。根据agents上报的ap的各种测量数据和能力数据，下发配置到各个ap，从而管理整个网络。

• Agent
  在multi-ap网络中，所有的ap都是agent角色。生效controller下发的配置，周期上报检测数据和能力信息给controller。也向其他agent提供接入的无线接口。
  1.3 组网示例

 

组网应用示例1

1. backhaul link (wired or wifi)
2. fronthaul link
3. controller interface

 

组网应用示例2

1. backhaul link
   Backhaul BSS 与Backhaul sta之间的链路
2. fronthaul link
   无线客户端跟ap fronthaul BSS的链路
3. backhaul sta
   Agent中有一个无线sta模式的接口，用于通过WPS与Fronthaul BSS连接获取Backhaul BSS的SSID和密码，然后连接到backhaul BSS。 疑问点：先连接Fronthaul ssid，如何知道连接哪个ssid去获取。
4. backhaul BSS
   用于建立Mesh链路的SSID（通常是hide）。
5. fronthaul BSS
   Multi-AP设备的对外无线接入点。有几个功能：无线客户端连接；提供WPS功能（用于建立backhaul link）用于backhaul sta建立Wi-Fi连接，通过WPS把backhaul BSS的SSID和密码传递下去；

---

可以看到有几种类型的SSID，通过association req或reassociation req中的扩展信元字段区分

3. easymesh的几个阶段

3.1 onboarding

onboarding流程是Multi-AP的agent在Multi-AP网络中通过Wi-Fi或者有线连接建立二层连接的过程。一旦通过onboarding建立了两层连接，agent就会开始discovery流程去发现controller。easymesh spec中定义了两种onboarding方法：

• PBC backhaul STA Onboarding
• DPP onboarding

3.1.1 PBC Backhaul STA Onboarding

An enrollee backhaul STA uses an extension to the PBC onboarding method, as defined in section 5.1, to indicate to an existing Multi-AP Agent that it is a backhaul STA (see Figure 4) 

待加入的agent ap的backhaul sta会使用关联帧（association req/reassociation req）里的扩展字段，向已经连接的agent ap（支持BSS backhaul sta连接）表明。具体MS流程如下：

 

Onboarding/Configuring BSS

 

IE format

 

802.1Q

1. enrollee agent: 待加入的agent
2. existing agent: 已加入Multi-AP的agent

• enrollee agent 的backhaul sta先跟existing agent 的fronthaul BSS连接，完成backhaul BSS配置后，就断开，去连接existing agent的backhaul BSS。（可能因为backhaul BSS是隐藏的，所以需要通过fronthaul BSS去下发backhaul BSS的配置）
• enrollee agent 的Backhaul sta向existing agent 的fronthaul BSS发送M1 message（扩展字段第7字节置1表明是Backhaul sta），existing agent收到M1消息发送M8消息携带Backhaul BSS的ssid和密码。如果已经被其他agent配置过，则直接连接配置过的Backhaul BSS。
• 总结：enrollee agent配置过Backhaul BSS则无需onboarding过程了，而是直接连接Backhaul BSS发现controller？。
• 问题

1. Backhaul BSS does not support WPS
   Fronthaul BSS supports WPS 这个信息如何从existing agent通知到enrollee agent？

3.1.2 DPP Backhaul STA and Multi-AP Agent secure onboarding

The Multi-AP DPP onboarding method enables a Multi-AP Agent that implements the DPP Protocol (see [18]) to onboard to a Multi-AP network using a Multi-AP Controller that implements DPP Onboarding. The onboarding can occur over Ethernet or over Wi-Fi via a Multi-AP Agent that implements the DPP Protocol acting as a Proxy Agent (as defined in section 5.3.4). 

agent可以用有线或无线通过DPP协议与controller完成onboarding过程，existing agent作为proxy传输DPP协议报文。

The DPP onboarding process begins when the Multi-AP Controller receives the bootstrapping information of the Enrollee Multi-AP Agent in the form of a DPP URI. Upon receipt of the DPP URI, the Multi-AP Controller instructs one or more existing Multi-AP Agents to advertise the CCE IE in their Beacon and Probe Response frames, if they are not doing so already, and listen to the Enrollee's DPP Presence Announcement frame. Once the Multi-AP Controller receives a DPP Presence Announcement frame from an Enrollee Multi-AP Agent, it initiates the DPP Authentication procedure by generating a DPP Authentication Request frame. A Multi-AP Agent, acting as a proxy, relays the DPP Authentication messages received from the Multi-AP Controller to the Enrollee when the DPP Presence Announcement frame with the correct hash is received from the Enrollee. The proxy performs a bi-directional converstion between a DPP frame carried in an 802.11 frame to a DPP frame encapsulated in a Multi-AP CMDU message. Upon successful authentication, the Enrollee Multi-AP Agent requests configuration by exchanging DPP Configuration Protocol messages (see 6.6 of [18]) with the Multi-AP Controller. 

通常Controller收到Enrollee agent的DPP URI格式的bootstrapping information即开始DPP onboarding流程.
Controller收到DPP URI，会让所有的existing agent在他们的Beacon 和 Probe帧广告CCE IE，如果他们还没这么做，Controller则会等待Enrollee agent的DPP Presence Announcement frame，Controller一旦收到此帧，开启DPP Authentication流程，Existing agent则作为proxy，转发controller的DPP Auth request msg，Enrollee收到agent的转发消息会选择该agent。并向Controller返回DPP authresponse消息。具体流程如下：

 

DPP Onboarding

当收到backhaul STA 和1905-layer的配置后，Enrollee agent会做以下事情：
• configures its backhaul STA interface,
• uses its backhaul STA to connect to a backhaul BSS of the Multi-AP network,
• discovers the Multi-AP Controller using 1905 AP-Autoconfiguration Search,
• initiates the DPP Network Introduction protocol (see section 6.6 of [18]) to exchange 1905-layer connectors,
• establishes a 1905 PMK with the Multi-AP Controller for its 1905-layer, and
• intiates a 4-way handshake to derive a 1905 PTK.

3.1.3 Data structures used in DPP onboarding

onboarding阶段，Controller和Enrollee agent配置消息交互是用json格式。

3.1.4 使用DPP onboarding对设备的要求

• controller只会给每个agent配置一个backhaul sta
• If an Enrollee Multi-AP Agent sends a DPP Configuration Request frame (see section 6.4.2 of [18] and Table 5), it shall:
  • include one DPP Configuration Request Object (see Table 5) • set the netRole to “mapAgent”
  • set wi-fi_tech to “map”
  • include the akm parameter, and
  • set the akm parameter value to the supported akm of its backhaul STA.
  If a Multi-AP Controller sends a DPP Configuration Response frame, it shall include:
  • Zero or one DPP Configuration Object for the backhaul STA
  • Zero or one DPP Configuration Object for the 1905-layer

3.1.5 Onboarding method via Wi-Fi with out-of-band DPP bootstrapping

out-of-band DPP bootstrapping如何理解out-of-band

If the Multi-AP Controller receives a DPP URI using any out-of-band DPP URI exchange (see section 5 of [18]), it shall send a DPP CCE Indication message containing one DPP CCE Indication TLV with the Advertise CCE field set to one and send it to one or more Multi-AP Agents that indicate support for DPP Onboarding - one of which will act as Proxy Agent during the onboarding process of an Enrollee Multi-AP Agent. If a Multi-AP Agent does not indicate support for DPP Onboarding, it responds with an Error Response message with a Profile-2 Error Code TLV with Reason Code set to 0x0D. 

如果Controller收到使用out-of-band DPP URI的DPP URI，它会发送一个包含了设置CCE字段设置为1的DPP CCE消息到一个或者多个Agents表明需要支持DPP Onboarding，其中的一个agent将会作为Proxy agent在Enrollee agent的Onboarding阶段。如果有agent不支持DPP，它会返回一个带错误码0x0D的TLV响应消息。

If a Multi-AP Agent sends a Beacon or Probe Response frame and the most recently received DPP CCE Indication TLV from the Multi-AP Controller had the Advertise CCE flag set to one, the Multi-AP Agent shall either include the CCE in the Beacon and Probe Response frames on all of its fronthaul BSSs or respond with an Error Response message with a Profile-2 Error Code TLV with Reason Code set to 0x0D. 

如果一个Agent发送一个Beacon或Probe response帧并且从controller收到DPP CCE标识TLV（CCE flag置为1），Agent就需要在它所有的Fronthaul BSS的Beacon和Probe Response帧都包含CCE，或者返回错误码0x0D。

If an Enrollee Multi-AP Agent supports onboarding over a Wi-Fi link, it shall support sending a Presence Announcement 
frame as specified in Section 6.2 of [18].
If a Proxy Agent receives a DPP Presence Announcement frame, the Proxy Agent shall check if the bootstrapping key 
hash in the DPP Presence Announcement frame matches any values of bootstrapping key hash of a stored DPP 
Authentication Request frame received from the Multi-AP Controller. If no matching hash value is found, the Proxy Agent 
shall send a Chirp Notification message to the Controller with a DPP Chirp Value TLV and shall set the fields in the TLV:
• Enrollee MAC Address present bit to one
• Hash Validity bit field to one
• Destination STA MAC Address field to the source MAC Address of the DPP Presence Announcement frame
• Hash Length field value to the length of the hash
• Hash Value field to the bootstrapping key hash received in the DPP Presence Announcement frame

如果一个Enrollee agent支持通过Wi-Fi的Onboarding，它就需要支持一个发送Presence Announcement帧。
如果一个Proxy agent收到一个DPP presence announcement帧，Proxy agent需要检查该帧中的bootstrapping key hash是否与从controller接收到的已存储的DPP Authentication request帧中的bootstrapping key hash相匹配。如果匹配，proxy agent应该发送一个携带DPP value 的TLV的Chrip Notification message给controller，并且设置TLV字段如下：

If the Multi-AP Controller that has been provided a DPP URI receives a Chirp Notification message with the Hash Value field matching the bootstrapping key hash from the DPP URI (see section 5 of [18]), the Multi-AP Controller shall send to all the Multi-AP Agents, using the CMDU reliable multicast transmission procedures, a Proxied Encap DPP message containing a 1905 Encap DPP TLV and a DPP Chirp Value TLV pertaining to that received DPP URI and set the fields: • In the 1905 Encap DPP TLV, the Multi-AP Controller shall set the DPP Frame Indicator to zero, the Frame Type to zero (DPP Authentication Request frame), set the Enrollee MAC Address Present bit to one and the Destination STA MAC Address field to the MAC address of the Enrollee received in the DPP Chirp Value TLV. • In the DPP Chirp Value TLV, the Multi-AP Controller shall set the Enrollee MAC Address present bit to one, Hash Validity bit field to one, the Destination STA MAC Address field to the MAC Address received in the Chirp Notification message, the Hash Length field set to the length of the hash, and the Hash Value field to the value computed from the DPP URI (as per Section 6.2.1 of [18]) 

如果controller接收到一个带有Hash匹配的Chrip Notification message，controller应该通过CMDU reliable multicast transmission 流程（一个代理的封装的DPP message包含一个1905 Encap DPP TLV和一个DPP Chirp value TLV包含以下信息：）给所有的agents。

If a Proxy Agent receives a Proxied Encap DPP message from the Multi-AP Controller that includes both a 1905 Encap DPP TLV containing an encapsulated DPP Authentication Request frame and a DPP Chirp Value TLV, the Proxy Agent shall decapsulate and store the DPP Authentication Request frame and listen for DPP Presence Announcement frames on the fronthaul BSS. 

如果一个Proxy agent从controller接收到一个包含1905
encap DPP TLV（包含一个封装的DPP authentication request frame和DPP Chirp Value TLV）代理封装的DPP message，Proxy agent 应该解封装它并存储DPP authentication request frame并同时开始在它的fronthaul BSS监听DPP Presence announcement frames。

If a Proxy Agent receives a Presence Announcement frame (chirp) with bootstrapping key hash from the Enrollee Multi�AP Agent that matches the Hash Value field of the DPP Chirp Value TLV received from the Multi-AP Controller, the Proxy Agent shall send the DPP Authentication Request frame to the Enrollee within 1 second of receiving the Presence Announcement frame from that Enrollee, using a DPP Public Action frame to the MAC address from where the Presence Announcement frame was received. 

如果一个Proxy agent从Enrollee agent接收到带有bootstrapping key hash（并且与一个跟从controller发来的DPP Chirp value TLV种的hash匹配）的Presence announcement frame（chirp），proxy agent需要在接收到的1s内向enrollee agent 发送DPP authentication request frame。
如果proxy agent接收到enrollee的802.11 ACK frame，在DPP authentication request frame到enrollee 期间，proxy agent 会忽视掉DPP authentication request frame。为什么要忽略掉呢？

If the Enrollee Multi-AP Agent receives a DPP Authentication Request frame that includes its own bootstrapping key hash (i.e., meant for itself), it shall respond with a DPP Authentication Response frame and ignore any subsequent DPP Authentication frames it may receive from other Multi-AP Agents. 

如果enrollee agent 接收到带有它的bootstrapping key hash的DPP Authentication request帧，它应该回复一个DPP Authentication response帧并忽略掉之后收到的其他agent的Authentication frames。

If the Controller has not received a DPP Authentication Response frame and the DPP Authentication Protocol times out 
(see [18] for timers), the Controller shall restart the DPP Authentication Protocol as per section 6.3 of [18] by resending the DPP Authentication Request frame. 

controller没有收到DPP authentication request response帧，并且等待超时了，controller会重启DPP 认证协议重新弄发送DPP authentication request frame。

If a Proxy Agent receives a DPP Public Action frame with Frame Type field set to one or 16 (DPP (Reconfiguration) Authentication Response) in response to a DPP (Reconfiguration) Authentication Request from the Enrollee Multi-AP Agent, it shall generate a Proxied Encap DPP message containing a 1905 Encap DPP TLV with the Encapsulated frame field set to the received DPP Public Action frame body, the Enrollee MAC Address Present bit set to one, the Destination STA MAC Address field set to the Enrolee's MAC address, the DPP Frame Indicator bit set to zero and the Frame Type field set to one (or 16), and shall send the message to the Multi-AP Controller. 

如果proxy agent收到一个从enrollee agent发送来的针对DPP authentication request frame响应的帧类型字段为1或16 DPP（DPP reconfiguration authentication response） public action frame。proxy agent 应当向controller发送一个包含1905 encap DPP TLV Proxied encap DPP消息。controller收到这个消息需要在1s内回复一个1905 ack。

• DPP configuration via Wi-Fi

 

DPP configuration via Wi-Fi

• Encapsulation of DPP Public Action frames and DPP GAS frames into TLVs

 

 

lDPP in 802.11 Action Frame

3.1.5 Onboarding Method via a Multi-AP Logical Ethernet Interface with out-of-band DPP

bootstrapping

 

DPP onboarding via logical ethernet interface

3.1.6 Onboarding method via Wi-Fi with inband DPP bootstrapping using Push Button


问题：inband和out-of-band区别

 

Onboarding/Configuration BSS

 

 the Presence Announcement frame is generated by the Enrollee Agent on a periodic basis and might be sent prior to or after the Enrollee Agent sending M7 with DPP Bootstrapping URI message. For example, Figure 13 shows the Presence Announcement frame being sent before and after the DPP Bootstrapping URI message has been sent. Presence Announcement frames sent prior to sending the M7 with DPP Bootstrapping URI message to the Controller will not trigger the DPP Authentication procedure. 

presence announcement frame 是由enrollee agent定期产生的又可能在enrollee agent发送带DPP bootstrapping URI的M7消息之前或之后发送。如果先于M7发送，将不会触发DPP authentication流程。
3.1.6 establishing secure 1905-layer connectivity
3.1.7 DPP onboarding after PBC Backhaul STA Onboarding
3.1.8 Reconfiguration

3.2 discovery

discovery流程是用于在Multi-AP网络发现Controller和Agents。

3.2.1 Multi-AP controller discovery

一个Multi-AP网络由一个controller配置。

If a Multi-AP device can be configured as a Controller through an out-of-band mechanism (e.g., through UI or Service Provider configuration), the configuration shall be stored in non-volatile memory and the configuration shall be used after restart of the device. 

如果一个设备通过out-of-band机制被配置为controller，这个配置需要持久化在设备，设备重启也能使用。

 If a Multi-AP device implements an Agent and a Controller, then it might provide an out-of-band mechanism by which a user can disable the Controller function if they wish to onboard this as a Multi-AP Agent to an existing Multi-AP network. For example, this could be implemented directly by presenting the user with a Controller on/off selection or indirectly by presenting the user with a choice such as “Is this a new network or an existing network?”. 

一个即是controller又是agent的设备，如果想onboard到另一个Multi-AP 网络，需要人为关闭controller开关。

If a Multi-AP device implements an Agent and a Controller and the Agent initiates onboarding onto an existing Multi�AP network (see section 5) using a Wi-Fi interface, it might disable its Controller functionality and store this configuration in its non-volatile memory. 

如果一个即是controller又是agent的设备已经onboard到其他Multi-AP网络，它会关闭它的controller功能，并持久化该配置。自动关闭？也就是说一个设备不能同时属于两个Multi-AP网络？

3.2.2 Multi-AP service discovery

是1905 Topogy query/response 流程的扩展。发现Multi-AP的设备能力信息。

3.2.3 Client association and disassociation notification

是1905 Topology Notification message的扩展，让agents可以快速知道client的association 和diassociation事件。
如果一个Wi-Fi客户端连接或断开Multi-AP中设备上的BSS，agent应该发送带有client association TLV 的1905 Topology Notification message 给controller。如果是断开还需要携带客户端流量统计等信息的TLV。

3.3 configuration

3.3.1 AP configuration

使用1905 AP-Autoconfiguration 流程使controller完成对agent上的802.11接口的配置。对于未配置的无线接口，agent都以“uncofiguration 802.11 interface”对待。controller通过1905 AP-Autoconfiguration WSC messages或者AP policy config request messages配置agent的流控策略。
agent应该每个radio都单独发送1905 AP-Autoconfiguration WSC message去配置
当agent 接收到一个1905 AP-Autoconfiguration renew message，agent需要保留所有之前接收到的配置，除非被autoconfig renew procedure更新。
Multi-AP Profile-1、Multi-AP Profile-2、Multi-AP Profile-3的含义？

3.3.2 AP operational BSS reporting

3.3.3 Policy configuration

controller send Multi-AP Policy Config request message to agent ，when agent received shall respond within one second with a 1905 Ack message。
主要是哪些policy呢？流控？

3.4 channel selection

3.4.1 channel preference query and report

controller 发送 channel preference query message到agent，agent收到该消息需要1s内回复channel preference report message消息需要携带跟query消息同样的MID（message id）。如果agent支持6GHz信道。。。
如果agent的信道改变了，他需要发送一个unsolicited channel preference report 给controller。
如果agent检测到任何信道的DFS状态变化，也需要发送unsolicited channel preference report 给controller。
controller收到unsolicited channel preference report 需要在1s内响应1905 Ack message。

3.4.2 channel selection request and report

controller发送channel selection request message，agent收到后需要在1s内回复response消息。
如果agent调整完信道，需要发送operating channel report message，controller 1s内回复1905 ack message。

3.4.3 coordinated DFS CAC

controller 发送一个CAC request message给agent。

3.4.4 spatial reuse

3.5 capability innformation reporting

3.5.1 ap capability

ap capability query message
ap capability report message

3.5.2 client capability

client capability query message
client capability report message

3.5.3 backhaul sta capability

backhaul sta capability query message
backhaul sta capability report message

3.6 link metric collection

3.6.1 Backhaul link metrics

**The 1905 link metric information dissemination protocol **is used to query and report link metrics for backhaul links (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]).
三个字段：macThroughputCapacity field、linkAvailability field、RSSI field
macThroughputCapacity field：评估backhaul链路mac层上下行数据传输速率单位Mb/s
linkAvailability field：预测当前backhaul 链路在当前信道环境下的空口占用率。
RSSI field：

3.6.2 Per-AP metrics and bulk STA metrics

这节定义了multi-ap agent传输每个ap运行中的fronthaul和backhaul的BSS质量信息。

3.6.2.1 link metric measurements from the ap

controller 发送 ap metrics query message 到agent，agent收到消息需要1s内回复带ap链路质量的响应消息。包含以下TLV：
• One AP Metrics TLV per section 17.2.22 for each of the BSSs specified in the query.
• One AP Extended Metrics TLV for each of the BSSs specified in the query.
• One Radio Metrics TLV for each of the radios specified in the query.

3.6.2.2 channel scan

（这块跟capwap协议类似）
agent在启动时或者收到controller请求消息时，agent要上报各个信道的扫描情况到controller。
controller 发送channel scan request message给agent，agent收到消息后需要1s内发送ack消息。扫描完成agent发送channel scan report message 到controller，controller收到消息1s内回复一个1905 ack消息。

• onboot scan（ “On boot only” bit to 1 in its Channel Scan Capabilities TLV）
• requested channel scan（fresh）（”On boot only” bit to 0 in its Channel Scan Capabilities TLV）
• requested channel scan（stored）
• independent channel scan

3.6.2.3 anticipated channel usage

agent发送Anticipated Channel Usage Report message上报每个信道的预期使用情况。

3.6.3 per-sta measurements

3.6.3.1 associated sta link measurements from the ap

agent 上报上下行终端的链路质量。
controller 发送 Associated STA Link Metrics Query message给agent，agent收到消息需要1s内回复associated sta link metrics response消息。

3.6.2.4 unassociated sta rcpi measurements from the ap

在ap capability tlv中配置是否开启功能

3.6.2.5 802.11 beacon measurements from client

controller或agent发送一个beacon metrics query message 到一个agent，agent收到消息1s内回复ack消息。如果需要搜集的终端未连接则ack消息中需要携带错误码0x02。agent收到消息需要做以下事情：
• Send an 802.11 Beacon request to the STA.
• If the STA indicates support for Active and/or Passive 802.11 Beacon measurements, the Multi-AP Agent may set
the Measurement Mode field in the Beacon request to Active or Passive unless an active QoS-sensitive traffic
stream exists which the Multi-AP Agent expects would be unduly impacted by Active or Passive measurements,
in which case Beacon Table mode may be requested.
• If the value of the SSID Length field in the query is non-zero, an SSID subelement shall be included in the 802.11
Beacon request, and shall be set to the value of the SSID field in the query. Else, an SSID subelement shall not
be included.
• The Operating Class, Channel Number, BSSID and Reporting Detail fields in the Beacon Request shall be set to
the corresponding values specified in the query
• If the value of the Number of AP Channel Reports field (h) in the query is greater than zero and the value of the
Channel Number field in the query is 255, then h AP Channel Report subelements shall be included in the 802.11
Beacon request, each containing the specified Operating Class and Channel List.

3.7 client steering

• Multi-AP Controller initiated steering mandate
  controller 发送client steering request message request mode set to 1到agent，agent收到1s内回复1905 ack 消息。
• Multi-AP Controller initiated steering opportunity
  controller 发送client steering request message request mode set to 0到agent，agent收到1s内回复1905 ack 消息。
  如果是opportunity，agent 调整完终端后，需要向controller发送steering completed message 带新的MID。controller 收到后1s内回复1905 ack消息。
• Multi-AP Agent initiated RCPI-based steering
  RCPI-based steering is used to allow a Multi-AP Agent to steer an associated STA to another BSS when the RCPI of the
  current connection becomes low.
  A Multi-AP Controller sets the steering policy on a Multi-AP Agent using the Steering Policy TLV。agent收到配置：
  1）steering policy field is set to 0x00：(Agent-initiated Steering Disallowed)
  2）If the Steering Policy field is set to 0x01： (Agent-initiated RCPI-based Steering Mandated)
  3）Steering Policy field is set to 0x02 (Agent-initiated RCPI-based Steering Allowed)
• RCPI-based steering rules
• Multi-AP Agent determination of target BSS
• Steering mechanisms
• Client association control mechanism
  controller或agent 发送给agent Client Association Control Request message，agent收到消息1s内回复1905 ack消息

3.8 backhaul optimization

在onboarding阶段，backhaul sta可能已选择BSS连接。controller可以控制其连接不同的BSS。
controller 发送Backhaul Steering Request message给agent要求qgent连接不同的BSS。agent收到该消息，需要1s内回复1905 ack消息并尝试连接消息中的目标BSS。如果连接成功或者超时10s，agent需要发送backhaul steering response message给controller，错误吗0x00，如果连接失败也发送backhaul steering response message给controller，错误吗0x01。controller收到response消息，1s内回复1905 ack消息。

3.9.1 Backhaul optimization by backhaul station association control

3.9 Multi-AP messaging security

3.9.1 1905-layer security capability

A Multi-AP device that indicates support for DPP Onboarding shall indicate its 1905-layer security capability in the 1905 Layer Security Capability TLV by setting the onboarding protocols supported field to '0x00', the supported message integrity algorithm to '0x00' and the supported encryption algorithm to '0x00'. 

3.9.2 message intetrity code(消息完整编码)

** CMDU is short for Control Message Data Unit**

 CMDU relayed multicast transmission procedures (see section 7.3 of [2] or CMDU reliable multicast transmission procedures (see section 15.1), it computes a Message Integrity Code (MIC) value over all of the enclosed TLVs and inserts the value in a MIC TLV into the message (see Figure 15). The receiver independently computes the MIC value and ignores and discards any message with a received MIC value that is different than the transmitted MIC value. 

CMDU在传输消息会根据所有封装的TLV计算一个MIC值（message integrity code）并放到MIC TLV放到消息中，接收者也计算MIC并跟TLV中的MIC比对，不一致则丢弃消息。
怎么计算：
支持DPP onboarding的controller会生成一个1905 GTK（Group Temporal Key）和与之关联的一个key id并把它分发给每个agent在onboarding或rekeying阶段。agent就是根据这个1905GTK去计算MIC的。

为了防止消息重传攻击，发送者用一个完整传输计数器在MIC计算过程中，发送消息后发送方计数自增1，计数放在MIC TLV中。接收方只需判断计数是否大于之前的即可。

 

1905 Message Format

3.9.2.1 MIC transmission requirements

发送消息前Multi-AP device需要做以下事情：
• Compute a 256-bit MIC field using HMAC-SHA256 (see [16]) with the 1905 GTK as the key, and the
message_array consisting of the following inputs concatenated in the order shown below:
▪ The first 6 octets of the 1905 CMDU (see Table 6-3 in [2]).
▪ The first 13 octets of the MIC TLV Value (1905 GTK Key ID field, MIC Version field, reserved bits, Integrity
Transmission Counter field, and Source 1905 AL Mac Address field) (see Table 85). ▪ All of the TLVs included in the message (including the End of Message TLV), but not the MIC TLV.
• Include the 1905 GTK Key Id, MIC Version field set to 0x00, Integrity Transmission Counter and the MIC in a MIC
TLV (see section 17.2.68).
• Include the MIC TLV in the message, immediately preceding the End of Message TLV as shown in Figure 15. • Increment the Integrity Transmission Counter by one.

3.9.2.2 MIC reception requirements

接收消息前需要做以下事情（打开1905 security的情况下）：

• 检查是否携带MIC TLV
• 检查消息计数字段是否大于当前计数
• 计算MIC并与消息中的MIC之比对

3.9.3 1905-layer encryption

1905PTK是发送和接收方通过1905 4次握手产生的。用于加解密消息。
为了防止重传攻击，发送方同样使用消息计数，每发送一个消息，计数自增1.每次接收到消息与上次消息计数比对大小。

 

1905 Message Format for Encryption

3.9.3.1 encryption requirements

message only transmitted with CMDU unicast transmission procedures (see section 7.4 of [2]) 发送消息前需要做以下事情：

 

encryption-requirements.png

3.10 Four-address MAC header format

这一章需要仔细理解

3.11 其他规则说明

3.11.1 CMDU reliable multicast transmission

• 重传机制

3.11.2 1905 CMDU adjustments

• CMDU分片

3.11.3 Order of Processing

• Transmission Order
  准备发送消息按顺序：
  • collects the underlying information that will be transmitted in one or more TLVs (see section 17.2) (some TLVs
  might have a length exceed 1492 octets)
  • if the message transmission procedures (see Table 16) use encryption, perform the encryption transmission
  procedures (see section 13.3.2)
  • if the message transmission procedures (see Table 16) use message integrity check, perform the MIC
  Transmission procedures and insert the MIC TLV (see section 13.2.2)
  • if the aggregate of TLVs exceed 1492 octets, perform CMDU fragmentation (see section 15.2 above and section
  7.1.1 of [2])
• Reception Order
  • if lastFragmentIndicator is zero, perform and complete CMDU reassembly (see section 7.1.2 of [2])
  • if any TLV is a MIC TLV, perform the MIC Reception procedures (see section 13.2.3)
  • if any TLV is an Encryption Payload TLV, perform the decryption reception procedures (see section 13.3.3)
  • process the underlying information contained in the TLVs (see section 17.2)

3.12 Higher layer data payload over 1905

4. Multi-AP control messaging

Multi-AP control message 使用1905 CMDU格式。
1905 CMDU 头包含一个msg type字段标识CMDU中消息类型。
end of message TLV只在分片报文的最后一片携带即可。