80211 发送速率选择算法分析

转:https://blog.csdn.net/junglefly/article/details/48974077

1. 介绍
《802.11无线网络权威指南  第二版》中对于选速和降速的描述:

市面上所有802.11接口均支持某种降速机制,可以根据不同网络环境调整所使用的数据传输速率。速率选择主要决定一张网卡该在何时提高速率以提高链路品质。802.11标准并未规范工作站如何决定降速(或者升速),因此速率选择如何实现就留给芯片组厂商自行决定。几乎所有芯片组具有自己的一套选速机制,因此大多数802.11接口的操作方式均有所不同。速率选择是可编程的,一般由驱动程序控制。

最常被用来判断何时应该变速的算法,其实是通过一些不是那么严格的信号质量测量。信号质量可以直接就信噪比加以测量,或者间接观察有多少帧需要重传。直接测量信噪比可以针对最近一个帧的瞬间信号质量,或者就最近一段时间所接收到的一定数量的帧取平均数。有些芯片会直接测量信噪比,不过随后会将之转换为相应的“信号质量signal quality”。当信号质量变差,芯片就会以降速来应变。

至于间接测量,则是监测瞬间或者平均遗失多少帧,然后予以适当补偿。采用间接测量的算法简单来说就是:如果帧已经遗失且帧重试计数器已经用尽,那就降速到下一档,然后重试一遍。反复进行以上步骤直到帧送出,或者一直尝试到以最低速率都无法成功传送为止。采用间接信号质量测量的芯片组或许会稍微修改上述算法,以避免耗费过多时间在物理层所支持的所有速度间逐次降速。尤其是近来的芯片组均支持不少的速率,在较低速率上反复重试将会相当费时。

1.1 发送速率的选择

代码中的数据结构如下所示:

/* MIMO Tx parameter, ShortGI, MCS, STBC, etc.  these are fields in TXWI. Don‘t change this definition!!! */

typedef union _HTTRANSMIT_SETTING {

#ifdef RT_BIG_ENDIAN

struct {

USHORT MODE:2;   /* Use definition MODE_xxx. */

USHORT iTxBF:1;

USHORT rsv:1;

USHORT eTxBF:1;

USHORT STBC:2;      /* SPACE */

USHORT ShortGI:1;

USHORT BW:1;         /* channel bandwidth 20MHz or 40 MHz */

USHORT MCS:7;       /* MCS */

} field;

#else

struct {

USHORT MCS:7;       /* MCS */

USHORT BW:1;         /* channel bandwidth 20MHz or 40 MHz */

USHORT ShortGI:1;

USHORT STBC:2;      /* SPACE */

USHORT eTxBF:1;

USHORT rsv:1;

USHORT iTxBF:1;

USHORT MODE:2;   /* Use definition MODE_xxx. */

} field;

#endif

USHORT word;

} HTTRANSMIT_SETTING, *PHTTRANSMIT_SETTING;

由上面的代码可知:

*  Ralink是通过APHardTransmit函数来发送所有的帧的。而驱动在发送数据时的速率是直接用节点的成员变量PMacEntry->HTPhyMode;

*  在发送一个报文时,它找到对应的节点,就可以取出当前的速率。

*  至于PMacEntry->HTPhyMode,driver中是通过APMlmeDynamicTxRateSwitching函数(call this routine every second ,walk through MAC table, see if need to change AP‘s TX rate towardeach entry)来实现对每个节点的速率的周期性维护。

2. 算法分析
2.1 算法的流程
在算法中会使用到如下的速率表,算法中会使用该表中的TrainUp以及TrainDown来决定是降速还是升速。

如下是传输速率表的一个例子:

