Wi-Fi越来越多地用于有各种QoS要求的应用和服务,为了提供可靠的服务交付和品质更高的体验, Wi-Fi QoS Management以WMM为基础,帮助AP和STA为已识别IP流量分配相关优先级的接入类别,并提供可靠的服务交付和高质量实时应用体验。
Acronyms | Definition |
---|---|
DSCP | differentiated services code point |
MSCS | Mirrored Stream Classification Service |
UP | User Priority |
AIFS | Arbitration Inter Frame Spacing |
AIFSN | A rbitration Inter Frame Spacing Number |
USP | Unscheduled Service Period: period started when a WMM STA transmits a Trigger Frame to the WMM AP |
EDCA | Enhanced Distributed Channel Access |
EDCF | Enhanced Distributed Coordination Function |
Group traffic | Multicast and broadcast traffic |
TID | Traffic Identifier |
TS | Traffic Stream |
Un-admitted AC | Traffic transmitted using an AC that did not require admission |
SP | Service period: a contiguous time during which one or more downlink unicast frames are transmitted to a WMM STA and/or one or more TXOPs are granted to the same WMM STA. Service Periods can be Scheduled or Unscheduled. For a WMM STA, there can be at most one Service Period active at any time. |
TXOP | Transmission Opportunity: An interval of time when a particular WMM STA has the right to initiate transmissions onto the wireless medium (WM). |
802.11e的优先级实际通过802.1d(802.1p&802.1q)的优先级映射的。
802.1d不同的DSCP(实际为ToS)对应到CoS(code of service),不同CoS实际对应到了不同的服务优先级类型,其实也对应了802.1d的用户优先级(UP)。
AC(Access Category) | Designation | Destination |
---|---|---|
AC_VO | Voice | 一般为VoIP流量类型,对延迟最为敏感,同时也是优先级最高的流量。 |
AC_VI | Video | 视频流量的优先级低于语音服务,高于其他两项。视频服务也是延迟敏感类型的服务,所以具有一定的优先级 |
AC_BE | Best-effort | 默认的无线流量类型就是best-effort类型,比如网页访问的数据流量类型。对于延迟有一定需求,但是没有那么敏感 |
AC_BK | Background | 对于延迟要求最不敏感的流量,比如文件传输,打印作业的流量 |
在不区分业务类别和发送队列的情况下,可能会引起“队头阻塞”,就是在发送设备内,第一个数据包挡住了队列中的其余数据包的情况。
而区分了不同业务类别作为不同发送队列以后,当发送设备为分配到不同接入类别的混合数据包排队时,即使其他优先级较低的数据包已经处于等待发送状态,高优先级数据包也会排在发送队列的最前面。这可最大限度降低由“队头阻塞”引起的延迟。
Wi-Fi QoS Management™技术扩展了Wi-Fi CERTIFIED WMM™的功能,其中Wi-Fi CERTIFIED QoS Management™是Wi-Fi Alliance® 的一项可选认证计划。该技术可在Wi-Fi网络中简化对延迟敏感型互联网协议(IP)流量的优先级划分和管理,对IP数据流分类,并将其映射到WMM®定义的Qos接入类别之一,以帮助确保将实时应用和服务的流量插入优先级更高的队列中,从而带来更好的最终用户体验。
Wi-Fi QoS Management认证计划主要包含两项主要功能:
功能 | 名词解析 | 说明 |
---|---|---|
MSCS | 镜像流分类服务(Mirrored Stream Classification Service) | 使STA能够利用QoS镜像,管理AP对下行链路IP流的 QoS处理 |
DSCP | 差异化服务代码点(Differentiated Service Code Point) | 映射使网络管理员能够在AP和STA上配置IP数据包报头中的DSCP标记和无线QoS处理之间的映射 |
这两项功能都运用了基于IEEE 802.11 QoS机制的WMM。
Wi-Fi QoS Management认证强制要求支持这两项功能。
IEEE 802.11-2020中定义,如果支持Wi-Fi QoS Management,则AP和STA必须支持MSCS。
当进入AP的下行链路IP流无适当DSCP标记(对于源自公用互联网的下行链路IP流,缺少适当的DSCP标记是常见情况,因为中间节点或互联网服务提供商即ISP经常会将源服务器可能已经设定的任何DSCP标记重置为零或对其进行修改),DSCP-to-UP Mapping无法实现基于DSCP实现所需的QoS优先级划分,此时就需要用到MSCS。
MSCS提供基于L2、L3信令建立分类的方法。 AP根据STA发送而来对应的MSDU的映射规则(即所谓的镜像或反向),为自身来自L2/L3的单播MSDU分配一个用户优先级(UP)。
这是通过监测IP报头和802.11 MAC报头中的用户优先级值完成的。
MSCS的实现是可选的。
支持Wi-Fi QoS Management的设备在 (Re)Association Request/ Association Response/Beacon/ Probe->Extended Capabilities->(Mirrored )SCS中指明对MSCS的支持。
MSCS设置过程MSCS的激活由STA通过以下方式启动:
这个过程涉及为协商MSCS参数而进行的单次请求/响应交换,可在关联时或关联后的任何时间完成。
对于每个STA而言,AP最多有一个激活的MSCS。
如果AP接受STA的请求,就会激活用于该STA的MSCS,或者如果已经激活,就更新该MSCS的参数。然后,如果在关联时接到请求,那么AP通过在 (Re)Association Response帧中放入指明为Success的MSCS Descriptor来做出响应;或者,如果在关联后接到请求,那么就在MSCS Response中指明Success。AP单独保持每个STA的MSCS状态。以上意味着,协商商定的MSCS参数和生成的下行链路QoS规则是特定于每个STA的。
如果AP不接受请求,就会提供一个可能指明拒绝原因的状态码,例如处理资源不足,或不被支持的TCLAS Mask参数。
AP和STA可以随时终止一个活跃MSCS。
MSCS终止流程发起方 方法 其他
AP AP通过自发地向STA发送MSCS response,终止与该STA的MSCS MSCS response可能指明终止原因的状态代码值。终止原因的例子包括,由于所生成的QoS规则数量过多而导致处理资源耗尽,或支持所生成的QoS规则的网络容量不足。
STA TA通过发送Request Type=remove的MSCS request,终止MSCS N/A
自动隐式终止 STA不再与AP关联,或与同一AP重新关联时,AP和STA之间的任何活跃MSCS都会隐式终止 N/A
尽管在STA漫游时,有可能某些网络架构会在AP之间交换MSCS QoS规则,或者会基于MSCS规则得出整个网络的QoS策略,但是一般而言,不应期望MSCS规则或状态传播到单个BSS以外。
如果STA与AP之间有已激活的MSCS,之后漫游到网络中的另一个BSS且仍希望继续使用MSCS,那么通常STA需要在漫游(重新)关联期间或在其之后立即请求激活与目标BSS中新的AP之间的MSCS。
无论目标BSS是否由相同的物理AP运行,上述做法都适用。漫游后,直到STA在相应的上行链路IP流中向目标BSS发送至少一个数据包以便AP可以生成相应规则以后,才会为下行链路IP流分配所期望的用户优先级。
MSCS request/response是一种action帧,作为Robust AV Streaming Action frame的一种变体。
MSCS Request(Add):
MSCS Request(Remove):
MSCS Response(Add):
MSCS Response(Remove):
Request Type | Description |
---|---|
Add(0) | STA请求激活MSCS |
Change(1) | MSCS已经激活且STA请求修改MSCS参数 |
Remove(2) | 停用MSCS |
Reserved(3-255) | 预留 |
如下情况下,该字段为reserved:
以下分别对User Priority Control下的各个子字段简要说明。
User Priority Bitmap的每个bit对应一个用户优先级(User Priority, UP),B0对用UP=0,依此类推。
Bit value in User Priority Bitmap(B0~B7) | Description |
---|---|
0 | 对应的UP不被MSCS用于分配UP |
1 | 对应的UP可被MSCS用于分配UP |
AP监测包含在所接收上行链路数据包中的这些数字,以确定下行链路的QoS规则。
一般情况下,STA会将位图设置为仅指示UP=4、5、6和7,对应VO和VI。这么做的目的是,使AP基于STA以VO和VI发送的上行链路IP流,生成下行链路QoS规则时,但不为以BE或BK发送的上行链路IP流生成QoS规则,有助于避免在AP上产生过多的处理开销(例如,AP不必要地针对不需要特殊QoS处理的、对应于BE和BK的下行链路IP流生成规则)。
User Priority Limit限制了在MSCS分类的流中分配给传入MSDU的UP的最大值,User Priority Limit值范围0~7,一般设置为7(最高),这种情况下位图中的所有用户优先级均按原值进行镜像。
例如,某些企业网络也许设定了网络策略,仅允许MSCS镜像值最大为VI的用户优先级5,即User Priority Limit=5,在这种情况下,AP基于STA发送的用户优先级6或7的上行IP流生成的QoS规则会受到限制,并分配用户优先级=5。
Stream Timeout指示了从QoS规则生成之时或最近更新之时开始,要求AP保持下行链路QoS规则的最短时间,单位TU。
通常情况下,STA将这一数值设定为60s或更短,以便AP可以高效删除掉不再活跃的IP流有关的下行链路QoS规则。
如下情况下,该字段为reserved:
一般而言,AP的实现方式要能够保持相应于目前活跃的下行链路IP流的下行链路QoS规则。如果AP确实删除了用于仍然活跃的下行链路IP流的QoS规则,那么后续从STA接收的相应上行链路IP流中的数据包将使得AP为该下行链路流生成新规则。
TCLAS(Traffic Classification) Mask指明了MSCS中如何将MSDU分类,分类方法主要基于TCLAS Mask element->Frame classifier –>classifier mask。
一般包含0~多个TCLAS Mask。
Case | TCLAS Mask Count |
---|---|
Request Type = Add或者Change | 1~more |
Request Type = Remove | 0 |
(Re)Association Response->Data->MSCS Status = Success | 0 |
Request Type = Add && (Re)Association Response->Data->MSCS Status != Success | 0 |
以下介绍一下Frame classifier各个字段。
其中包含多种特殊情况,太过繁琐本文不展开,详见《802.11-2020》9.4.2.30 TCLAS element。
一般而言是指示了用于分类的,也即classifier parameters中包含的参数。
如下便是从Classifier Mask比特位置映射到对应的目标字段。
不同的classifier type对应不同含义的Classifier Mask,详见《802.11-2020》9.4.2.30 TCLAS element。
指示了结合Classifier Mask,用于分类的参数值。
不同的classifier type对应的classifier parameters不同,,详见《802.11-2020》9.4.2.30 TCLAS element。
例如,STA设置TCLAS Mask->Frame Classifier->Classifier Type=4,即指明随后是IP and higher layer的参数。设定的Classifier Mask指明将基于完整的IP 5元组{源IP地址、目标IP地址、源端口、目标端口、协议、下一个报头}定义该QoS规则。这一系列报头字段也适用于IPv4和IPv6流。
TCLAS Mask未针对任何特定的流规定实际的IP多元组的值,它只是规定一系列用于对每个流进行独一无二的识别和分类的IP报头字段。
在某些用例中,选择非标准的TCLAS Mask参数列表也许是有益的。例如,如果STA上的应用意图利用不同的本地端口建立大量与相同的远程IP地址和端口的短期连接,而且所有这些连接的上行链路用户优先级是相同的,那么STA可以从TCLAS Mask码元列表中省略Destination Port,以帮助最大限度减少AP生成的下行链路QoS规则的数量。
STA必须确保,在发送将被AP看作是相同上行链路IP流组成部分的上行链路数据包时,所使用的用户优先级不会在数据包之间快速波动。否则,分配给相应下行链路QoS规则的用户优先级将是不稳定的。STA应规定足够具体的TCLAS Mask参数,以避免这类不稳定性。
当AP拒绝一个MSCS请求,AP可以选择规定准备接受的另一组MSCS参数。例如,如果STA请求User Priority Limit为7,但是网络策略仅允许MSCS镜像到用户优先级5,那么AP可能在其拒绝响应中指明User Priority Limit为5。然后,如果STA仍然想要激活MSCS,就可以发送一个新的请求,其中所请求的User Priority Limit为5。
如果网络策略完全禁止使用MSCS,也许是因为该策略要求将DSCP-to-UP映射严格应用于所有下行链路IP流,那么AP可能会拒绝MSCS请求。不过,如果网络策略仅规定QoS处理用于某些IP流,而不用于其他IP流,那么这些策略有可能与MSCS共存。在这种情况下,AP可能接受STA做出的MSCS请求,并继续遵循针对那些特定流的网络策略,同时使用MSCS规则为其他下行链路IP流设定用户优先级。
一旦在AP处激活了针对给定STA的MSCS,该AP就会监测从该STA接收的上行链路数据包。在802.11 MAC头的QoS Control->TID中指明用户优先级。如果从客户端收到了含有IP数据包的单独寻址单播QoS Data帧,且其用户优先级与User Priority Control->User Priority Bitmap中的一个值相匹配,那么AP就会通过从这个已接收数据包中提取IP报头字段的值,来生成或更新相应的下行链路QoS规则,如TCLAS Mask中所规定的那样。
举个例子,假设与STA商定的MSCS参数如下所示:
当AP从STA接收到如图所示的上行链路QoS data,且QoS Control字段中指明的用户优先级为7。
则生成的下行链路QoS规则:
{SrcIPAddr=WAN_IPADDR; DstIPAddr=STA_IPADDR; SrcPort=WAN_PORT; DstPort=STA_PORT; ProtNxtHdr=6},UP=5。
已接收上行链路帧中的DstIPAddr& DstPort用作下行链路QoS规则分类器中的SrcIPAddr& SrcPort,反之亦然。分配给这个规则的用户优先级确定为上行链路数据包的用户优先级 (本例=7)和商定的User Priority Limit(5)之中的最小值。
如果收到另一个具有相同IP多元组数值的上行链路数据包,且如果这个数据包的用户优先级与规则当前分配的用户优先级不同,那么就用这个用户优先级更新当前分配给规则的用户优先级。这意味着,STA仅通过更改其发送的相应上行链路IP流的用户优先级,或者间接地,通过改变其DSCP标记,就可以使AP动态修改对下行线路IP流的QoS处理。
基于MSCS的处理,AP的实现可以使用各种优化方案,以最大限度减少数据包处理开销及所需生成的规则数量,例如:
如果用来配置AP的网络策略所使用的机制超出了Wi-Fi CERTIFIED QoS Management计划的范围,且该网络策略适用于下行链路IP数据包,那么该策略可以优先于MSCS QoS规则用来进行用户优先级分配。这类策略可能还包括ICMP、DNS、DHCP等网络控制协议。
如果与流量关联的TCLAS分类器与下行链路IP数据包相匹配,那么TCLAS分类器也优先于MSCS QoS规则用来进行用户优先级分配。请注意,这不适用于为WMM-Admission Control或WMM-Power Save商定的任何流量,因为这些流量与TCLAS分类器无关。
如果这些更高优先级的规则不适用于下行链路IP数据包,且下行链路IP数据包与MSCS规则相匹配,那么AP就将规则中规定的用户优先级分配给该数据包。
如果下行链路IP数据包与上述任何策略或规则都不匹配,那么默认情况下,将基于DSCP映射分配其用户优先级。例如QoS Map,下文将进行更多的介绍。
MSCS功能着眼于为下行链路IP流分配恰当的用户优先级和接入类别。它无意于管理其他互补性QoS处理机制,例如无线资源预留、对给定接入类别的发送队列内的数据包进行管理以及数据包整形等核心网络流量管理。这些处理机制可能由包括WMM-Admission Control在内的其他网络策略和/或协议处理。
MSCS可用于管理所有具备以下特点的下行链路IP流的QoS处理:具有相应的、使用对称IP地址和端口的上行链路IP流。
在使用有状态且本质上是双向的TCP协议的情况下,会使用相同的套接字或IP地址和端口进行发送和接收,且相应的下行链路和上行链路IP流一起形成TCP会话。所有TCP会话的下行链路数据包的QoS处理均可以使用MSCS进行管理。即使用户数据的传送基本上仅为下行链路方向,为建立初始TCP会话所发送的任何上行链路数据包,例如SYN或ACK,也足够AP生成正确的下行链路IP规则了,只要使用恰当的用户优先级发送上行链路数据包即可。
同样,尽管QUIC(Quick UDP Internet Connection)协议使用UDP作为底层的第四层协议,但它使用对称端口创建有状态的双向会话,且所有QUIC会话的下行链路数据包的QoS处理均可用MSCS进行管理。
实际上,其他很多基于UDP的协议也具有这些特点,因为,即使这些协议不一定建立正式的双向会话,它们也确实需要下行链路IP数据包通过NAT(Network Address Translation)或对等设备之间通常存在的其他有状态防火墙。
例如,在防火墙后的对等设备使用STUN服务器与另一个远程对等设备建立点对点VoIP通话的情况下,该设备使用相同的套接字或本地IP地址和端口发送和接收VoIP数据包。这样一来,该设备向远程对等设备发送初始数据包以后,本地防火墙就会接收和转发后续从远程对等设备接收的数据包。两个方向的数据流将有对称的IP地址和端口,且初始出站的VoIP数据包足以使AP生成正确的规则,以使用MSCS对来自对等设备的入站下行链路VoIP数据包进行QoS处理。
在虚拟专网(VPN)连接情况下,例如使用IPsec,常常使用TCP或UDP封装为NAT遍历提供方便,而且外部IP地址和端口通常是对称的。在很多情况下,VPN客户端使用恒定的用户优先级发送所有上行链路VPN数据包,而不考虑有效载荷或VPN隧道内的内部IP报头上的任何DSCP标记。在这类情况下,可以用MSCS管理下行链路VPN数据包的QoS处理。如果VPN主要承载视频流量,那么VPN客户端可以使用用户优先级4或5(VI),来发送所有上行链路VPN数据包。在这种情况下,如果MSCS已激活,那么还会使用相同的用户优先级和接入类别发送相应的下行链路VPN数据包。
此外,如果VPN客户端逐个数据包动态改变用来发送上行链路VPN数据包的用户优先级,那么激活MSCS可能导致AP非常频繁地更新用于下行链路VPN数据包的QoS规则。由于这会导致下行链路VPN数据包的QoS处理的不稳定性,所以不建议在这种特定情况下激活MSCS。其他选项可能包括:在VPN服务器恰当标记每一个下行链路数据包且DSCP标记在进入AP时保持完整的情况下,使用下行链路DSCP标记。另一种选择是,建立多个VPN连接,以承载具有不同QoS要求的每一个内部流。在后一种情况下,如果每个VPN连接的IP 5元组都是不同的,那么可以使用MSCS管理每一个VPN连接的下行链路数据包的QoS处理。
在托管式企业级和运营商Wi-Fi网络中,常见的是,网络管理员将某些DSCP标记策略作为整个网络QoS管理的组成部分来配置。
对于由企业或运营商管理的服务器,下行链路流量可能在源端得到DSCP标记;或者,基于对源自公用互联网上第三方服务器的流量的分类规则,下行链路流量可能在进入网络时得到DSCP标记。在某些情况下,网络管理员还可以使用部署在托管式STA上的GPO(Group Policy Objects)或 MDM(Mobile Device Management)工具,在源端管理上行链路流量的DSCP标记。正如在上文有关MSCS介绍的那样,即使没有GPO或MDM策略,有些移动应用通过默认方式,也可将特定的DSCP标记用于QoS敏感型上行链路流。
在这些情况下,网络管理员通常希望管理AP和STA上的DSCP值与用户优先级之间的映射,从而即使在网络负载不断变化的情况下,也可以为具有优先DSCP标记的数据流提供差异化QoS。
经过Wi-Fi QoS Management认证的AP和STA必须支持IETF RFC 8325中定义的默认DSCP-to-UP映射表,还必须支持IEEE 802.11中定义的QoS Map功能,以指明对该默认映射而言的例外情况。这同时适用于下行链路及上行链路IP数据包。
在没有特定于厂商的分类器、虚拟局域网(VLAN)标记映射、MSCS规则等其他用户优先级分配策略适用的情况下,AP或STA通过采用以下方法检查数据包IP报头中的DSCP值来决定用户优先级:
有些传统实现方案仅通过使用DSCP值的3个最高有效位(也称为弃用的“首选项”值)作为用户优先级来执行映射。这导致将标记为DSCP快速转发(DSCP Expedited Forwarding)的语音流分配到用户优先级5(VI),而不是用户优先级6或7(VO)。其他传统实现方案使用较早版本的IEEE 802.11标准中的示例映射表。这导致将标记为DSCP CS42的视频流分配到用户优先级6(VO),而不是用户优先级4或5(VI)。
RFC 8325中定义的DSCP-to-UP映射表解决了传统映射表的不一致问题。默认情况下,使用RFC 8325映射表可确保Wi-Fi上的QoS处理与网络行业一致认同的QoS流量标记之间的一致性。
如果在支持Wi-Fi QoS Management的AP或STA上启用QoS Map功能,且配置了非默认DSCP-to-UP映射表,那么设备必须使用这个表而不是IETF RFC 8325 默认映射表,来进行自己的传送。非默认映射表可以用作网络管理的组成部分,以避免过多使用高优先级接入类别,和/或为网络上使用的、非标准本地DSCP值规定映射。
IETF RFC 8325 DSCP-to-UP映射:
采用Wi-Fi QoS Management的AP和STA在Extended Capabilities->QoS Map表示启用/禁用Qos Map。
网络管理员在AP上配置QoS Map表的方法未定义,但通常使用特定于厂商的管理接口来执行。
启用了Qos Map的AP会通过(Re)Association Response/QoS Map Configure帧将QoS Map element发给STA,STA将其作为DSCP-to-UP映射表而替代掉默认 DSCP-to-UP映射表。
指示特定DSCP的例外情况列表。每个DSCP Exception字段都有一个唯一的DSCP Value。
Non-AP STA将IP报头中的DSCP字段与DSCP Exception->DSCP Value相匹配,如果成功,则使用DSCP Exception->User Priority相应UP中的UP;如果没有找到匹配,则Non-AP STA尝试将DSCP与UP n DSCP Range字段匹配,如果成功,则使用n作为UP;否则将使用UP=0。
DSCP Exception List包含0~21个DSCP Exceptio字段。
其中DSCP Value取值范围为[0,63]&255;User Priority取值范围为[0,7]。
通过匹配IP层的DSCP和UP n DSCP Range的DSCP,匹配后分配对应UP n。8个UP都有一个DSCP Range。
其中DSCP Range value取值范围为[0,63]&255。
有以下值得注意的地方:
当使用QoS Map在STA上配置一个非默认DSCP-to-UP映射表时,在STA与其BSSID关联期间,该配置均适用。因此,如果网络使用QoS Map配置一个STA,且之后该STA漫游到网络中的另一个BSS,那么目标BSS中的AP必须使用QoS Map配置相同的映射表。该配置必须在漫游(重)关联期间完成或漫游(重)关联后立即完成,以便STA在漫游后继续执行一致的DSCP-to-UP映射。
QoS Map功能允许网络管理员管理对AP发送的下行链路IP数据包以及STA发送的具有给定DSCP标记的上行链路IP数据包进行的QoS处理。
尽管在需要时,网络管理员可以在网络基础设施之内配置IP流的DSCP(重新)标记,但是STA为每个上行链路IP流确定DSCP标记的方法是特定于厂商的。在使用移动STA的情况下,DSCP标记的确定通常可以由相应的应用和STA的操作系统来管理。
对于想要WIFI CFA QoS Management认证的AP&STA,需要完成如下认证测试。
{F36128,size=full}
要高效使用Wi-Fi所用非授权频谱,所有使用Wi-Fi QoS Management功能的实体都必须以合理和负责任的方式按优先顺序使用该频谱的机制。
网络IT经理应部署能够将恰当的用户优先级分配给相应流量的机制,以促使实现最高网络效率。由于最高优先级接入类别使用较小的争用窗口(CWmin、CWmax),因此当使用这些接入类别的流量增加时,冲突的可能性就提高了。在这种情况下,即使相互竞争的发送器数量很少,网络效率也可能显著下降。此外,由于在默认情况下,最高优先级接入类别与较短的TXOP长度相关联,因此当存在相互竞争的设备时,使用该类别可能大幅降低可实现的吞吐量,因为可得到的总传送时间减少了。
使用Wi-Fi的应用和服务的开发商可以按照IETF RFC 4594中定义的服务类别,通过在分配DSCP标记给IP流时运用行业最佳实践,帮助确保恰当、有效地使用这些机制。STA的操作系统可以帮助确保应用将恰当的接入类别用于上行链路流量,并在QoS敏感型服务处于活动状态时,与AP协商激活MSCS。这有助于确保将相同的接入类别用于相应的下行链路流量。
可通过AP的部署方式帮助确保为下行链路流量配置合适的网络策略,并监控高优先级接入类别的使用。然后,如果检测到对这些接入类别的过度使用,并对网络性能或介质访问公平性造成了不可接受的影响,那么AP就可以采取适当的措施,例如,修改网络策略、激活MSCS、使用QoS Map表等。
移动STA上的在线游戏应用与一个或多个服务器通信,以同步所有用户的游戏进程。游戏应用运用STA的操作系统提供的API设定用户优先级,带有这个用户优先级的上行链路IP流发送到AP和在线服务器。
例如, 应用可以为延迟敏感型数据流设定用户优先级6(VI),为实时视频流设定用户优先级5(VO),为非实时媒体资产流(例如当用户玩游戏时,在后台运行的游戏更新)设定用户优先级0(BE)。
STA上的应用基于设备的规则、按照优先顺序实现对上行链路IP流的QoS处理。这些规则可以是严格针对设备的,也可以应用业界通用最佳实践,例如RFC 4594。例如,延迟敏感型数据流可能与RFC 4594 Telephony 类的定义相匹配,该类别适用于以恒定速率发送的、大小固定的小型数据包的抖动敏感型流量。
在这个例子中,从互联网到达AP的所有相应下行链路IP流的DSCP标记都等于0,QoS行为是默认转发(Default Forwarding)。如果AP基于DSCP标记来分配每个数据流的“用户优先级 ”,那么所有数据流都将以BE类别发送。结果,尤其是当频道加载时,游戏元数据和实时视频会话对延迟、抖动及吞吐量的要求可能无法满足。不过,由于STA激活了MSCS,因此AP基于相应上行链路流的用户优先级来设定下行链路流的用户优先级。这些是由STA的应用而不是下行链路DSCP标记决定的。因此,用户的游戏体验始终很高。
Wi-Fi QoS Management计划使客户端游戏应用能够影响IP数据流的优先级,从而最大限度提高该应用的性能。结果,满足了游戏对低延迟、低抖动或无抖动以及高吞吐量的要求,为用户带来了始终如一的良好游戏体验。
企业部署了各种网络服务,包括面向关键任务型通信与协作的视频会议,以及面向员工培训的视频传送服务。在经常进行视频会议和远程培训的环境中,网络管理员的任务是确保这些应用提供高质量服务。为此,网络管理员通常会在网络上,且在可能的情况下,也会在托管的STA上,配置DSCP标记,以便分别将视频会议流的VO和VI标记为“确保转发(Assured Forwarding)”行为类的AF41和“快速转发”,同时将视频传送流标记为AF313。默认的DSCP-to-UP映射确保AP和STA以VO接入类别发送视频流,以VI接入类别发送语音流。
在繁忙的网络活动高峰时段,网络接近其最大容量,视频会议服务质量有降低风险。这时网络管理员可触发用QoS Map配置AP和STA的网络策略,将DSCP AF31视频传送流映射到用户优先级0(BE),而不是用户优先级4(VI)。这样一来,就能够以对该服务影响最小的方式降低视频传送服务的优先级,以便为关键任务型视频会议服务保留充足的网络容量和频道接入优先级。
为了在各种应用中提供良好的体验质量, WIFI联盟改进了WMM的Wi-Fi QoS Management技术,支持一系列服务类别,以区分这些应用的数据流并划分其优先级,从而改善了用户体验。
支持Wi-Fi QoS Management的设备需要支持MSCS和DSCP(DSCP-to-UP&QoS Map)。
MSCS使用户设备上的应用能够请求为流量分配所希望的优先级。这种双向QoS处理可确保设备上的应用有一致的、更低的延迟,而且即使Wi-Fi频道处于拥挤状态,也能提供良好的Wi-Fi体验。
DSCP映射允许网络管理员将来自接入点和客户端设备的流量映射到网络中特定的QoS优先级。在企业级网络中,网络管理员可以将视频会议流量设置为高优先级,并配置一个可更新的映射表,以确保满足关键任务型服务的需求。
[1] 《802.11-2020》
[2] 《QoS Management Specification Version 1.0》
[3] 《IETF RFC 8325》
[4] https://www.wi-fi.org/zh-hans/discover-wi-fi/wi-fi-qos-management