CCA更新流程分析

1 CCA

  CCA(空间信道评估)在CSMA/CA中比较非常重要,事关整机吞吐量,所以对其实现进行简单分析。CCA好像应该有2种:CCA-CS,是属于PLCP层的,捕获到能量且能量值高于-82dB后,确定空间忙;CCA-ED,属于协议层,捕获到-62dB信号后,需要判定空间忙,并等待。

  修改CCA等级,可以让它对“弱信号”失聪,从而可以在干扰环境中提高吞吐量。

2 具体实现

ar9300_update_cca_threshold(struct ath_hal *ah, int16_t nfarray[NUM_NF_READINGS], u_int8_t rxchainmask)

  nf=ah->nf_2GHz.max  OR ah->nf_5GHz.max        频段噪底

  nf_max_primary = nf_max_extension = nf;  主信道噪底=辅信道噪低=频段噪底

  chainmask = rxchainmask & ahpriv->ah_caps.hal_rx_chain_mask; 天线数

  for (chan = 0; chan < 2 /*ctl,ext*/; chan++) 基于nfarry[]获得最高nf,利用nf更新 nf_max_primary 和nf_max_extension

  nf_nominal = -101(HT20) OR  -98(HT40)  标称噪低(极限)

  if (nf_max_primary < nf_nominal)

  cca_detection_margin_pri = ahpriv->ah_config.ath_hal_cca_detection_margin + (nf_nominal - nf_max_primary);

  主信道cca检测余量值=配置检测余量+极限噪底-当前主信道噪底

  else

  cca_detection_margin_pri = ahpriv->ah_config.ath_hal_cca_detection_margin;

  主信道cca检测余量值=配置检测余量 (一般都是这里)

  if (nf_max_extension < nf_nominal)

  cca_detection_margin_ext = ahpriv->ah_config.ath_hal_cca_detection_margin + (nf_nominal - nf_max_extension);

  辅信道cca检测余量值=配置检测余量+极限噪底-当前辅信道噪底

  else

   cca_detection_margin_ext = ahpriv->ah_config.ath_hal_cca_detection_margin;

  辅信道cca检测余量值=配置检测余量  (一般都是这里)

  derived_max_cca = (ahpriv->ah_config.ath_hal_cca_detection_level - ahpriv->ah_config.ath_hal_cca_detection_margin - (-130);

  计算出的最大cca=配置的检测等级值 – 配置的检测余量 - (-130)

  max_cca_cap = derived_max_cca < 90 ? derived_max_cca : 90;

  最大cca门限=(计算出的最大cca值 与90之间的小者)

  cca_threshold_primary = (ahpriv->ah_config.ath_hal_cca_detection_level - cca_detection_margin_pri - nf_max_primary);

  主信道CCA门限=配置的CCA检测余量值-计算出的主信道检测余量值-当前主信道噪低

  cca_threshold_primary = cca_threshold_primary < max_cca_cap ? (cca_threshold_primary > 0 ? cca_threshold_primary : 0) : max_cca_cap;

  主信道CCA门限 =(主信道CCA门限 与最大cca门限间的小者)

  主信道CCA门限 =(主信道CCA门限 与0 间的大者)

  cca_threshold_extension = (ahpriv->ah_config.ath_hal_cca_detection_level - cca_detection_margin_ext - nf_max_extension);

  辅信道CCA门限=配置的CCA检测余量值-计算出的辅信道检测余量值-当前辅信道噪低

  cca_threshold_extension = cca_threshold_extension < max_cca_cap ? (cca_threshold_extension > 0 ? cca_threshold_extension : 0) : max_cca_cap;

  辅信道CCA门限 =(辅信道CCA门限 与最大cca门限间的小者)

  辅信道CCA门限 =(辅信道CCA门限 与0 间的大者)

  更新寄存器

   AR_PHY_CCA_0.AR_PHY_CCA_THRESH62= cca_threshold_primary

  主信道CCA值写入BB_cca_b0的0x0007F000位。这个寄存器应该是同时支持CCA_CS和CCA_ED的,这里所写入的也许就是CCA_ED,因为它命名为THRESH62;如果是CS,则为THRESH80才吻合;同样,该寄存器的0x1FF00000位好像不可改写,也不会随THRESH62值跳变,也许就是PLCP中的CCA_CS值,即真实的载波能量值。

  AR_PHY_EXTCHN_PWRTHR1.AR_PHY_EXT_CCA0_THRESH62=cca_threshold_extension

  辅信道CCA值写入BB_ext_chan_pwr_thr_1的0x000000FF位

  AR_PHY_EXT_CCA0.AR_PHY_EXT_CCA0_THRESH62_MODE=0x0

  BB_cca_ctrl_2_b0的0x00040000位置0。模式0/1的具体意思不明白,也许是自动和固定。

3 引申

  仅涉及到BB_cca_b0,BB_ext_chan_pwr_thr_1和BB_cca_ctrl_2_b0。因此,在需要强制提高CCA的场景下,仅需求关闭CCA自动调整功能(缺省模式),然后手工修改这3个寄存器即可。

  当然,开启CCA自动调整(CCAThEna ),也可以获得吞吐量提升,但要预设好适合当前场景的CCADetLevel值即可。  

时间: 2024-10-12 19:45:57

CCA更新流程分析的相关文章

WebGL 启动加载触发更新流程分析

太阳火神的美丽人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致"创作公用协议 转载请保留此句:太阳火神的美丽人生 -  本博客专注于 敏捷开发及移动和物联设备研究:iOS.Android.Html5.Arduino.pcDuino,否则,出自本博客的文章拒绝转载或再转载,谢谢合作. requestAnimFrame(tick); 此命令是 HTML5 中新增的用于替换定时器触发更新的命令,以实现动画更新,其后台实现有一特殊之处

WebGL 启动载入触发更新流程分析

太阳火神的漂亮人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致"创作公用协议 转载请保留此句:太阳火神的漂亮人生 -  本博客专注于 敏捷开发及移动和物联设备研究:iOS.Android.Html5.Arduino.pcDuino,否则.出自本博客的文章拒绝转载或再转载.谢谢合作. requestAnimFrame(tick); 此命令是 HTML5 中新增的用于替换定时器触发更新的命令,以实现动画更新,其后台实现有一特殊之处

nova挂载cinder卷流程分析

Nova挂载cinder卷流程分析 1. nova通过命令nova volume-attach server volume device-name或者http请求 Req:POST /v2/{tenant-id}/servers/{server-id}/os-volume_attachments' Body:{'volumeAttachment': {'device': '/dev/vdb', 'volumeId': '951be889-b794-4723-9ac9-efde61cacf3a'}

region split流程分析

region split流程分析 splitregion的发起主要通过client端调用regionserver.splitRegion或memstore.flsuh时检查并发起. Client通过rpc调用regionserver的splitRegion方法 client端通过HBaseAdmin.split传入regionname与splitpoint(切分的rowkey,能够不传入), 通过meta得到此region所在的server,发起rpc请求,调用HRegionServer.spl

Android 7.0 ActivityManagerService(8) 进程管理相关流程分析(2)

前一篇博客进程管理相关流程分析(1)里, 我们介绍了AMS中updateLruProcessLocked函数相关的流程. updateLruProcessLocked只是按照进程中运行的组件,粗略地定义了不同进程的优先级. 实际上,Android根据进程的oom_adj进行了更加细致的进程分类, 而AMS中的updateOomAdjLocked函数,就是用于更新进程的oom_adj值. 本篇博客中,我们来看看AMS中updateOomAdjLocked相关的流程. 一.ProcessList.j

Android -- Wifi连接流程分析

Android -- Wifi连接流程分析 当我们在Android手机上连接一个AP时,间接调用WifiManager的connect()方法: /** * Connect to a network with the given configuration. The network also * gets added to the supplicant configuration. * * For a new network, this function is used instead of a

Android 4.4 Kitkat Phone工作流程浅析(六)__InCallActivity显示更新流程

本文来自http://blog.csdn.net/yihongyuelan 转载请务必注明出处 本文代码以MTK平台Android 4.4为分析对象,与Google原生AOSP有些许差异,请读者知悉. 前置文章: <Android 4.4 Kitkat Phone工作流程浅析(一)__概要和学习计划> <Android 4.4 Kitkat Phone工作流程浅析(二)__UI结构分析> <Android 4.4 Kitkat Phone工作流程浅析(三)__MO(去电)流程

Android -- Audio Native服务之启动流程分析(一)

Android -- Audio Native服务之启动流程分析(一) Android中的Audio系统是比较庞大.繁杂的一部分内容, 其中会涉及较多的音频编解码.多媒体制式与Android Audio HAL设备管理的知识.随着Android的发展,其所支持的音频设备也变得越来丰富,如扬声器.耳机.听筒等等:这种变化也为Android管理如此丰富的音频设备以及如何正确.合理地切换音频输出提出了更高的要求.面对如此繁杂的管理要求,我们分析Android Audio服务的历程想必也不会轻松.接下来

Android7.0 Phone应用源码分析(三) phone拒接流程分析

接上篇博文:Android7.0 Phone应用源码分析(二) phone来电流程分析 今天我们再来分析下Android7.0 的phone的拒接流程 下面先来看一下拒接电话流程时序图 步骤1:滑动按钮到拒接图标,会调用到AnswerFragment的onDecline方法 com.android.incallui.AnswerFragment public void onDecline(Context context) { getPresenter().onDecline(context);