UCHAR RateSwitchTable[] = {

/* Item No.   Mode   Curr-MCS   TrainUp   TrainDown

Mode- Bit0: STBC, Bit1: Short GI, Bit4,5: Mode(0:CCK, 1:OFDM, 2:HT Mix, 3:HT GF)*/

0x11, 0x00,  0,  0,  0,                   /* Initial used item after association;连接后刚开始使用这个速率表项*/

0x00, 0x00,  0, 40, 101,

0x01, 0x00,  1, 40, 50,

0x02, 0x00,  2, 35, 45,

0x03, 0x00,  3, 20, 45,

0x04, 0x21,  0, 30, 50,

0x05, 0x21,  1, 20, 50,

0x06, 0x21,  2, 20, 50,

0x07, 0x21,  3, 15, 50,

0x08, 0x21,  4, 15, 30,

0x09, 0x21,  5, 10, 25,

0x0a, 0x21,  6,  8, 25,

0x0b, 0x21,  7,  8, 25,

0x0c, 0x20, 12,  15, 30,

0x0d, 0x20, 13,  8, 20,

0x0e, 0x20, 14,  8, 20,

0x0f, 0x20, 15,  8, 25,

0x10, 0x22, 15,  8, 25,

0x11, 0x00,  0,  0,  0,

0x12, 0x00,  0,  0,  0,

0x13, 0x00,  0,  0,  0,

0x14, 0x00,  0,  0,  0,

0x15, 0x00,  0,  0,  0,

0x16, 0x00,  0,  0,  0,

0x17, 0x00,  0,  0,  0,

0x18, 0x00,  0,  0,  0,

0x19, 0x00,  0,  0,  0,

0x1a, 0x00,  0,  0,  0,

0x1b, 0x00,  0,  0,  0,

0x1c, 0x00,  0,  0,  0,

0x1d, 0x00,  0,  0,  0,

0x1e, 0x00,  0,  0,  0,

0x1f, 0x00,  0,  0,  0,

};

表项对应的数据结构为:

typedef struct _RTMP_TX_RATE_SWITCH

{

UCHAR   ItemNo;

#ifdef RT_BIG_ENDIAN

UCHAR     Rsv2:2;

UCHAR     Mode:2;

UCHAR     Rsv1:1;

UCHAR     BW:1;

UCHAR     ShortGI:1;

UCHAR     STBC:1;

#else

UCHAR     STBC:1;

UCHAR     ShortGI:1;

UCHAR     BW:1;

UCHAR     Rsv1:1;

UCHAR     Mode:2;

UCHAR     Rsv2:2;

#endif

UCHAR   CurrMCS;

UCHAR   TrainUp;

UCHAR   TrainDown;

} RTMP_TX_RATE_SWITCH, *PRTMP_TX_RATE_SWITCH;

上面的接口中我们重点关注TrainUp和TrainDown。

如果发包错误率(PER: Packet Error Rate)大于等于TrainDown,并且一秒钟内发包数量大于一定数值,Driver就会选择降速;

如果发包错误率小于等于TrainUp, 并且一秒钟内发包数量大于一定数值,Driver就会选择升速;

算法流程参见下图:

2.2算法的分析
*  如果上一秒统计的总的发送报文数<=15,那么仅根据Rssi来选择发送的速率,原则是选择出满足RSSI条件的最大的发送速率;

*  如果发送报文个数>15个,根据发包错误率来决定未来的传输速度。

#  如果发包错误率(PER: Packet Error Rate)大于等于TrainDown,Driver就会选择降速;

#  如果发包错误率小于等于TrainUp,Driver就会选择升速;

---------------------
作者:飞越丛林
来源:CSDN
原文:https://blog.csdn.net/junglefly/article/details/48974077
版权声明:本文为博主原创文章,转载请附上博文链接!

原文地址:https://www.cnblogs.com/newjiang/p/10804495.html

时间: 2024-10-06 07:01:03

80211 发送速率选择算法分析的相关文章

UDT协议实现分析——发送窗口大小及发送速率的调整

UDT主要通过在数据收发的过程中进行精细的控制来实现对于网络带宽更加有效的利用,并使网络中数据传输的速率尽可能快. 如我们前面在分析数据发送的控制中看到的,对于正常的顺序packet发送,发送控制主要在于两个方面,一是发送窗口的大小,也就是某个时刻已经发送但未得到相应的packet的最大个数,这一点主要由拥塞窗口大小m_dCongestionWindow和滑动窗口大小m_iFlowWindowSize来描述,发送窗口大小为两者中较小的那一个:二是控制两个数据包发送的时间间隔,也就是包的发送速率,

第一章:1-20、试计算以下两种情况的发送时延和传播时延: (1) 数据长度为107bit,数据发送速率为100kbit/s,传播距离为1000km,信号在媒体上 的传播速率为2&#215;108m/s。 (2) 数据长度为103bit,数据发送速率为1Gbit/s,传输距离和信号在媒体上的传播速率同 上。

<计算机网络>谢希仁著第四版课后习题答案答: 1):发送延迟=107/(100×1000)=100s         传播延迟=1000×1000/(2×108)=5×10-3s=5ms 2):发送延迟=103/(109)=10-6s=1us         传播延迟=1000×1000/(2×108)=5×10-3s=5ms

GPS控制指令-串口发送控制指令选择输出格式

我用的模块是Ublox的从设置软件上可以看到每一种设置的十六进制的命令格式: 具体可以上网查,网上有相关文章. 设置波特率为19200: B5 62 06 00 14 00 01 00 00 00 D0 08 00 00 00 4B 00 00 07 00 03 00 00 00 00 00 48 57 设置输出频率为10HZ: B5 62 06 08 06 00 64 00 01 00 01 00 7A 12 注意以上是十六进制,具体发送时要用加0x,如:0xB5 其他输出格式设置: unsi

【Atheros】minstrel速率调整算法源码走读

先说几个辅助的宏,因为内核不支持浮点运算,当然还有实现需要,minstrel对很多浮点值做了缩放: /* scaled fraction values */ #define MINSTREL_SCALE 16 #define MINSTREL_FRAC(val, div) (((val) << MINSTREL_SCALE) / div) #define MINSTREL_TRUNC(val) ((val) >> MINSTREL_SCALE) MINSTREL_SCALE是一个放

【Atheros】Ath9k速率调整算法源码走读

上一篇文章介绍了驱动中minstrel_ht速率调整算法,atheros中提供了可选的的两种速率调整算法,分别是ath9k和minstrel,这两个算法分别位于: drivers\net\wireless\ath\ath9k\rc.c···················Ath9k net\mac80211\minstrel_ht.c···························Minstrel 无论从理论分析还是实验结果上看,minstrel都要胜ath9k一筹,为了一个完整性,这里也

关于算法--蛮力法篇--选择排序

近日开始学习算法,所看课本为清华大学出版社的<算法设计与分析基础>,对简单的数据结构进行了复习,已经学习了算法效率分析基础. 本篇开始对所学算法的思想进行实际JS编码,看学习的进度,每日写一篇学到的算法,以上为背景. 蛮力法是一种直接解决问题的方法,常常基于问题的描述和所涉及的概念定义:所谓的“力”,指的是计算机的计算能力. 优点是①可解决广阔的领域各种问题:②可以产生一些合理的算法:③实例不多时,可用一种能接受的速度求解:④可解决一些小规模问题实例:⑤可作为研究或教学目的,作为其他算法的准绳

【转载】WebRTC基于GCC的拥塞控制(上) - 算法分析

实时流媒体应用的最大特点是实时性,而延迟是实时性的最大敌人.从媒体收发端来讲,媒体数据的处理速度是造成延迟的重要原因:而从传输角度来讲,网络拥塞则是造成延迟的最主要原因.网络拥塞可能造成数据包丢失,也可能造成数据传输时间变长,延迟增大. 拥塞控制是实时流媒体应用质量保证(QoS)的重要手段之一,它在缓解网络拥堵.减小网络延迟.平滑数据传输等质量保证方面发挥重要作用.WebRTC通控制发送端数据发送码率来达到控制网络拥塞的目的,其采用谷歌提出的拥塞控制算法(Google Congestion Co

UDT协议实现分析——数据发送控制

在前文中,我们有看到,数据发送的过程,大体是发送者CUDT将要发送的数据放进它的CSndBuffer m_pSndBuffer,并将它自己添加进它的CSndQueue m_pSndQueue的CSndUList m_pSndUList的堆里,后面CSndQueue m_pSndQueue的worker线程会通过CSndUList::pop()从CSndUList m_pSndUList的堆顶CUDT中获取一个要发送的包来发送,包的获取主要是通过CUDT::packData()来完成,而这个函数正

Kafka消息的可靠性测试--针对直播业务的方案选择

转自:http://blog.csdn.net/bailove/article/details/44240303 业务场景 来疯直播互动平台,每天有数百万人上下线,有数十万人同时参与互动直播聊天.用户的登陆.退出及用户间的各种交互行为如聊天.送礼.关注.投票.抢沙发等等事件都会产生大量的消息.这些消息具有瞬间爆发性,比如热门直播间刚开播,直播表演的高潮等等.而用户的礼物.星星.喇叭.沙发等这类消息是不允许丢失,必须100%送达.这就需要有一个高性能,高可靠,稳定可拓展的消息服务平台的支撑.它要求