所有文章
WiFi6的Bss Coloring特性详解
在802.11ax也就是WiFi6中引入了一种BSS Coloring特性，这种特性用于优化和解决在高密度环境中多个基本服务集（BSS）之间的无线干扰问题。 在传统的Wi-Fi网络中，如果两个相邻的BSS网络使用相同的信道，它们之间在通信的过程中所发送的信号会相互干扰，导致两个网络的通信性能均明显下降。因为，一旦发生同信道的无限冲突，对于每一个通信节点，都需要增加重传尝试来把数据包放到通信的对端，这样才能避免潜在的数据丢失，无线冲突和重传太多，严重劣化了网络的通信性能。而WiFi6中所推出的BSS Coloring机制可以减少这种不必要的干扰，提高了网络性能和信道利用率。 要理解BSS Coloring的工作原理，首先需要理解WiFi通信节点在信道监听中所采用的CCA（Clear Channel Assessment，信道空闲评估）机制的工作流程。 CCA信道空闲评估流程 在wifi通信中，每个通信节点在发出数据之前，都首先要监听当前的信道是否是空闲的（即同一信道下是否有另外一个节点正在发送数据）。每个通信节点只有在确认当前信道空闲的情况下，才能向外发送数据，这就是物理载波监听的机制。而对于每个通信节点而言，如何评估当前的通信信道是空闲的，就是CCA机制，即信道空闲评估。 在CCA机制的具体实现上（此处只关注物理层载波监听，不关心虚拟载波监听NAV），其核心机制可分为 能量检测（Energy Detection, ED） 和 载波侦听（Carrier Sense, CS） 两个方面。 载波侦听（CS） 物理层载波侦听的核心运行逻辑为：只要物理层能够有效的检测和解调出来Wi-Fi前导码（如802.11协议定义的OFDM符号或DSSS头），那么无论当前信号能量是否超过阈值，均判定当前的通信信道为繁忙。 具体的实现细节是，CS通过解码前导码中的 SFD（Start Frame Delimiter）字段或 PLCP头（Physical Layer Convergence Protocol）来识别合法的Wi-Fi信号，因此这一机制主要用于区分当前信道中所存在的无线信号是Wi-Fi信号还是其他的非协议干扰（如蓝牙、微波炉等）信号。如果是WiFi信号的话（也就是说能够检测到WiFi前导码），当然就判定当前信道是繁忙的；而如果无法解出正确的WiFi前导码的话，就依赖于下一步的能量检测ED阶段来判断信道是否繁忙。 简单总结：CS只要检测到当前信道中有WiFi信号，就认为当前信道繁忙。 能量检测（ED） 物理层能量检测的核心运行逻辑则是，当信道单位时间内积分上的总能量超过ED阈值时，无论信号是否为Wi-Fi协议帧，均判定信道为繁忙。ED检测的主要应用场景是判断信道是否被其他设备（无论是否遵循Wi-Fi协议）占用，当信道上的总能量（包括Wi-Fi信号、非Wi-Fi干扰、噪声等）超过ED阈值时，设备判定信道为繁忙，从而推迟发送数据。 - 不同协议标准阈值不同（如802.11b为-76 dBm，802.11a/g/n/ac更高） 简单总结，当ED检测到当前信道单位时间内的积分能量超过指定的阈值，无论这些信号是否是WiFi信号，都认为当前信道繁忙。 在实际的工作过程中，一般是CS和ED这两个检测之中，只要有一个判断结果是信道繁忙，系统就会认为当前信道为占用状态，推迟发送数据。 BSS Coloring的工作原理 在WiFi6（802.11ax）所引入的BSS Coloring工作机制中，每个AP（接入点）被分配了一个6bit的BSS颜色标识（因此其取值范围0~63），该标识嵌入在PHY层的HE-SIG-A1字段中（位于PPDU帧头），因此每个WiFi6节点所发出数据包的包头都包含有这个6bit的Coloring ID，每个BSS的Coloring ID都不同（理论上，如果检测到Coloring ID冲突可动态调整）。因此对于每个WiFi6节点而言，都可以通过载波侦听（即前面所说的SD环节）监听当前信道WiFi信号的包头前导码来判断这个数据包是自己BSS（MYBSS）的数据包还是使用相同信道的其他BSS（OSS）的数据包。 - AP会在自己的Beacon Frame中广播自己的Coloring ID，这样的话，每个BSS内的STA都可以很清楚的知道自己BSS的Coloring ID是多少。 !image.png 除了以上在包头信息中增加Coloring ID以外，BSS Coloring机制还在CCA的流程中引入了一个差异化及动态调整能量检测阈值的机制。所谓的差异化信道检测门限是指： - MYBSS：如果接收到信号的BSS Coloring ID与自己的AP一致（也就是同一个BSS内部的STA发出的信号），采用一个较低的ED检测阈值（CCA-SD，Signal Detect）来判断信道是否繁忙。例如，当信号功率超过CCA-SD（如-82 dBm）时判定信道繁忙。CCA-CD这个阈值的设置比较低，确保对同BSS信号的敏感检测，避免在相同BSS的其他STA正在传输信号的时候发出数据。 - OBSS：如果接收到WiFi包头前导码序列中的Coloring ID不一致，表示这个数据包来自于其他的BSS。此时在CCA的能量检测环节采用更高的门限值（CCA-ED，Energy Detect）来判断信道是否繁忙。例如，当信号功率超过CCA-ED（如-62 dBm）时才判定信道繁忙。在这种情况下ED检测阈值较高，就允许设备忽略弱干扰信号（如相邻AP的同频信号），减少不必要的退避等待，可有效提升信道的利用效率。 此外，CCA-ED门限还可根据网络负载动态调整。例如当检测到来自OBSS的干扰较强时，可适当提高CCA-ED门限，这样就可以进一步容忍干扰并提升空间复用率。 在下图中，左侧的WiFi4对于所有的BSS，都采用相同的CCA-SD和CCA-ED阈值，这样在有OBSS存在的情况下，很容易就会被判断为当前信道繁忙，不得不等待退避一段时间后再发送数据；而右侧的WiFi6针对MYBSS和OBSS对CCA的判断阈值进行了区分并且可以动态调整，这样的话如果检测到当前是OBSS的节点正在发送数据的话，可以采用更高的CCA-ED判断阈值，只要来自OBSS的信号强度不至于影响当前BSS的信号解调，两个BSS的无线信号就可以同时发送，这样就可以有效的提升频谱的空间利用率。 !image.png BSS Coloring机制理解的相关问题 增加BSS Coloring ID可以解决通信的无线冲突吗？ 当然不可以。在wifi6包头增加的BSS Coloring ID只是用于分辨这个包是否来自自己所在BSS的设备，根据这个ID可以判断出来当前无线环境正在发送的包是否是自己所在BSS的包，然后再根据这个信息来决定CCA信道繁忙状态判断的阈值。包头上增加BSS Coloring ID本身并不能解决冲突问题。 所以，如果两个wifi节点在相同的信道上同时间发出数据，而且对于接收节点而言干扰功率足够大的话，肯定还是会影响接收信号的正确解调。但是，如果两者的距离比较远，两个不同BSS的数据包被认为是弱信号，那就不会影响各自的正确解调，从而可以有效的提升频谱的空间利用效率。 在WiFi6和WiFi4的混合环境中是否还可以支持BSS Coloring？ 在WiFi4和WiFi6的混合环境中，BSS Coloring特性仍然是可以工作的。在这种情况下，Wi-Fi 6设备能够按照其标准流程识别和处理BSS Color字段，而Wi-Fi 4设备由于不支持这一特性，它们不会识别这个字段。但是这并不妨碍Wi-Fi 6设备利用BSS Coloring来减少与其他Wi-Fi 6网络的干扰。因此在实际工作中，Wi-Fi 6设备会忽略来自Wi-Fi 4设备的信号，这样Wi-Fi 6设备就可以更有效地利用信道，而Wi-Fi 4设备则继续按照它们原有的方式工作，不会受到BSS Coloring的影响。 总结 BSS Coloring的具体实现，就是： - 在WiFi6节点所发出的数据包的包头上额外增加一个BSS Coloring ID标识，理论上每个无线环境中的BSS ID表示都是不同的，那么在同一个无线环境中，通过接收和解调出来的包头信息，就可以判断当前正在传送的这个包是哪个BSS的包。 - 基于以上的BSS Coloring ID标识，判断当前收到的数据包来自于相同的MYBSS，还是不同的OBSS。针对MYBSS设置较低的冲突检测阈值CCA-SD，也就是只要检测到相同BSS的数据包正在发送，就要退避等待发送机会；而对于OBSS设置较高的冲突检测阈值CCA-ED，也就是即使检测到有另外一个同信道BSS的数据包正在发送，只要其能量不是很大（使用CCA-ED进行过滤），就认为当前信道可以正常发送数据，这样就可以提升频谱的空间利用率。 因此，按照以上工作流程，通过在WiFi6的包头序列码中增加BSS Coloring ID标识以及针对MYBSS和OBSS设置不同的冲突能量检测阈值并可支持进行动态调整阈值的方式，BSS Coloring确实是可以从一定程度上优化同频段干扰并提升整个频谱使用的空间利用率。 但需要注意的是，BSS Coloring机制并不能从根本上解决同信道无线通信中存在的冲突问题（这个问题实际上是无解的），只不过它通过对BSS的区分，使得不同BSS的数据包在相互之间干扰功率不是很大的情况下可以同时发送，以提升整个网络的通信效率。 参考资料 - 802.11协议精读22：CCA (Clear Channel Assessment) - 知乎 - Wi-Fi 6(802.11ax)解析7：BSS Coloring技术 - 知乎
WiFi6的OFDMA特性详解
OFDMA：全称是Orthogonal Frequency Division Multiple Access，即正交频分多址。 OFDM vs OFDMA 在WiFi6之前的WiFi4/WiFi5，甚至更早的802.11a协议中，已经导入了OFDM机制，即把整个通信信道的频宽划分为多个相互重叠但是正交的子载波，以尽可能提升数据传输速率以及频谱利用率，并且克服无线传输中存在的多径干扰问题。 但是单独OFDM的使用，WiFi AP和STA之间的每次通信都是针对单用户的，也就是说每次发送数据的时候，不管这个用户数据量的大小，与这个用户的通信每次都要占用全部的子载波进行通信。如果把整个信道全部的子载波整体看成一辆送货的小车，当用户要通信的数据量很小的时候，例如即时消息，浏览网页等，这些通信的数据量根本用不了全部的子载波，因此这个小车是装不满的，但根据OFDM的工作机制和流程，这个装不满的小车里面也只能装这个用户的数据，小车里多余的空间（即剩下闲置的子载波）就被白白浪费了。 !image.png 在WiFi6中引入的OFDMA机制则可以有效的改善以上情况。在WiFi6协议中，把整个信道带宽所包含的所有子载波划分为多个相互独立的资源单元RU（Resource Unit），在发送数据的时候，经过AP的统一协商和管理，不同用户的数据只会占用其中的某个RU而不是整个信道，这样的情况下，因为整个信道包含多个RU，那么就可以实现在同一时间使用不同的RU向多个用户同时发送数据的应用场景。如果仍然拿小车来举例的话，OFDMA相当于是在小车中划出专门的隔间，通过调度确定下来每个隔间用户放置不同用户的货物，这样小车跑一次就可以同时为多个接收方送货，当然是大大提升了运输效率（通信效率）。 !image.png 以下是传统的OFDM与OFDMA之间的对比： !image.png RU（Resource Unit）的概念 如上所述，在WiFi6的OFDMA机制的运行过程中，RU是OFDMA的最小资源分配单位。RU由一组连续的子载波（Tone）组成。在WiFi6的OFDMA机制中，RU最小可包含26-tone（也就是26个子载波），其他类型的RU还包括52-tone、106-tone、242-tone等。RU中tone的数量与其所占频宽的对应关系是：（WiFi6的子载波间隔是78.125KHz，很好计算） - 26-tone RU ≈ 2 MHz - 52-tone RU ≈ 4 MHz - 106-tone RU ≈ 8 MHz - 242-tone RU ≈ 20 MHz（对于20MHz频宽而言，相当于是覆盖整个信道） 以2.4GHz频段20MHz频宽为例： - WiFi6导入了更小的子载波间隔（78.125kHz），相比Wi-Fi4/5（312.5kHz）缩小了4倍。因此WiFi6在相同带宽下，可用的子载波数量大幅增加。 - 对于20MHz的信道频宽而言，整个信道的20MHz会被分割为256个子载波，其中234个用于数据传输，其余为保护子载波（11个）、空子载波（4个）和直流子载波（7个）。 - 在20MHz的信道中，最多可支持9个26-tone RU，即同时服务9个用户。 !image.png 在具体的执行中，完整的20 MHz信道可以被灵活的动态分配为不同的RU组合，例如可以分为1个106-tone RU + 5个26-tone RU来同时支持6个用户；也可以分为4个52-tone RU同时支持4个用户。另外，AP在运行的过程中，还会周期性的探测当前连接的多个终端设备的数据流量类型（如视频、语音）和缓冲区状态等，在各个设备之间动态分配RU，进一步优化带宽利用效率。 > 但是需要注意，WiFi6的OFDMA对于RU的划分，只能够支持在同一时间周期内给一个STA分配一个RU，因此无论AP如何灵活的给其连接的STA分配RU资源，每个STA都只能使用其中的一个RU。 触发帧(Trigger Frame)结构 如上所述，在WiFi6 OFDMA机制的运行过程中，AP可以根据其连接的各个节点的通信需求在多节点之间动态的分配RU，那么这个动态分配RU的执行流程是什么呢？答案是： - AP要依赖于触发帧（Trigger Frame）和管理帧交互机制来动态通知各个终端（STA）RU的分配结果。 - 而对于AP与STA之间的下行通信，如果不依赖于MU-RTS机制的话，各个STA的下行通信RU信息就直接包含在AP发出数据PPDU的HE-SIG-B字段中，这样对于下行OFDMA通信而言，就不需要依赖触发帧来分配RU资源了。但上行OFDMA通信（即多个STA利用各自的RU同时向AP发出数据）必须要依赖于触发帧进行RU的协商和同步。 触发帧是在802.11ax规范中引入的一种控制帧结构（Type=1，SubType=2）。有关触发帧的详细信息可以参考[[WiFi6的触发帧（Trigger Frame）帧结构详解]]。 上行和下行OFDMA的运行流程 WiFi6的OFDMA在具体的应用上可以分为上行OFDMA和下行OFDMA两种应用场景和流程： - 下行OFDMA(Downlink OFDMA)，是指AP可以同时使用多个RU向多个不同的STA传输数据，因此可以提高单位时间内的有效数据吞吐率，提升频谱的利用效率。 - 上行OFDMA(Uplink OFDMA)，是指多个STA可以通过利用自己分配的RU向AP传输数据，因此各个STA之间不再需要通过传统的竞争信道的方式来竞争无线传输媒介，减少了STA上传数据由于信道竞争而产生的时延和冲突次数。 以下总结下行OFDMA的通信流程：（AP同时向多个STA发送数据） - AP发出一个MU-RTS Frame类型的触发帧。相比于传统的RTS(Request To Send) Frame，这个MU-RTS Frame中包含了多个目的STA的Association ID以及各个STA在本次会话通信中使用的RU等信息。在这个AP的BSS中，所有的STA都可以接收并解析这个MU-RTS Frame，从而了解到本次会话中AP是否有数据发送给自己，自己是否需要给AP发回CTS应答以及自己的数据在哪个RU。 - STA（MU-RTS中指定的那些STA）发回CTS Frame，确认信道可用于接收数据。因为在MU-RTS中指定了本次会话通信中各个STA的Association ID以及其占用的RU，所以这些STA收到MU_RTS Frame以后，就通过给自己分配的RU向AP发回CTS Frame进行应答。因此，多个STA占用的RU相互独立，可以同时向AP发回这个应答。 - AP同时向多个STA发出数据。这个阶段就是AP使用不同的RU向多个STA同时发出数据，各个STA也只需要接收自己的RU中所传输的数据。 - AP轮流向每个STA发出BAR(Block ACK Request)帧。数据发送完成后等待SIFS的时间，AP轮流向每个接收数据的STA发出一个BAR Frame用于请求各个其数据接收应答帧，以确认数据是否被正确接收。（此处为什么不采用MU-BAR帧，主要是考虑兼容性方面的问题，确保不支持OFDMA和触发帧的其他STA也能够正常收到BAR帧并答复。） - 多个STA同时使用自己的RU向AP回复Block ACK帧。对于本次OFDMA下行通信过程中每个接收数据的STA，使用上行OFDMA机制在自己的RU中同时向AP返回Block ACK Frame，表示前面的数据已经被正常接收并解析。 !image.png 当然以上的MU-RTS和CTS环节是可选的流程，推荐在高密度部署或者敏感数据传输的应用场合中使用。在一般优化吞吐量的应用场景中，可跳过MU-RTS和CTS环节以降低控制开销，在这种情况下，本次下行传输中对各个STA的RU分配信息包含在下行数据PPDU前导码中，前导码中所包含的HE-SIG-A和HE-SIG-B字段描述了RU的分配信息，STA接收到前导码以后对其中的HE-SIG-B字段进行解析来判断自己数据所在的RU。 对于上行OFDMA流程而言，相比下行通信要稍微复杂一点。在上行的流程中，AP需要先轮询各个STA的数据缓冲状态（是否有上行通信的需求），然后再根据各个STA的信息来分配RU资源。因此，在上行流程中，AP先发送BSRP触发帧，STA回复BSR（缓冲状态报告），然后AP再根据这些信息发送基本触发帧来调度资源。 以下总结上行OFDMA的通信流程：（多个STA同时向AP发送数据） - 首先由AP发起下行OFDMA通信流程，AP向所有的STA发出BSRP(Buffer Status Report Poll)触发帧，通过这个触发帧来查询各个STA是否有数据要发送给自己。 - 每个STA通过自己分配的RU，向AP返回一个Qos Null Frame，其中包含有BSR信息(Buffer Status Report) ，告知AP自己是否有数据要发送。 - AP再向所有的STA发出MU-RTS Frame，用于确认各个STA是否已经准备好上传数据，以及各个STA的RU分配信息。 - 多个STA通过自己的RU同时向AP应答一个CTS Frame，表示自己已经准备好发送数据。 - AP再向所有的STA发出一个基本触发帧，通过这个基本触发帧来触发多个STA向其上传数据。各个STA收到这个基本触发帧以后，同时通过自己的RU向AP发出自己的数据。 - 最后AP再向所有的STA发出应答包Multi-STA Block ACK，表示自己已经成功的接收并解析上行数据。 !image.png 同样的道理，以上的上行OFDMA流程中的MU-RTS和CTS部分也是可选的。 参考资料 - Wi-Fi 6(802.11ax)解析2：OFDMA资源块 - RU - 知乎 - Wi-Fi技术简介（九）-- WIFI6高性能之OFDMA - 【WLAN从入门到精通-Wi-Fi 6】第2期——物善其用 OFDMA-云社区-华为云 - Wi-Fi 6(802.11ax)解析13-15：触发帧（Trigger Frames）和MAC接入机制、下行OFDMA接入机制（DL-OFDMA）、上行OFDMA接入机制（UL-OFDMA）_dl ofdma 80211-CSDN博客 - Wi-Fi6协议Triggle Frame在OFDMA中应用_wifi 6 ofdma-CSDN博客
WiFi6的触发帧（Trigger Frame）帧结构详解
WiFi6（802.11ax）中OFDMA（正交频分多址接入）的实现依赖于触发帧（Trigger Frame, TF） 这一关键机制。本文从技术角度深入剖析其触发帧的详细细节。 触发帧整体结构 整体而言，触发帧是802.11ax所引入的一种控制帧类型（Type：Control，Subtype：2）。下图是802.11ax规范中定义的Trigger Frame的整体帧结构。 !image.png 从以上触发帧的整体帧结构上可以看到，Trigger Frame的整体帧结构可以分为四个部分： - MAC Header：包含Frame Control，Duration，RA，TA四个部分。其中触发帧的帧类型在Frame Control中指定。 - Common Info：紧随MAC Header之后的是一个Common Info部分，在其中定义了这个帧的全局参数配置信息。 - 连续多个User Info结构：每个User Info结构针对一个用户（也就是STA）的独立配置字段信息，在其中指定给这个STA分配的RU资源。 - Padding和FCS：最后是整个包结构的占位字段和校验字段。 对于触发帧而言，又可以按照Common Info中的Trigger Type指定，分为多种不同的子帧类型。 !image.png - Basic：用于常规上行OFDMA MU-MIMO传输，AP通过RU分配指定各STA的时频资源，启动各个STA向其上传数据。 - BSRP：在UL OFDMA通信中，AP使用BSRP帧请求STA上报缓冲区状态（有多少数据等待上传），以便于AP动态分配资源。 - MU-RTS：类似于RTS帧，但用于OFDMA通信中，用于协调多用户同时发送RTS帧，以减少信道竞争冲突。 - MU-BAR：用于上行OFDMA通信中，AP向所有的STA请求Block ACK应答消息。 > 另外需要注意的是，在Wi-Fi6协议中，所有的触发帧（Trigger Frame）及其子帧都是AP专属的控制帧，只有AP有可能会发出触发帧，STA无法主动发送触发帧或其子类型。STA仅在收到AP的触发帧后，按照RU分配和时间同步的要求进行响应（如发送数据或ACK），但STA无权主动发起触发帧。这种设计确保了信道资源的集中调度和冲突避免。 > 需要说明的是，对于各个子帧类型不同的触发帧，其中所包含Common Info和User Info的信息可能会有较大的差异。例如MU-RTS类型的触发帧中，Common Info和User Info里面的大部分字段都是不存在的。 Common Info 以下对Common Info部分的重要字段进行解释： - Trigger Type：这个4bit额字段用于说明这个触发帧具体对应的子帧类型，Basic，MU-RTS，BSPR等（可参考上面的表格理解）。 - UL Length：本次上行传输的总时长（也就是STA本次上行传输包含的符号数）。 - More TF：大部分情况下设置为0，主要用于TWT等低功耗模式。 - UL Bandwidth：此处指定上行传输的带宽（20/40/80/160MHz），AP在此带宽内分配给各个STA所使用的上行RU资源 - GI and LTF Type：指定保护间隔（GI）的时间长度 - RU Allocation：定义了每个RU在信道中的频域位置（例如26-tone、52-tone RU）。 - AP Tx Power：此处的AP Tx Power字段是建议所有STA使用的统一发射功率基准，此外User Info部分允许为每个STA指定个性化功率参数。 - HE-SIG-A Info：携带HE PHY头的参数（如是否使用LDPC、STBC等）。 !image.png User Info 在触发帧的帧结构中，针对OFDMA进行RU分配的每个STA都有一个User Info数据结构。这个User Info中就包含了针对对应STA的独立配置信息。 以下对User Info部分的重要字段进行解释： - AID（Association ID）：对应于目标STA的Association ID。 - RU Allocation Index：对这个STA分配的具体RU索引（根据标准预定义映射表）。 - UL MCS（Modulation and Coding Scheme）：指定上行数据传输的调制编码策略。 - UL DCM（Dual Carrier Modulation）：是否采用双载波调制方式来传输上行数据。 - SS Allocation：空间流数（仅适用于UL MU-MIMO）。 - UL Target RSSI：AP要求STA在上行发送数据过程中的发射功率（基于接收信号强度的反馈）。 !image.png 参考资料 - The 802.11ax Trigger Frame – SemFio Networks - Trigger Frames in 802.11ax | Hitch Hiker's Guide to Learning
对AI NVR的思考以及君正的AI NVR平台A1
君正的A1系列是针对NVR市场所推出的集成式解决方案，相比于传统的NVR方案，君正方案最大的特色是继承了较强的AI算力，所以君正在这个方案的命名上也刻意的以xVR这样的形式进行命名，以强调其AI算力。 A1方案的架构和基本规格 以下是A1方案的架构图： !image.png - 主CPU仍然是君正基于MIPS进行深度定制的XBurst2，包含两个CPU核心，单核主频最高1.0GHz-1.4GHz。 - 内置DDR。根据具体型号的不同，A1系列内置有1Gb、2Gb、4Gb不等的DDR，系统设计和实现更容易。对于普通的只作为存储功能使用的NVR产品来讲，1Gb或者2Gb DDR基本就足够了，但是如果要并发支持多路AI或者同时在Display上拼接显示多路IPC的图像，就需要首先把IPC的码流解码出来，这样内存的需求就要大很多。因此为了支持更大的内存空间，A1系列的A1A型号也可以支持外部RAM扩展。 - 内置AI Engine硬件，是A1方案区别于普通NVR方案的一大亮点。AI算力的实现包含两个部分，支持神经网络卷积计算的NNA和支持SIMD指令的CPU协议处理器，这些算力能够把接入NVR的IPC Streaming解码后的图像进行Video AI分析和处理，实现NVR上的视频相关AI功能。A1 NNA单元能够支持的AI算力是1.4T@int8或者5.6T@int4，运行君正的Magik开放AI平台，可支持君正已经在IPC领域布局和应用多年的诸多AI算法。除了NNA以外，A1上还包含一个SIMD512的协处理核，Magik平台上的部分算法应该是也可以利用这个核所提供的SIMD指令来实现一些计算密集型的处理任务。 - 解码能力方面，最高支持4K 90fps H.264/H.265的解码。对于在NVR上进行接入视频的AI处理，以及对单路/多路图像的实时、历史视频进行回放，需要首先使用A1的解码能力对接入的码流进行解码，才能进行下一步的处理，所以要支持并发路数越多，分辨率越高，对于解码能力的要求也就越高。 - 显示接口和性能方面，可以支持HDMI2.0接口，以及4K 60fps的显示。相对应的，也就包含一个Display Engine，用于对多路视频解码后的图像进行缩放、拼接以及显示增强方面的处理。 - 其他外部接口方面，可以支持两个千兆以太网口，以及两个SATA3.0接口用于接两个SATA硬盘，算是NVR的标配。但是USB只能支持到2.0，这样的话接鼠标键盘没有太大问题，但是如果要支持事件录像文件在U盘上快速导出的话，USB2.0的速度就是一个很大的瓶颈。 总体来说，君正的A1系列主要包含以下产品系列：A1L，A1NT，A1X，A1A。 - A1L主要针对4-8路的低成本NVR应用产品。 - A1NT则主要针对当前主流的16路成熟类型的NVR产品。 - A1X和A1A主要面对32路的高规格、差异化的NVR产品形态。 !image.png A1方案对于AI的支持 君正A1方案一个比较大的特色，就是其中内置的AI Engine算力，以及在这个AI Engine硬件的基础上能够支持的AI框架Magik。 A1方案所具备的算力是1.4T@int8或者5.6T@int4。严格来说，这个算力放在IPC上，基本上还算是比较有竞争力的，君正的T40/T41，瑞芯微的RV1006大致都是这个规格。但是对于NVR产品来讲，如果要支持对多路IPC Streaming进行AI视频分析，这个算力规格跑2-3路问题不大，但是再多的话估计就比较吃力了。 另外一点，君正对于AI Engine的支持自然是在其规划和布局已久的Magik平台生态上做文章，这样可以把NVR系列与其IPC系列在AI方面的整体规划和安排放在一起，NVR可以直接使用已经在IPC系列上运行非常成熟的诸多视频图像类的算法。对于NVR或者IPC的产品开发商而言，既可以选择君正团队已经基于这个框架开发和训练好的算法，也可以从其中选择第三方团队在Magik平台以及君正芯片上开发好的算法，而如果产品开发商自己有成熟的团队和AI开发能力/模型，更是可以方便的把自己已经训练好的模型移植到Magik平台上，并运行在君正的芯片中。 !image.png 对NVR产品上引入AI功能的思考 我之前对2024年北美市场上销量比较好的几款NVR产品的形态以及功能列表进行了一些调研，并专门整理了一片笔记。总的来说： - NVR产品目前主要仍然是POE/以太网连接的天下，有线网络连接的方式更稳定，这一点对于超过8路摄像头接入的情况非常关键。实际上现在市场上也有一些类似Eufy Homebase这样的WiFi NVR的产品，但是绝大多数情况下，要么就是那种Event based的低功耗类型的IPC，大部分情况下多路摄像头不会同时并行上传数据，要么就是只能最多支持4-6路摄像头的接入。毕竟，要能够支持16路甚至32路4K级别图像分辨率的IPC同时接入，对于WiFi而言还是挑战太高。所以可以预期的是，对于NVR这类产品而言，如果要支持的IPC路数比较多，未来还是会以POE和以太网连接为主。 - 也有部分NVR产品在宣传上提出可以支持AI方面的处理，但是基本上能力都比较有限，其对AI的支持，要么是依赖于与NVR搭配的自家IPC上所具备的算力来实现，要么是只能对2-3路摄像头进行NVR端的实时分析。 - NVR的产品形态非常稳定，缺乏有效的产品概念创新，整个市场的竞争形势也比较清楚，基本上就是那几个比较大的NVR厂家在不断的进行一些产品型号上的迭代和微更新。整体而言，缺乏关键的用户痛点和有效的产品应用技术在该品类产品上的持续关注和解决。 也许，在NVR产品上增加端侧的AI功能，多少还是能够给这个产品形态的突破提供一些想象空间，通过这种方式，一些在别的品牌上需要订阅付费才能够使用的功能，就可以在NVR上所具备的AI算力上得到实现，对于NVR的使用体验上也可以有一些显著的提升。 但问题是，时间快进到2025的今天，针对low cost市场的IPC方案，例如爱芯的AX520，瑞芯微的RV1003，都已经普遍具备了0.5T这样级别的算力。而主流IPC产品的方案更是都已经基本具备了1-2T的算力，因此在IPC端已经可以实现大多数常见的人形、车辆、宠物乃至包裹等算法。 那么，在NVR这样的产品形态上增加AI功能的意义何在？ - 可配合接入一些不具备AI功能的非智能、传统的摄像头，在NVR端利用算力对这些传统摄像头的视频数据进行处理，增加AI视频分析所具备的功能。 - NVR应具备远高于IPC平台的AI算力，例如20-30TOPS，这样就可以在NVR上实现一些更复杂的、无法在IPC上实现的AI算法和相关的功能。 - NVR本身所具备的诸如视频分类、搜索、定位查找等方面的使用需求和体验，也可以基于AI NVR所具备的算力，做出更智能的标记，协助用户在使用过程中进行更快速的搜索定位和分类的功能。 参考资料 - AI Introduction PPT From Ingenic
对射频电路元器件的学习总结
本篇笔记对无线射频电路中常用的各种元器件电路的基本工作原理和应用进行简单的总结，为后续理解和设计完整的射频电路系统架构打好基础。 下图是一个比较典型的、简单的射频系统的框图： !image.png 无线射频电路中所用到的各种主要的元器件，根据其是否有外部供电的方式，可以分为有源器件和无源器件两大类。 - 有源器件包括：射频收发芯片RF Transceiver，功率放大器PA，低噪声放大器LNA，射频前端模块FEM，有源晶振，射频开关等。 - 无源器件包括：滤波器Filter，双工器Duplexer，双迅器Diplexer，耦合器Coupler，电阻电容电感，天线，无源晶振等。 射频收发芯片RF Transceiver RF Transceiver实际上包含了RF Transmitter和RF Receiver，也就是同时具备了射频信号接收和发射的功能。RF Transceiver是整个射频电路系统的核心，用于产生适合无线通信使用的高频RF信号。而所谓的射频系统架构本质上就是以射频收发芯片为核心，在其外围搭配一些其他的射频前端电路。 RF Transceiver具备的主要功能就是： - 对于射频信号的发射而言：把基带调制信号进行上变频、频率合成，并进行信号的初步放大后产生射频信号，再经过PA的进一步放大，通过天线开关切换后由天线辐射出去。 - 对于射频信号的接收而言：从天线上接收到的射频信号，经过天线开关后在LNA中进行放大，送入射频收发芯片中进行下变频和滤波的操作，恢复出来基带调整信号，得到基带解调信号。 因此，从标准意义上讲，RF Transceiver与PA、LNA、射频开关等是分开的，各自具有各自的功能，但是现在在消费类电子中的集成度越来越高，很多射频收发芯片中实际上已经把PA、LNA以及射频开关这些都已经集成进去了，甚至在一些5G手机的射频收发芯片方案中连天线的合并进去了，这样射频电路的设计和调试就变得非常简单。 功率放大器PA PA，就是Power Amplifier功率放大器。在射频电路中，PA的作用就是在射频的发射链路中，把RF Transceiver所产生的射频信号进行功率放大，使得通过天线发射出去的功率能够满足传输距离的要求。 从制造工艺的角度上，目前PA常用的工艺主要有四种：砷化镓GaAs，氮化镓GaN，锗化硅SiGe，以及CMOS。其中在射频功率放大器领域，砷化镓GaAs工艺占据主流位置。 具体的产品应用中，需要充分的认识到降低PA功耗的重要性，因为PA的功耗占据了射频电路功耗的大部分，多天线以及高通信速率的产品需求会导致PA的功耗对产品的整体功耗、使用续航时间乃至散热设计造成很大的影响。 低噪声放大器LNA LNA，就是Low Noise Amplifier低噪声放大器。LNA的作用与PA类似，都是对射频信号的放大，只不过PA用于发射链路中，对要通过天线发射的射频信号进行功率放大，以确保信号的发射可以满足传输距离的要求；而LNA则用于接收链路中，对从天线上收到的射频信号（通常非常微弱）进行放大，满足射频信号解调的需求。 因为从天线收到的射频信号一般非常微弱，那么放大器本身运行所产生的噪声就有可能对这个微弱信号产品严重的干扰。而LNA里面的所谓Low Noise低噪声，就是指这种LNA放大器本身具有非常低的噪声系数（这一点是LNA最有特色的地方，噪声越低，灵敏度越高），这样在其对接收到的射频信号进行放大的时候，才能尽可能提升灵敏度和信噪比，从而帮助解调电路顺利解出基带信号。 射频前端模块FEM FEM，就是Front End Module射频前端模块。FEM实际上就是在一个芯片中集成了多个射频单元电路的模块，例如，FEM中可以集成包含PA、LNA、滤波器、射频开关等，有些模块甚至把射频收发器和天线阵列都包含在内。FEM的存在主要是为了提升产品开发的集成度和轻便化的需求，也降低了射频调试和开发的复杂度和难度。 因为FEM本身只是多个射频单元电路的集成模块，所以它整体的功能及其性能指标就由其内部所包含的射频单元电路决定。 射频开关Switch 射频开关本质上就是一个开关，既可以用于判断和控制在同一频点上TX和RX分时接通天线，也可以用于控制不同频段的系统在RF链路中何时接通。所以，从逻辑上看，可以把这个这个器件认为是一个理想的开关器件，只不过用于射频电路中，一般称为射频开关，而如果用于控制天线端口的接通和切换，则称之为天线开关。 当然，与普通开关不同的是，对于射频开关而言，其工作在高频的射频领域，那么就有一些自己独特的工作参数：工作频率（这个开关器件适合允许的频率范围），各端口之间的隔离度（开关控制的多个通道之间的隔离程度，尽可能避免相互影响）、插入损耗（插入这个开关器件后对于信号功率的损耗，当然是越小越好）等。 双工器Diplexer/Duplexer 在[[对双频WiFi天线复用理解的纠正以及对Duplexer和Diplexer的比较]]一文中已经有非常详尽的解释了。 滤波器Filter 滤波器在射频电路和系统中的运用，包含发射和接收两个方面： - 在接收方面，主要就是为了最大程度的衰减接收信号中所包含的那些不需要的频段中的信号，并且尽可能对需要的频段的信号造成最小的影响。 - 而在发射方面，则是用于尽可能减少和衰减发射器电路中所包含的谐波、杂散以及带外泄露，以避免对各种RF频段的通信造成相互之间的共存干扰。 滤波器具体的实现原理是基于R、L、C的谐振电路形成的二端口网络，利用谐振电路的选频特性对通带内频率信号呈现匹配传输，对阻带内频率信号失配而进行衰减，从而实现信号频谱过滤功能。 按照对信号频段的过滤特性进行分类，可以把滤波器分为低通滤波器、高通滤波器、带通滤波器、带阻滤波器几种类型。 !image.png 按照滤波器实现所使用的器件类型，可以把滤波器分为有源滤波器和无源滤波器两种类型。在消费类电子中所使用的滤波器一般都是无源滤波器。 功率耦合器Coupler 功率耦合器是一种无源器件，在RF电路中从射频通路中通过耦合的方式分配出来一部分信号功率和能量，然后把这部分耦合出来的能量用于实现对该射频通路输出功率的检测以及反馈调整。从其起作用的原理上讲，功率耦合器一般用于发射通路，最典型的使用场景就是从功率放大器PA的输出电路中耦合出来一部分能量，对这部分能量进行检测后，通过反馈形式控制功率放大器的输出功率大小。因此，随着集成度越来越高，大部分功放PA实际上已经在其内部集成了功率耦合器来实现对其发射功率的反馈和控制，只有在一些非常特殊的应用中才需要独立外加耦合器。 下图是功率耦合器Coupler的等效电路图。一般是一个四端口的无源器件，功率放大器输出的功率通过输入端1接入，在输出端2输出。PA的能量除了通过输出端2进行输出以外，还有一部分能量通过耦合的方式在耦合端3输出，通关把这个耦合端输出的能量接入到射频收发芯片，就可以用于检测功率放大器的输出功率，然后对其进行调整和控制。输出端4是隔离端口，没有功率输出。 !image.png 参考资料 - 无线秘籍：射频电路设计入门，第六章 - 射频-滤波器基础知识 - 射频-定向耦合器基础知识
对双频WiFi天线复用理解的纠正以及对Duplexer和Diplexer的比较
之前在我的另外一篇描述2.4GHz和5GHz双频WiFi共用一根天线进行通信的笔记中，基于对于下图的理解： !image.png 简单的认为：_对于双频wifi的天线复用问题，逻辑上其实跟WiFi与蓝牙之间复用天线的情况一致：无论如何复用，最后都是通过时分的机制来实现的，同一时刻，要么是2.4GHz频段在使用WiFi天线，要么是5GHz频段在使用WiFi频段。既然是分时的天线复用逻辑，那么就势必会对各个频段通信的吞吐率造成一定的影响。以最简单的等比分时复用的逻辑对SPDT开关进行切换，那么对于2.4GHz和5GHz频段而言，都只有一半的时间可以拥有天线的使用权，当然会对各个频段使用的通信吞吐率造成显著的影响。尤其是对于射频的接收而言，如果在接收信号到达天线端但是SPDT开关未能切换到与之匹配的工作频段时，这个数据包肯定就丢包了，接下来只能在开关切换过来以后通过重传来解决问题。所以这样的频繁切换对于射频收发吞吐率的影响是无法避免的。_ 但是实际上我以上的这个理解和总结是错误的。经过网友Seas Li的指正，在2.4GHz/5GHz双频WiFi对于天线的复用设计上，更合理的实现方式并不是采用以上的射频开关在两者之间分时复用切换，而是采用Diplexer来实现两者的并行工作，互不影响，不需要时分切换，也就不存在影响吞吐率的情况。 那么接下来的问题就是： - Diplexer及其工作原理（即Diplexer如何实现不同频段对天线同时使用而互不影响）是什么？ - Diplexer与Duplexer等类似元件在应用上的差异是什么？ - 既然Diplexer对于双频WiFi的天线复用是更合理的设计，为什么前面的双频wifi的框图中明确表明使用SPDT射频开关进行切换？ 本篇笔记的目的就是尝试对以上几个问题进行解释和分析。 RF Diplexer及其工作原理 在射频电路中使用的Diplexer，在有些资料里面被称为双工器，但是另外一个功能类似的器件Duplexer往往也被称为双工器，所有部分资料把Diplexer称为双讯器，把Duplexer称为双工器。本文为了避免混淆，统一使用英文Diplexer和Duplexer，不去纠结命名上的细节差异。 从作用上将，Diplexer的主要作用是可以将不同的频段的信号分离或者合并在一起，这样就可以用同一根天线或者传输通道，来实现对多路不同频段信号的同时接收和发送。 放在双频WiFi的角度来解释，就是Diplexer可以把双频WiFi的2.4GHz和5GHz频段的信号进行分离（用于接收）和合并（用于发送），然后两个频段的信号就可以同时共用同一根天线进行通信。与双频WiFi类似的，LTE手机上多个不同频段（band）的通信，也可以使用Diplexer来进行隔离。 从工作原理上讲，Diplexer内部包含了两个独立的带通滤波器，分别对应于其要进行隔离的不同频段： - 对于信号的发射而言，不同频段的RF信号经过带通滤波器滤波以后，因为两个带通滤波的频段不同，所以可以叠加后同时使用一根天线进行发射。 - 而对于信号的接收而言，从天线上接收到的RF信号，经过带通滤波器过滤以后，只有自己频段范围之内的信号可以通过，这样天线就可以同时接收多种不同频率的RF信号，经过Diplexer的带通滤波处理后进入各个频段自己的解调电路。 !image.png 通过以上带通滤波的方式，就可以使用多个不同频段的信号在同一时间通信过程中的分离和合并。 那么对于双频WiFi而言，使用Diplexer进行2.4GHz和5GHz频段同时并行工作的结构如下图所示： !image.png Diplexer/Duplexer的应用差异分析 既然以上解释了Diplexer的工作原理和主要的应用场景，那么也就无法避开双工器的另外一种器件类型-Duplexer。双工是什么？所谓的双工就是通信的设备之间可以同时进行双向传输，也就是可以同时进行发射和接收。 Diplexer和Duplexer作为双工器，就是用来解决射频通信中的双工通信的，确保通信的两个设备之间可以同时相互通信。 对于Diplexer的理解已经比较清楚了，就是用于隔离和区分两个或者多个不同频段的信号，避免不同频段的信号在同时通信时产生相互的冲突。其起作用的基础本质上就是两个针对不同频段的带通滤波器，两个频段之间的间距一般都比较大。 很多资料上对于Duplexer的解释是：Duplexer用于隔离同一频段的发射信号和接收信号，允许同一频段的发射机和接收机共用一根天线，同时通信的过程中不会相互干扰。然后再搭配这样的示意图： !image.png 总体上给人的感觉就是：Diplexer可以用于支持两个不同频段的通信能够并行进行，相互不会影响；而Duplexer则用于支持同一个频段的发射和接收能够共享同一根天线，并且能够同时通信互不影响。 但是问题来了： - 所有有关Duplexer的资料上都提到，Duplexer只会用于FDD系统。既然是FDD，那么收发信道所使用的频率就是不一样的，而Duplexer又用于解决同一个频段内的收发共享问题，这两者不是矛盾的吗？ - 在WiFi、BLE、TD LTE等时分机制通信中都会提到，RF模块在同一个频点上要么处于接收状态，要么处于发射状态，不可能在同一个频率上同时接收和发射（这种本质上也就是半双工），那么Duplexer如何能够做到相同频段发射和接收的全双工通信呢？ 对于以上示意图以及两个问题，我的理解是： - Duplexer确实是只用于FDD系统中，以LTE FDD通信为例，一个频段里面包含了多个通信频点，上行和下行通信（分别对应基站和手机的收发功能）分别使用不同的频点，也就是说收发信道处于同一频段的不同频点上，两个频点的间距比较小，但是能够通过Duplexer内部的带通滤波进行区分和隔离，从而使之能够同时通信并且不会相互干扰。 - WiFi BLE这类上行和下行通信使用相同频率、时分机制来实现的通信方式，只能实现同一时间要么发射要么接收的半双工通信状态；而对于FDD这类上下行通信使用不同频点的通信方式而言，因为两个频点之间本身就可以通过滤波器来进行区分和隔离，自然就可以做到全双工通信了。 两者的应用差异 总结起来： - Diplexer主要用于不同频段之间共享同一根天线或者传输链路来进行通信的应用，最典型的就是双频WiFi两个频段，以及LTE多个BAND之间。 - Duplexer则主要在用于同一个频段内，使用FDD模式下的不同上下行信道通信频点上，实现同时收发全双工通信的应用。最典型的应用就是LTE FDD模式的通信。 那么对于2.4GHz的单频WiFi或者BLE的TX和RX的切换而言，究竟使用的是Diplexer还是Duplexer？ 答案是两者都不是。因为2.4GHz单频的情况下，不属于Diplexer要解决的不同频段的复用问题，使用Diplexer当然不合适；而WiFi和BLE使用的是时分机制通信，上下行通信使用相同频率的信道，也不是Duplexer要解决的FDD全双工通信的问题，所以使用Duplexer也不合适。这种情况下使用的是射频开关（或者天线开关），由射频开关来判断和决定应该是TX还是RX接入天线。 题头框图中为何使用SPDT射频开关而不是Diplexer？ 那么问题来了，从Diplexer、Duplexer、开关等的工作原理的角度来看，对于双频WiFi不同频段之间共享同一根天线进行传输的实现而言，Diplexer确实是更为合理的技术选择，那么为什么题图中的双频WiFi架构图中采用了SPDT开关对两个频段使用天线进行切换呢？ 针对这个问题，我专门咨询了这家供应商的FAE，从供应商得到的答复是，他们的WiFi模块从成本、典型应用场景等方面考虑，虽然能够支持双频WiFi的两个频段，但是5G和2.4GHz的部分RF电路是共用的，因此即使在天线的共用上采用了Diplexer，其后面的RF电路也没有办法支持两个频段独立工作，所以在这种情况下，采用SPDT天线开关从两个频段上二选一就是合理的设计选择了。 参考资料 - 射频器件-双工器基础知识 - 《无线秘籍：射频电路设计入门》，第六章 - 无线通信 | 双工器Duplexer和双讯器Diplexer的概念、作用、参数及选型 - 知乎
半波对称振子天线基础及其天线增益
按照《LTE教程：原理与实现》一书的说法：半波振子天线是天线最基本的结构单位，相当于是化学中的分子。所以要想对不同形态和应用中的天线有完整的理解，就要从其源头，也就是半波对称振子天线的工作原理来开始。 本文对半波对称振子天线相关的各方面基础知识进行整理和总结，作为学习更复杂的天线系统技术的基础。 半波对称振子天线的结构和辐射 从结构上看，一个半波对称振子天线是由一对1/4波长的导体所组成，完整的长度就是1/2波长，这就是半波振子天线的由来。而这个所谓的波长当然是天线所收发的电磁波的波长，处于不同频段的电磁波的频率和波长不同，因此依据其波长计算出来的天线长度也就有差异。天线的长度与其收发的电磁波的波长/频率关系保持一致的情况下，才能发挥出来最佳的性能。 !image.png 波长的计算公式：λ= C/f （公式中，C为光速，f为工作频率，λ为波长）。在相同的介质中，不同频率下，天线的工作波长不同。频率越高，波长越短，对应的天线也就越短。取光速C为3x10^8m/s的情况下： - 2.4GHz电磁波对应的波长是：(3x10^8m/s) / (2.4GHz) = 12.5cm。对应的1/2半波长度是6.25cm，那么单个振子的天线长度就是3.125cm。 下图是半波振子天线在水平方向和垂直方向上的辐射方向图。半波振子天线在水平面上的各个方向的辐射强度都相同，其水平面的半功率辐射角是360度，也就是说在水平方向上是全向天线；而在垂直面上，其半功率角为78度，在振子的轴线方向上辐射为0。辐射方向的立体图看起来就像是一个甜甜圈的形状。 !image.png 在天线增益方面，以球形均匀辐射体的电磁场作为参考的情况下，半波对称振子天线的天线增益是2.15dBi，波瓣的宽度比较大，因此增益较小，实际应用中，如果要提升对称振子天线的增益，可以使用多个对称振子组成一个天线阵列。 _当然，半波对称振子天线作为最基础的天线类型，也往往作为另外一个天线增益单位dBd的参考值，即dBi=dBd+2.15。因此，当评估一个天线的天线增益时，既可以使用球形均匀辐射体的dBi为单位，也可以使用半波对称振子天线对应的dBd为单位，两者相差2.15db。_ 如何提高半波振子天线的增益？ 如上所述，对于标准的半波振子天线而言，其相对于的球星均匀辐射体的天线增益只有2.15dBi。这个天线增益在很多应用中是偏低的，那么如果要如何提高半波振子的天线增益呢？毕竟，只有提高了天线增益，天线所传输的无线信号才能覆盖更远的距离。这个问题的答案是可以把多个半波振子天线并联，形成天线阵列。如下图所示，多组相同的单元振子以并联的方式连接到同一个馈点上，形成阵列。 !image.png 多组半波振子天线经过并联组成天线阵列以后，所形成的方向图如下所示。 !image.png !image 在半波偶极子按照以上并联方式垂直排列的情况下，当偶极子对数增加一倍，其半功率波束宽度大约降低一半，辐射主瓣方向的增益增加3dB。随着天线增益的增大，其主瓣的辐射功率在水平方向上的辐射功率角也随之减小。 - 1组半波振子的主瓣半功率波束角度为78度，增益为2.15dBi。 - 两组半波振子的主瓣半功率波束角度降为32度，增益为5.15dBi。 - 四组半波振子的主瓣半功率波束角度降为15度，增益为8.15dBi。 - 八组半波振子的主瓣半功率波束角度降为7度，增益为11.15dBi。 进一步提升天线增益-定向天线 以上无论是一对还是多对半波振子天线，在水平方向上的功率辐射强度都是对称且各向相同的，也就是说半波振子天线是水平方向的全向天线。这种全向天线对于家庭路由器这种不限制功率辐射角度和方向的全向应用方向而言是比较合适的，但是对于移动基站的天线而言，对于天线的要求是希望能够把功率辐射到一定的角度范围内，并且保证尽可能高的天线增益，这样才能保证在这个方向范围内更远的覆盖距离，对于这种定向辐射的应用而言，在水平方向上的全向功率辐射不仅会对同一基站上架设的其他方向天线造成干扰，而且还会白白损失宝贵的辐射功率。 那么对于半波振子天线而言，如何实现LTE基站所需的定向高增益天线呢？答案是增加反射板+多对振子的组合。 !image.png !image 在上图中，标准的一对半波振子天线在水平方向上的功率辐射是全向360度；在其一个方向上增加一个反射板，就可以把辐射功率反射并且加强到180度的覆盖区域；再配合以上的多对半波振子的天线，就可以进一步缩小天线辐射功率的覆盖范围，同时增强其目标辐射范围内的天线增益。 下图是一个标准的多对半波振子天线所组成的定向天线的辐射图。在这种定向天线的设计方向上，目标是尽可能把辐射功率限制在主瓣所指向的空间范围内，同时限制后瓣和旁瓣的辐射功率和能量。 !image.png !image 参考资料 - 通俗易懂！看完你就是半个天线专家了 - 知乎 - 《LTE教程：原理与实现》 - 超详细的天线知识（收藏）！
G-Sensor的工作原理及其应用总结
G-Sensor：Gravity Sensor即重力传感器，或者Accelerometer即加速度传感器，其作用主要是检测物体在运动过程中加速度的突然变化。 GSensor最典型的应用就是在行车记录仪中，当GSensor检测到瞬间的加速、碰撞或者减速（例如急刹车）状态，会自动触发行车记录仪摄像头的内部记录事件，保存一个紧急录影文件作为后续进行事故分析的证据。 G-Sensor的工作原理 可以结合下图来理解GSensor的工作原理。使用两个弹簧把一个质量块固定，当没有加速度的情况下，质量块的位置处于两个弹簧的中间；当整个测试机构向左加速运动或者向右减速运动时，质量块因为惯性向右偏移，根据动态的偏移量就可以得到此时向右的加速度大小。相反，当整个测试机构向右加速运动或者向左减速运动时，质量块因为惯性向左偏移，根据动态的偏移量就可以得到此时向左的加速度大小。 !image.png 这个偏移方向和偏移量对应的就是这个轴向上的加速度值，反映在GSensor上就是X、Y、Z三个轴上的加速度大小。 !image.png G-Sensor输出值的计量单位是g，1g代表一个重力加速度，也就是9.8m/s^2，1g=1000mg。对于GSensor器件而言，其输入值一般为I2C或者SPI接口的数字信号。以STK8327为例，其输出值的范围为可由用户配置的±2g/±4g/±8g/±16g，每个轴进行一次采样产生一个16bit数据，三个轴进行一次采样就会生成6个字节的加速度数据，这6个字节就是一个frame。GSensor内部FIFO对于加速度数据的存取，以及与MCU之间通过I2C/SPI读取加速度数据，都应该以frame为单位。 G-Sensor的内置检测算法 除了能够检测、缓存并输出加速度数据以外，大多数GSensor型号内部还内置了一些基于加速度数据进行判断的常用检测算法。可以通过寄存器配置这些检测算法的使能，并且通过外部中断等方式通知MCU检测事件的发生。这些常用的加速度检测算法包括：动作检测，自由落体检测，方向检测，点击检测等。 以下简单介绍两个常用的GSensor内置算法：Any-Motion(Slope) Detection，Significant Motion。这两个算法在部分的GSensor里面都有，只不过命名方式有差异。 Any-Motion(Slope) Detection，这个算法主要就是对通常的运动行为进行检测和判断，只不过额外增加了一点过滤。以下面的这个截图来说明Slope Detection算法的工作原理。上图是GSensor的连续采样点的值，中图是各个采样点数据与阈值之间的比较，下图是中断引脚的波形。从图中可以看到，当GSensor的连续三个采样值幅度超过设置的阈值时，中断引脚才会触发，而当连续三个采样值幅度小于设置的阈值的时候，中断引脚拉低。通过这样的方式对Motion事件的判断进行一定程度的过滤，避免突发的1-2个毛刺造成中断引脚的误触发，可以让Motion判断的结果更稳定。 !image.png Significant Motion算法主要是针对设备/用户位置发生变化的行为进行准确的判断，但是希望能避免过多的误触发。该算法最典型的应用就是在手环、智能手表这类可穿戴设备上的应用，能够稳定的检测到人行走过程中的状态，但是希望能够自动过滤一些比较轻微的加速度值变化的行为，例如手机/手环放在桌面上，周围环境的轻微震动应该能够被自动过滤掉。 Significant Motion算法的工作原理，本质上也是对GSensor的实时采集数据进行一段时间的判断，结合不同大小的阈值来决定是真正的SIgnificant Motion还是一些小的干扰。 GSensor休眠过程中是否还在采集数据？ Gsensor在应用中一个很有意思的问题就是：GSensor处于休眠的状态下，究竟是否还需要不断地采集加速度数据？ - 如果需要的话，那么跟不休眠是没有本质上的区别，其内部的采集电路要始终处于工作的状态之下，如何能够实现低功耗呢？要知道低功耗对于手环、手表这类产品可是极度重要的。 - 而如果不需要的话，那它什么时候会唤醒呢？最简单的答案就是加速度值超过一定阈值的时候唤醒，但问题是如果它都没有采集数据，如何能够知道当前的加速度值是否超过设置的阈值呢？这就变成了一个鸡生蛋，还是蛋生鸡的问题了。 通过对几份GSensor的数据手册进行学习，我大概搞明白了GSensor实现低功耗状态的工作逻辑：大致就是，GSensor处于低功耗工作模式下，也是需要定期醒来采集数据的，其运行时间会被区分为休眠周期和唤醒周期。 在休眠周期中，绝大部分电路和数据采集转换的功能关闭，保持极低的运行功耗。 当休眠周期的时间到了以后，GSensor自动进入唤醒周期，唤醒后经过一个短的稳定时间settle time，然后采集一组数据保存在FIFO中，并比较这组采集数据跟寄存器设置的阈值，决定是否需要通过中断引脚唤醒MCU。如果低于阈值则重新进入休眠周期，等待下个唤醒周期的到来。 例如下图是STK8327低功耗模式EDM的工作时序图，红色部分就是唤醒周期，绿色部分就是休眠周期。 !image.png GSensor的应用 下面以Sensortek的STK8327来解释GSensor在实际产品中应用的注意事项，其他厂家的GSensor型号在具体使用上大同小异。 STK8327是一个XYZ三轴加速度传感器，主要规格包括： - 可支持用户配置加速度检测范围±2g/±4g/±8g/±16g - 以16bit数字方式输出加速度值 - 用户配置1s可输出14-2000个加速度采样，片内FIFO可支持缓存32组加速度采样值 - 两个中断引脚，可以通过寄存器灵活配置为对应内部的不同中断模式 - 支持的数字通信接口为I2C或者三线/四线SPI - 封装是2.0mm x 2.0mm x 1.0mm LGA。 !image.png 12个引脚，除去NC和Reserved，剩下的10的引脚就是电源、地，SPI、I2C，以及两个中断引脚，使用上非常简单。Layout时需要注意芯片封装上的圆点，具体使用中要根据这个圆点来确定GSensor的XYZ轴的方向。 !image.png 工作模式及其切换 STK8327有四种工作模式。其中： - Power OFF是关机模式； - Normal是正常工作模式，MCU可以在Normal模式下持续的使用I2C或者SPI从GSensor上读取加速度数据，但是不建议在Normal模式下修改寄存器； - Suspend模式是专门用于设置寄存器的工作模式，这种模式下芯片内的所有模拟电路和晶振都停止工作，一般可以在这种模式下对STK8327的内部寄存器进行设置，设置完成后再切换到Normal模式下读取加速度数据； - Low Power模式是针对低功耗设计的休眠工作模式。这种模式下除了晶振之外的大部分模拟电路都处于关闭状态，有效的降低了Gsensor的运行功耗。 ![[1736848751069.png]] !image.png 四种工作模式中，其他三种在应用上都比较简单。而Low Power实际上才是G Sensor应用的精髓所在，毕竟绝大多数使用G Sensor的产品都要依赖于其Low Power模式来实现低功耗以及Motion事件检测的效果。 Low Power Mode 在STK8327的low power mode下，实际上这个GSensor反复的在休眠周期和唤醒周期下切换：首先按照参数设置的时间周期进入休眠周期，此时停止数据采集，芯片进入极低功耗的工作状态；休眠时间到或者发生其他外部事件后，GSensor进入唤醒周期，开始采样数据并存入FIFO，并根据采样数据决定是否通过中断唤醒MCU；采样数据结束以及中断状态解除后重新进入休眠周期。 在Low Power工作模式下，STK8327提供了两种唤醒周期下的工作时序：EDM和ESM，主要区别是在唤醒周期中GSensor采样数据存入FIFO的逻辑不同，具体要使用哪一种模式，需要考虑MCU端如何使用GSensor FIFO中的历史数据来实现检测和判断算法。 EDM：Event Driven Mode，事件驱动模式。在这种时序模式下，GSensor在低功耗的唤醒周期中所采样的所有数据都会存入FIFO。需要注意的是，如果发生其他类型事件的情况下，GSensor处于唤醒周期的时间可能会延长，这样在FIFO中保存的连续GSensor采样之间的时间间隔就不是固定的。因此，这种模式比较适合于那些不依赖于FIFO缓存历史数据的应用。 !image.png ESM：Equidistant-Sampling Mode，等距采样模式。顾名思义，在这种工作时序之下，GSensor保存在FIFO中的连续采样数据的时间间隔总是相同的。如果MCU端需要依赖于FIFO中的历史数据实现一定的判断算法，那么正常情况下使用这种工作模式更为合适。从下图可以看到，如果GSensor进入到唤醒周期，即使有多个数据采样，也只会保存固定时间周期的采样数据（向上箭头）到FIFO中，其他采样数据（五角星）会被丢弃。这种模式比较适合于依赖于FIFO历史数据来执行一些算法判断的产品应用。 !image.png 参考资料 - G-sensor概述及常用芯片整理 - 简书 - STK8327 datasheet
G711音频压缩标准的实现详解
G.711是ITU-T所定义的一种音频压缩标准，广泛应用于电话通信网络和VoIP领域。在具体的实现上，G711的音频编解码又可以分为u-law（主要应用于北美和日本）和A-law（主要应用于欧洲和世界的其他地方）两种形式，在本文中分别进行说明。 G.711在电话通信应用中所定义的采样率是8KHz（需要明确的一点是，G.711音频编码算法本身并不限制采样率，这里的8KHz采样率是电话通信网络的兼容性要求，因此如果要考虑通话系统中不同厂家的设备之间的兼容性，应该采样标准所定义的8KHz。而如果只是要在通信两端使用G.711对音频数据进行编解码，不需要考虑与其他厂家设备的兼容性的话，完全可以采用更高的采样率。），音频的每次采样产生一个16bit的采样原始数据，这种情况下原始数据的码率就是8000Hz x 16bit = 128Kbps。G.711音频编码算法对音频采样的原始数据进行编码，每个音频采样的16bit数据会被压缩为8bit，压缩率为2:1，因此针对8KHz的采样率产生出来64Kbps的编码数据。 如上所述，G.711音频编解码算法的具体实现上主要有两种主要的编码方式：μ-law（北美和日本使用）和A-law（欧洲和其他地区使用）。无论是μ-law还是A-law，都是非线性量化方法，在进行音频数据编码时通过对数压缩来优化动态范围，这样可以使得在低音量时具有更高的精度，而在高音量时精度较低。 G.711 Alaw的理论及其实现 对于音频采样数据进行G.711 Alaw编码和解码的理论公式如下所示。其中A一般采用87.6的常数值，sgn(x)是取符号函数，x为正数时返回1，负数时返回-1；x为音频采样数据在（-1，1）之间的归一化值，即每个16bit音频采样数据的最高位为符号位，在按照下面的公式计算之前先把去掉符号位的15bit数据除以32768，再合并最高位的符号位得到（-1，1）的归一化数据。 编码公式： !image.png 解码公式： !image.png 下图是按照以上公式所画出来的音频采样归一化数据与经过alaw编码后的映射图。可以看到在音频采样值x比较小的时候，它在图中映射对应的F(x)的变化非常剧烈，x的微小变化就会导致F(x)的剧烈变化，因此在采样值较小的情况下，alaw的编码精度比较高。而在采样值比较大的情况下，F(x)的变化幅度就比较小了，采样精度相对也就比较差。 !image.png 按照以上所描述的G.711 Alaw音频编码流程的代码实现如下所示： 具体的实现中，首先调用normalize_16bit_to_float进行音频采样数据的归一化计算，把16bit采样数据归一化到（-1，1）之间；然后再调用a_law_encode进行编码，编码结果就是一个无符号的单字节数据。 但是如果按照以上公式进行alaw的编解码运算符的话，涉及到log等对数运算，这一点对于之前在电信领域早期的电话系统中硬件资源有限的情况，挑战很大。所以在alaw的具体实现上，为了节约宝贵的计算资源，一般采用十三折线法逼近alaw的理论曲线来降低计算复杂度。十三折线法通过分段线性逼近 A-law 的非线性特性，将输入信号的动态范围划分为多个区间，每个区间用一条直线来近似。这种方法既保留了 A-law 的非线性特性，又大大降低了计算复杂度。 !image.png 按照十三折线法进行alaw运算时，16bit音频采样数据首先要通过右移三位变成13bit数据，然后对这个13bit数据进行如下计算分别得到符号位（1bit）、指数部分（3bit）和尾数部分（4bit），最后组合为一个8bit数据： - 首先取13bit数据的最高位为符号位。将其取反得到s； - 通过对剩下的12bit数据进行判断，根据其bit1出现的最高位的位置决定指数部分的取值，从0b000-0b111，也就是指数位eee； - 从12bit数据最高的bit1位置向右取四个bit，也就是尾数位abcd； - 最后组合符号位、指数位和尾数位这三个部分为seeewxyz，编码完毕。 以上工作逻辑如下图所示： !image.png 以下是从音频采样的16bit数据进行G.711 Alaw压缩的代码片段。 G.711 ulaw的理论及其实现 G.711 ulaw压缩算法主要应用于北美和日本市场，编码的理论公式如下所示： !image.png - 进行以上计算之前，仍然要像alaw一样，先把16bit采样数据归一化到（-1，1）之间。 - 以上计算公式的输入为归一化到（-1，1）之间的16bit音频采样数据，输出则是音频采样压缩生成的8bit编码数据。 解码的公式如下图所示： !image.png - 以上计算公式的输入为G.711编码生成的8bit压缩数据，输出为（-1，1）区间范围的解码数据，具体要进行播放时需要重新映射为16bit的音频采样数据，通过audio codec播放出来。 在G.711 uLaw的具体实现上，与alaw的实现类似，同样采用折线法来逼近uLaw的曲线以减少计算的工作量。不同的是，alaw采用十三折线法，进行折线计算的数据是音频采样右移三位的13bit数据；而ulaw采用十五折线法，进行alaw的折线计算时首先对音频采样数据右移二位变成14bit数据。 十五折线法实现的流程可以基于下表来使用查表的方式来实现： !image.png 以音频采样数据经过右移2位后数据是1234为例，解释十五折线法具体的查表实现流程如下： - 首先通过查询上表取得区间范围值，查表可以得到1234位于以下区间： +2014 to +991 in 16 intervals of 64 - 根据以上的区间范围值得到其基础值为0xA0，间隔数interval为64 - 以上区间范围的初始值为2014，再当前值1234和区间范围初始值的差异为2014-1234=780 - 基于以上的差异值计算偏移值：780/间隔数=780/64，取整得到12 - 最终得到的输出为0xA0+12=0xAC。 可参考以下代码实现： 总结 - 无论是G.711a还是G.711u，实际上都是一种对于单个音频采样数据进行压缩的算法，两者在压缩的实现原理上，都是在小信号区域提供更高的量化精度，而在大信号区域减少量化精度，从而在有限的比特率下实现高效的语音编码。 - 尽管在电话领域中所采用的G.711音频编码要求固定的使用8K采样率（采样率固定为8K，码率固定为64Kbps），但是实际上对于G.711算法本身的实现而言，因为它是对单个音频采样数据进行的编码处理，算法本身对采样率并没有特定的要求。这里的8K采样率的要求只不过是为了满足音频通话的需求（4KHz对于大多数音频通话而言足够使用了），较低的采样率也意味着较低的计算工作量，所以通话双方都采用8KHz来进行采样和编解码的话兼容性就没有问题。而如果音频通信的两端能够通过其他机制自动识别采样率的话，使用G.711编码时完全可以采用更高的采样率，例如16KHz、32KHz等，只不过这样的话码率就会大一些。 - 至于alaw和ulaw计算中所采用的十三折线法或者十五折线法，同样是基于减少计算工作量的角度出发，采样折线拟合的方式去逼近alaw和ulaw的对数曲线，这一点与二三十年前电信通信领域中所采用的处理器具备的计算能力不足相关。如果处理器的计算资源不是瓶颈的话，直接采用对数运算来进行G.711编码当然也是没有任何问题。 参考资料 - 音频处理——G711标准详解_g711a和g711u区别-CSDN博客 - A律十三折线法G711编解码介绍_13折线a律编码-CSDN博客 - G.711编码原理 - 简书
基础相位调制技术之BPSK/QPSK/DQPSK
BPSK、QPSK等几种对相位进行调制的载波调制方式，是目前在无线通信中使用非常广泛的调制方式。在各个WiFi标准中所包含的低规格MCS，基本上都是使用BPSK、QPSK等相位调制方式。 !1736407097077.png BPSK: Binary Phase Shift Keying BPSK是最简单的相位调制方式，其中的Binary就表示使用相位0度和相位180度分别代表逻辑0和逻辑1。也就是说，BPSK每一组载波传输一个bit的基带数据信息。 在BPSK的具体实现上，逻辑0和逻辑1，或者是相位0度和相位180度，就是把作为载波的正弦波乘以+1或者乘以-1来进行操作。如下图所示： !image.png 但是在具体的实现上，还是有一些细节问题需要考虑：在经过BPSK调制以后的载波发射过程中，载波应该在哪个相位切换？例如在在下图中，如果在载波幅度处于最高时立即切换到其载波的最低幅度，就会产生所谓的high slop transition的问题：载波幅度的剧烈变化会辐射出高频能量到其他频段，从而对其他频段的通信造成干扰，因此载波的幅度变化应该尽量平缓，尽可能避免这种high slop transition现象。 !image.png 比较合理的做法就是在载波幅度过零点的位置进行相位变换，这样的话，在基带信号的0和1发生变换时，载波的幅度就不会发生跳变从而导致高频能量的散射。 !image.png QPSK: Quadrature Phase Shift Keying 在BPSK的调制中，每一组载波传输一个bit的基带数据，而QPSK则可以通过一组载波传输两个bit的数据。因此对于QPSK调制模式下的每一组载波而言，也就可以对应传输以下四组基带信息之一：00，01，10，11。每一组对应于载波的不同相位，各组载波相位的差异是90度：45度，135度，225度，315度。 !image.png QPSK相比BPSK最大的好处，当然就是更高的传输速率：如果保持载波和基带信号的频率不变，因为QPSK的一组载波比BPSK的一组载波携带的基带数据量增大了一倍，那么在相同条件下也就意味着其实际上的数据传输速率提高了一倍。而其代价则是，QPSK系统的复杂性更高。 QPSK的high slop transition问题 从上图可以看到，在45度和135度这两组载波切换时载波的幅度不会发生跳变，但是在后面的135到225度这两组载波切换的时候，明显的会发生载波幅度的跳变问题，也就是上面所说的high slop transition的问题，这个问题没法简单的使用BPSK在过零点进行切换的策略来解决（因为QPSK的相位差是90度而不是180度），所以就需要有其他办法来应对这个问题。解决这个问题的办法之一就是采用Offset QPSK, π/4-QPSK，或者类似MSK/MFSK的做法，基本的逻辑都是在两组连续的载波之间增减一定的延迟时间来尽可能避免载波的幅度发生过大的跳变。 DQPSK: Differential QPSK PSK在解调端存在的问题是，其解调判断的难度相比FSK要大。对于FSK的解调而言，只需要测量载波的频率就能知道其调制的基带信息是0还是1，但是对于PSK而言，0和1的差异存在于初始相位中，那么如果调制端和解调端的初始相位不同步或者是稍有差异，都可能会影响PSK解调的判断。为了应对调制端和解调端载波相位可能不同步所存在的问题，DQPSK也就是差分QPSK应运而生。 对于PSK的解调而言，接收端在接收到射频信号以后，接收端端解调用的载波和发送端进行PSK调制所使用的载波必须要严格的同频同相位，才能成功正确的解调出来载波上承载的基带信号，如果两端的载波相位有差异的话，解调就会出现误判的情况。因此，PSK的解调依赖的是对接收信号的绝对相位进行的判断。 而如果采用DQPSK进行调制和解调的话，就不再依赖于对绝对相位的判断，因此只要保证发送信号的调制端载波和接收信号的解调端载波的频率一致即可，不需要两端的载波相同相位。DQPSK对于每一组载波的解调依赖的不是对其绝对相位进行判断，而是依赖于这一组载波与上一组载波在相位上的差异和变化（这就是Differential的由来）。也就是说，每一组载波上携带的基带信息，取决于这一组载波跟前一组载波相位的差异，例如如果两组载波相位没有差异，表示当前这组载波携带的基带数据是0b00，如果前后两组的相位差异是90度，则当前这组载波的基带数据是0b01，以此类推。按照这种方式进行调制和解调，就可以解决DPSK要求调制和解调载波严格同频同相位的问题。 !image.png 参考资料 - Digital Phase Modulation: BPSK, QPSK, DQPSK | Radio Frequency Modulation | Electronics Textbook
无线数字通信之IQ调制工作原理
IQ调制是BPSK、QPSK、QAM16，QAM64、QAM256等在LTE和WiFi领域应用非常广泛的各种高阶调制方式的基础，理解了IQ调制的工作原理，才能够更好的理解LTE以及WiFi底层的OFDM实现机制。因为在OFDM的各个子载波上，最后采用的调制方式仍然是基于IQ调制的各种QAM调制技术，而且本质上，OFDM的实现就是在多路相互正交的子载波上进行的IQ调制的叠加。 IQ调制中的I和Q与IQ调制解调的基本工作原理 IQ调制概念中的I和Q分别对应于两个英文单词的缩写：In-Phase（同相）和Quadrature（正交）。单纯从字面意义上看的话，I和Q两个信号的命名没有任何意义，什么是同相？什么是正交？以什么信号作为参考来判断同相和正交？在具体的实现上，一般是使用一组同频的余弦和正弦波作为I信号和Q信号，那么作为I信号的余弦信号实际上就是参考信号，其本身当然就是同相（In-Phase）信号，而与其同频相差90度的余弦信号自然就是它的正交（Quadrature）信号。所以对于IQ调制信号的理解，最简单的就是可以认为I信号就是余弦载波信号，Q信号则是与I信号同频相差90度的正弦载波信号。 而所谓的IQ调制，就是使用一组同频率的I信号即余弦信号和Q信号即正弦信号（相位相差90度，相互正交）作为载波，向两个载波同时调制两路基带信号，然后把调制后生成的两路信号叠加在一起通过RF电路发射出去。接收端接收到射频信号以后执行IQ解调，在IQ解调的执行过程中，因为两路载波之间是相互正交的，也就可以基于之前调制过程中使用的I和Q载波信号分别把两路基带信号从混合信号中分离出来，单独执行解调。这就是IQ调制和解调的基本工作原理。 下图是IQ调制的基本工作原理。 !ee99c85f-ade9-42ba-ae2b-a824ca2db813.png - 进行IQ调制之前，基带的数字序列信号被按顺序分为两路独立的基带调制信号：I基带信号和Q基带信号。然后I基带和Q基带分别送入I载波信号（余弦）和Q载波信号（正弦）进行调制，再把两路调制信号通过加法器叠加在一起生成IQ调制后的信号，通过RF模块和天线发射出去。 下图是IQ解调的基本工作原理。 !29c82b40-f4af-4083-ab19-f3acf7b1b74c.png - 接受端的天线和RF电路接收到射频信号后，把这个射频信号分别基于与调制信号相同的I信号和Q信号分别执行解调，恢复出来独立的I基带信号和Q基带信号。 I信号与Q信号的叠加 IQ调制的关键就在于对I信号和Q信号进行叠加所产生的幅度和相位上变化的效果。 例如下图是相同幅度的I信号和Q信号的叠加结果：桔色为余弦I信号，蓝色为正弦Q信号，两者幅度相同，叠加所生成的就是图中的红色信号。 !image.png 可以看到，相同幅度的I信号和Q信号叠加所生成信号的相位在I信号和Q信号之间，相对于I信号而言相位是45度。 而如果调高或者调低I信号和Q信号的幅度，则不光会改变调制生成信号的幅度，而且还会相应的改变调制生成信号的相位。 例如在下图中，把I信号（桔色）的幅度设置为2，Q信号（蓝色）的幅度仍然保持为1，那么I信号和Q信号两个信号叠加所产生的调制信号（红色）的幅度稍大于I信号，相位也会向I信号的方向偏移。 !image.png 另一方面，如果把I信号（桔色）的幅度保持为1，Q信号（蓝色）的幅度增大到为2，那么两者叠加所产生的IQ调制信号（红色）的幅度稍大于Q信号，相位则向Q信号靠拢。 !image.png 因此结论就是，对于IQ调制的I信号和Q信号的双方而言，提高一方的相对幅度大小，不光会提升调制信号的幅度，而且会导致调制信号的相位向幅度增大的一方偏移。所以本质上，IQ调制分别是在I信号和Q信号上进行的幅度调制，但是调制的结果不光会影响调制生成信号的幅度，还会影响其相位的变化。 但是，以上图片中I信号和Q信号的幅度无论如何变化和组合，其叠加后生成的IQ调制信号的相位肯定是在I信号的0度和Q信号的90度之间变化，如何实现调制信号的相位在0度到360度之间变化呢？例如QPSK，QAM16以及更高阶的QAM调制的相位都是在0-360之间变化的。 以QPSK解释IQ调制的相位变化 所谓的QPSK，是指一次调制可以完成两个bit基带信息在载波信息上的传输，两个bit的四种组合（00，01，10，11）分别对应于相位调制的45度，135度，225度和315度。 下图是一个QPSK调制器的框图： !image.png - 首先基带信号的数字序列以两个bit为单位进行划分，每次向QPSK调制器送入两个bit的信息，1个bit调制到I信号上，另外1个bit信号调制到Q信号上。上图的Local Oscillator所产生的载波信号就是I载波信号，把I载波信号经过90度相位偏移处理后就是Q信号，作为两个bit的基带信号的调制信号。 - 两个基带bit信号分别通过乘法器调制到其对应的载波信号以后（本质上就是两路独立的幅度调制处理），再把两路载波信号进行叠加处理，所生成的就是QPSK调制信号，通过RF和天线发射出去。 在进行以上QPSK调制的过程中，本质上就是在I路和Q路分别进行幅度调制处理。在这个幅度调制处理的过程中，如果限制基带信号只能为0和正数的话，这个幅度调制实际上就成了OOK，那么I路和Q路叠加的相位偏移量就只能在0-90度之间。而如果把基带的位序列映射处理，进行幅度调制时可以支持负数的话（所谓的负数，实际上就是把I信号和Q信号做180度反向处理而已），那么I路和Q路的幅度调制根据其正负关系就存在以下四种种情况。 I路和Q路都是正数幅度调制 跟前文所描述的逻辑相同，IQ调制生成信号的相位在0到90度之间变化。对于QPSK而言，对应的调制关系是I=1，Q=1，其相位为45度。 !image.png I路正数幅度调制，Q路负数幅度调制 这种情况下，I路的相位没有发生变化，Q路的相位发生了180度变化，由此导致的IQ调制生成信号的幅度在270度到360度之间变化。对于QPSK而言，对应的调制关系是I=1，Q=-1，其相位为315度。 !image.png I路负数数幅度调制，Q路正数幅度调制 这种情况下，I路的相位发生了180度变化，Q路的相位没有发生变化，由此导致的IQ调制生成信号的幅度在90度到180度之间变化。对于QPSK而言，对应的调制关系是I=-1，Q=1，其相位为135度。 !image.png I路负数数幅度调制，Q路负数幅度调制 这种情况下，I路和Q路的相位都发生了180度变化，由此导致的IQ调制生成信号的幅度在180度到270度之间变化。对于QPSK而言，对应的调制关系是I=-1，Q=-1，其相位为225度。 !image.png 因此对于QPSK也好，对于各种QAM也好，最后就是通过把基带的位序列映射为在I路和Q路上进行幅度调制的正数或者负数幅度，由此实现了360度的相位调制。 参考资料 - Understanding I/Q Signals and Quadrature Modulation | Radio Frequency Demodulation | Electronics Textbook - IQ调制为什么叫 I 和 Q？IQ调制是怎么工作的? IQ调制信号必须用IQ解调吗？IQ调制原理 - Digital Phase Modulation: BPSK, QPSK, DQPSK | Radio Frequency Modulation | Electronics Textbook - Understanding Quadrature Demodulation | Radio Frequency Demodulation | Electronics Textbook
双频WiFi和蓝牙之间的天线是如何复用的？
本篇笔记尝试更完整的理解和回答以下三个与射频天线复用相关的问题： - 所有WiFi和蓝牙芯片的射频模块都有收发数据的功能，那么其收发功能是如何通过一根天线来实现的？如何避免同时收发所造成的冲突？ - 部分2.4GHz WiFi+蓝牙的Combo模块，使用一根天线既可以用于WiFi，又可以用于蓝牙，那么WiFi和蓝牙如何共享同一根天线，并且不会产生？ - 双频WiFi支持2.4GHz和5GHz频段，部分模块可以支持2.4GHz和5GHz频段共用一根天线，但是2.4GHz和5GHz波段的波长差了一半多，如何保证一根天线在2.4GHz和5GHz频段都有比较好的射频性能？ WiFi/蓝牙天线的收发复用问题 其实在WiFi和蓝牙上使用一根天线收发根本就不成问题，因为WiFi和蓝牙的TX和RX通信本质上是半双工的，根本就不可能同时进行收发。也就是说，TX和RX打开的时间肯定是错开的，所以对于WiFi和蓝牙的收发天线复用而言，根本就不会存在冲突的问题。 对于BLE而言，其连接状态下的通信逻辑如下图所示： !1735192604742.png 每个connection event，总是从Central设备打开TX发送数据包，Peripheral设备打开RX等待接收数据包开始通信。Central设备发出数据包以后打开RX等待接收应答，而Peripheral设备在在收到Central的数据包以后，打开自己的TX发送应答数据包。 对于广播模式也是如此，Peripheral设备在广播信道总是先打开TX发出广播包，然后切换到RX等待接收Central设备所发出的连接请求包；而Central设备每次建立连接之前，也总是先到广播信道打开自己的RX监听广播包，收到Peripheral设备的广播包以后再切换到TX给其发出连接请求。 因此，对于Central设备和Peripheral设备而言，其数据包的收发总是严格按照时序错开，这样才能正常进行数据包的接收和发送。对于这两端设备的RF模块而言，肯定不存在TX和RX需要同时打开的情况。 WiFi也是类似，WiFi对于无线媒介使用的协商基于CSMA-CA的机制，当源站要发出数据包的时候，首先要通过RX对当前的无线信道进行监听，监听当前信道处于空闲状态下，再延迟一定的时间（SIFS/PIFS/DIFS），然后发出自己的数据包；而目的站在收到数据包以后，延迟一定的时间（SIFS）发出自己的应答包。在以上的源站和目的站发出数据包和应答包的时间内，当前的无线媒介就处于占用的状态（NAV）下。如果这个时候其他站有数据要收发，必须要等待一段时间后重新监听媒介，然后在争用窗口的时间内尝试打开TX发出自己的数据包。 !image.png 以上的这个过程中，每个站要打开TX向无线媒介发出数据包之前，都必须先打开RX监听无线媒介是否处于空闲的状态下，在确定无线媒介空闲的情况下才会打开自己的TX去发送数据。 实际上，每个站在打开TX发送数据包的过程中，它自己是没法知道此时是否有其他站在相同信道同时发送数据从而发生了无线射频冲突（这也是在无线通信中无法使用CSMA/CD，而必须采用CSMA/CA的原因所在），所以只能在每次发出一个数据包以后等待对端发回应答ACK才能确认本次通信是否成功。如果没有收到ACK就认为这个包丢失了需要重传。 按照以上工作逻辑，对于每个WiFi站而言，它的收发控制也都是错开的，即使要发送数据，也一定是先通过RX监听当前无线媒介没有冲突时才打开TX开始发送的。 总之，对于WiFi和蓝牙通信而言，其收发是不可能同时进行的，那自然就可以通过开关对TX/RX进行控制切换，在需要接收数据的时候打开RX，在需要发送数据的时候打开TX，两者不可能产生冲突。 实际上，对于所有的采用时分机制来进行收发双工通信的无线通信方式都是如此，收和发本质上是半双工的，不可能同时进行，也没有办法在发出信息的同时监听是否发生了无线信号的冲突和碰撞，所以只能依赖于对端发回的ACK来确认通信是否成功。 下面一个简化的无线收发器控制RX和TX切换的框图：RX接收无线信号走LNA通路，TX发送信号走PA通路。 !d7e8c264-ff53-4734-9528-bb744bbe6fd7.png 当无线收发器处在发射状态时，功率检波器会检测到无线收发器发出的信号，从而产生开关切换信号以控制RF开关打向发射PA通路，LNA电路被断开，双向功率放大器处在发射状态，此时TX的信号通过天线向外发射。当无线收发器处在接收状态时，功率检波器由于定向耦合器的单方向性而基本没有输入信号，这时通过开关切换信号将RF开关切换到LNA通路，PA通路断开，此时双向功率放大器处在接收状态，RX从天线接收射频信号送入LNA通路进行处理。 因此，从以上框图上可以看出，RX和TX总是处于自动切换的状态，需要发送数据时打开TX切换到PA通路，需要接收数据时切换到RX打开LNA通路，如此切换也就不存在收发同时的冲突问题。 参考资料： - 2.4G射频双向功放电路的设计与制作 - 设计测试 - 电子发烧友网 --- 2.4GHz频段WiFi与蓝牙之间的天线复用问题 部分WiFi+蓝牙Combo的模块，同时包含了WiFi和蓝牙功能，也自然分别包含了蓝牙和WiFi各自的射频电路，但是可以共用相同的2.4GHz天线。例如下图是高拓的2.4GHz单频WiFi6+蓝牙方案6461。问题是： - 蓝牙和WiFi同时通信的时候，如果两者都有数据要接收的话，天线接收的数据到底是给WiFi还是给蓝牙呢？ !1735199688313.png 蓝牙和2.4GHz WiFi共享一根天线和射频电路用于进行通信，需要依赖PTA或者EECI的机制。 PTA PTA（Packet Traffic Arbitration）是一种数据包流量仲裁机制，用于协调蓝牙和WiFi设备共享同一射频电路时的工作状态，以尽量减少两者在2.4GHz频段上的相互干扰。 802.15.2规范中定义了蓝牙和WiFi共享天线的情况下，双方进行数据包流量仲裁的框架。在该框架定义中，WiFi和蓝牙对于RF以及天线的使用通过一个仲裁器来进行管理，当两者需要使用RF的时候，分别通过PIN脚向仲裁器提出申请，由仲裁器来决定由哪一方来使用RF和天线。因此在这种WiFi和蓝牙共存的情况下，其无线通信的效率和稳定性等表现就取决于仲裁器的实现方式、运行逻辑以及从两端可以获取的信息。 PTA的具体实现上，一般是把PTA仲裁器模块放在WiFi芯片内部，WiFi芯片和蓝牙芯片通过专门的PTA引脚来交换当前的状态并发起申请。802.15.2建议使用三线制的PTA通信结构，但具体实现上也有二线和四线的方式。 以下是WiFi和蓝牙芯片之间共享RF和天线的典型PTA连接示意图。PTA连接采用标准的三线制：BT_PRIORITY_AND_STATUS，BT_ACTIVITY，WLAN_ACTIVITY。 !image.png - WLAN_ACTIVITY：也称为GRANT引脚，由WiFi芯片向蓝牙发出信号。当WiFi不需要使用RF和天线的时候，可以通过这个引脚通知蓝牙芯片，蓝牙芯片此时就可以向PTA仲裁器发起申请使用天线进行蓝牙数据收发。 - BT_ACTIVITY：也称为REQUEST引脚，由蓝牙芯片向PTA仲裁器发出请求信号。当蓝牙有数据要收发时，通过这个引脚向PTA仲裁器主动发起请求申请使用天线，PTA仲裁器收到请求以后根据自身内部的控制逻辑决定应该由蓝牙还是WiFi来使用天线。 - BT_PRIORITY_AND_STATUS：也称为PRIORITY引脚，由蓝牙芯片发出信号表示当前蓝牙要收发的数据是高优先级还是低优先级。与REQUEST引脚配合使用，通过该引脚表征蓝牙芯片要收发数据的优先级，PTA仲裁器依据这个优先级决定天线使用的归属逻辑。 所以本质上，PTA机制就是在wifi芯片内置一个PTA仲裁器，WiFi芯片和蓝牙芯片通过Grant、Request以及Priority引脚来通知和协商各自对于2.4G RF和天线的使用需求，然后最终由PTA仲裁器来决定天线使用的归属权，这样就可以避免WiFi和蓝牙同时使用天线所可能造成的无线冲突的问题。 PTA最大的问题是三个引脚通过高低电平来传递信息，所能够携带的信息量太少了，只包含了请求、状态、数据优先级等少量的信息，这些信息对于PTA仲裁器做出高效的判决是远远不够的，所以为了在两者之间分享更多的信息来辅助PTA仲裁器实现更高效率的天线控制，可以采用ECI或者SECI机制。 SECI SECI就是串行增强型共存接口（Serial Enhanced Coexistence Interface），实际上是Cypress定义的一种基于串口UART通信的2.4GHz射频与天线的共存协商接口和协议，广泛应用于Cypress的WiFi和蓝牙产品中。 在具体的应用中，SECI采用串口UART在蓝牙和wifi芯片之间传输仲裁所需要的信息，最多可以通过串口交换64bit的信息，远远超过了PTA机制下的三线通信所提供的3bit信息。因此可以辅助做出更高效的RF与天线在两者之间复用的决策。 - 当然因为SECI是Cypress定义的私有协议，所以对于要采用SECI在WiFi和蓝牙之间共享天线的情况下，最好是能够同时采用Cypress的wifi和蓝牙芯片。 !image.png 总而言之，无论是PTA也好，SECI也好，本质上都是一种在蓝牙和WiFi之间对于RF和天线共存的分时使用机制。WiFi和蓝牙通过某种通信机制交换双方的状态信息、通信需求、数据优先级、时序等方面的信息，由仲裁器决定应该由哪一方使用天线。因此无论如何，在一个时间点上肯定是只有一方能够使用天线。这样势必会造成对于两方通信实时性和吞吐率的影响，只不过在仲裁器的协助下，可以最大程度上降低通信过程中产生无线冲突的概率。 WiFi+BT Combo 以上所讨论的PTA以及SECI机制，都是针对在独立的WiFi芯片和独立的蓝牙芯片之间共享同一个天线进行通信，而如果要提升通信效率，更好的做法实际上上选择把WiFi和蓝牙内包在一起的Combo模块，在这种情况下，蓝牙和wifi在同一个芯片内部，其状态信息可以得到充分共享，不需要依赖于外部的PTA和SECI接口，这样对于RF和天线资源在两者之间调度就可以做得更高效。实际上这种方式才是目前在应用方向上的主流，不少wifi芯片直接就已经内包了蓝牙功能，不需要通过外部接口来进行天线使用上的协商，直接在芯片内部处理好了，例如高拓的6461内包了WiFi和蓝牙，因此直接在芯片内部对于wifi和蓝牙共享天线做好了支持，这样的方式就比外部PTA和SECI连接效率高很多： !1735810160250.png 结论 对于2.4GHz频段的WiFi与蓝牙之间共享一根天线进行数据收发的情况，存在多个方案，PTA，ECI，SECI以及Combo Module，但是其本质上都是大同小异。两者对于天线的共享都要依赖于其中包含的仲裁器，wifi和蓝牙需要使用天线的时候向仲裁器申请，仲裁器根据双方数据通信的优先级进行分配，同一时刻肯定是只有WiFi或者蓝牙的一方具有天线的使用权。 因此，仲裁器的存在，以及WiFi和蓝牙对于天线使用权的竞争，多少会影响各自数据通信的吞吐率，影响的大小就要取决于仲裁器的运行逻辑。 参考资料 - [蓝牙系列] WiFi 与BT 共存机制 - 知乎 - PTA是什么？BT-WIFI共存_wifi pta-CSDN博客 - Overview of SECI - Infineon Developer Community --- 2.4G/5GHz双频WiFi的天线复用问题 目前的双频WiFi模块，能够支持2.4GHz和5GHz频段的WiFi通信，在该模块的电路设计中，同样存在两个WiFi频段的天线复用问题，即2.4GHz和5GHz频段的射频电路使用同一个天线，通过开关对天线的使用进行匹配。例如高拓的双频WiFi 6132： !1735199172251.png 那么问题是： - 复用逻辑问题：与以上的蓝牙和2.4GHz WiFi复用天线的问题类似。WiFi 2.4GHz和5GHz频段在使用的时候，如果两个频段同时有数据发送的话，可以把数据先缓存在buffer中，然后通过开关切换依次把各自buffer中的发送出去，但是对于接收而言，两个频段如果同时有数据要接收的话，天线切换到2.4GHz的时候，5GHz频段的数据肯定就丢包了。这个问题是如何处理的？ - 复用性能问题：2.4GHz和5GHz的天线性能问题。天线的长度与波长相关，2.4GHz和5GHz的频率差了一倍多，那么能够发挥出来最佳RF性能的天线长度也应该差一半。如果复用一条天线的话，如何能够保证在两个频段都有最好的RF性能呢？ 复用逻辑问题 对于双频wifi的天线复用问题，逻辑上其实跟WiFi与蓝牙之间复用天线的情况一致：无论如何复用，最后都是通过时分的机制来实现的，同一时刻，要么是2.4GHz频段在使用WiFi天线，要么是5GHz频段在使用WiFi频段。 正如上面高拓6132框图所示，双频WiFi的5G和2.4G两个频段有各自的RF处理电路，通过SPDT开关进行切换，同一时刻只能有一个频段在使用WiFi。 既然是分时的天线复用逻辑，那么就势必会对各个频段通信的吞吐率造成一定的影响。以最简单的等比分时复用的逻辑对SPDT开关进行切换，那么对于2.4GHz和5GHz频段而言，都只有一半的时间可以拥有天线的使用权，当然会对各个频段使用的通信吞吐率造成显著的影响。尤其是对于射频的接收而言，如果在接收信号到达天线端但是SPDT开关未能切换到与之匹配的工作频段时，这个数据包肯定就丢包了，接下来只能在开关切换过来以后通过重传来解决问题。所以这样的频繁切换对于射频收发吞吐率的影响是无法避免的。 因为分时复用对于RF吞吐率会有明显的影响，那么如果产品应用中如果对于通信的速率有较高的要求，就需要考虑2.4GHz和5GHz分时复用天线可能造成的影响。这一点应该也是大多数路由器在天线设计中把2.4G天线和5G天线分开的原因所在，这样的话，独立的2.4G天线和5G天线固定的与其匹配的RF电路配合提供相应频段下的网络服务，这样就不需要在两个频段下频繁切换了。例如下图是小米一款路由器的拆解图，可以看到2.4G和5G天线明确的分成了两组。 !1736325410377.jpg 另外很重要的一点是，对于物联网以STA方式使用双频WiFi的应用而言，双频WiFi一般只是会处于二选一的状态，这样的话就不存在复用逻辑问题了。例如在IP Camera产品中使用双频WiFi，在进行配网的时候会选择以2.4GHz或者5GHz接入路由器，选择后以后每次与路由器之间的连接就只是固定的使用2.4GHz或者5GHz其中之一来工作，所以SPDT开关就会按照WiFi驱动配置设置的频段固定的切换到2.4GHz或者5GHz，根本就不需要在工作中频繁切换，那自然就没有复用逻辑的问题了。 复用性能问题 双频天线复用的性能问题，实际上就是天线的多频设计问题。经过多频设计的天线可以在单根天线上支持多个频段的通信。 - 天线多频设计的问题在手机LTE所支持的多模式上更为突出，因为LTE支持运行在多个不同频段的BAND上，而现在的手机基本上都是支持所有BAND的全网通，其内部天线的设计就需要能够兼容支持不同的频段，因此相较于双频WiFi的2.4GHz和5GHz的多频段支持要更加复杂。 如何设计天线，让这个天线能够支持多个频段，并且在各个频段上的工作性能都达到标准要求，这就是天线多频设计所关注的主要问题。 目前在单个天线上可以同时支持多个频段无线通信的天线设计方法主要有谐振分枝法、倍频设计法、寄生分枝法等。参考文档1针对这个主题提供了非常好的总结，以下基于其内容进行简单的总结。 谐振分枝法 谐振分枝法就是针对这个天线要支持的频段，每个频段有一个相互独立的辐射分枝。因为各个频段的分枝是独立的，所以其谐振频点的调试就不会对其他的频段产生影响，调试起来更简单。 例如下图就是一个标准的双频WiFi的天线设计图。其中尺寸较长的分支（L1+H）对应的是2.4GHz频段的偶极子天线，尺寸较短的分支（L2）是5GHz频段的偶极子天线。两个天线相互独立，可以根据其要支持的频段独立的调试长度。 !image.png 下图是以上天线在频谱上进行仿真运算的示意图，可以看到在2.45GHz和5.5GHz频点上具有良好的阻抗和带宽特性。 !1736320417245.png 对于谐振分枝法所设置的多频天线而言，用于两个频段时效果较为理想，当谐振分枝超过3个时，各个分枝之间的互扰就会变大，从而导致各个频段的性能均变差，因此这种方法比较适合类似双频WiFi这样的双频段应用。 倍频设计法 从电磁波的基本理论得知，当RF信号在天线的基波频段产生谐振时，同时会在其奇次谐波，例如3倍、5倍、7倍…基波频段同样产生谐振，而在其偶数倍基波频段因为抵消效应不会产生谐振。例如下图是在一个900MHz的标准偶极子天线上模拟出来的各次谐波谐振的示意图。那么就可以利用这个奇次谐波谐振的特性来设计使用一根天线用以支持多个不同频段，这就是倍频设计法的工作原理。 !1736315619425.png 上图中演示的效果是标准的奇次谐波谐振的情况，但是我们在产品应用中遇到的绝大多数情况，多个频段不太可能刚好是奇次谐波的关系。针对这种情况，可以在天线的设计上做一下特殊处理，例如PCB天线对天线的走线做一些弯折处理、调整弹簧天线的螺距线圈半径等参数，就可以做到保持低频的基波频率不发生变化，并且把高频次谐波的频点调节到自己期望的频点上。 寄生分枝法 还有一种多频天线的设计方法是寄生分枝法。大致的工作原理是在天线设计的原生分枝旁边增加一个寄生分枝，RF电路的能量从原生分枝的馈线端接入，而寄生分支与原生分枝之间的距离很近，因此两个天线分枝之间会产生耦合效应，相当于在两个分枝之间增加了一个寄生电容，原生分枝馈线端的辐射能量通过这个寄生电容耦合到寄生分枝辐射出去。寄生分枝根据自己的结构和尺寸设计有对应的谐振频点，从而产生了独立于原生分枝的辐射频点。 !1736324008946.png 寄生分枝除了可以像上图一样添加在原生分枝的馈电端口附近以外，也可以增加在原生分枝的末端： !1736325799292.png 甚至可以像下图一样以直接耦合的方式增加寄生分枝： !1736325904265.png 对于在单个天线上要支持多个不同频段的RF通信，大致就是以上三种多频天线设计方法的排列组合，首先确认自己的产品应用要支持的频段，然后针对性的选择合适的多频天线的设计方案并进行组合、仿真，基本上就可以到达预期的设计目的。例如下图就是一个综和利用了多种多频天线设计技术的天线设计图： !1736326204789.png 参考资料 - 用HFFS实例讲解多频天线设计-CSDN博客
WiFi不同制式下最大速率的计算
以下对各种OFDM调制模式下的WiFi标准能够支持的最大通信速率理论值进行计算和整理。 WiFi速率的计算公式 !image.png - T(DFT)是OFDM子载波调制的一个symbol的时长。T(GI)是连续Symbol之间增加的保护间隔，用于保护连续symbol之间造成相互干扰。因此T(DFT)+T(GI)是各个子载波上所实际发送的symbol的周期。 - N(SS)是空间波数据，简单地说就是通信中能够支持同时用几根天线发送不同的数据。与MIMO的支持有关。 - N(SD, U)是指OFDM调制的子载波数量，仅包含用于进行数据传输的子载波数量，不包含各种信道保护子载波。与各个不同wifi制式定义的子载波间隔以及能够支持的信道频宽（20/40/80/160MHz）有关。 - N(BPSCS, U)是指每个symbol能够传输的位数，例如QAM16一个symbol可传输4bit数据，QAM256一个symbol可以传输8bit数据。 - R是指编码率，也就是通过信道发出的有效数据和实际数据（其中还包含了一些纠错码等）的比例。例如编码率3/4表示每发送4bit数据，其中有3bit是实际的有效数据，1bit是纠错数据。 802.11a/g 802.11g采用OFDM。在802.11g模式下只支持2.4GHz的20MHz频宽的信道，其OFDM共包含52个子载波信道，其中48个被用于进行数据传输。 802.11g制式下T(DFT)也就是symbol长度是3.2us，symbol保护间隔T(GI)是0.8us。 802.11g能够支持的速率类型包括： !image.png 那么以802.11g最高的QAM64调制模式为例来进行计算，每个symbol能够包含的数据位数是6bit，编码率是3/4，天线数量1根，其能够支持的最高速率就是(48个子载波 6bit 3/4 * 1根天线)/(3.2us+0.8us)=54Mbps. 802.11n 802.11n采用OFDM，开始支持MIMO，最高可以支持4T4R（4个空间流），即可以支持4根天线向外发出数据。 除了默认的一个信道20MHz频宽以外，802.11n也开始支持40MHz的频宽，并且在20MHz和40MHz频宽的情况下均可支持0.8us和0.4us保护间隔。 - 20MHz频宽下，子载波数量由之前的52个提升到56个，其中52个子载波信道可用于传输数据。 - 40MHz频宽下，共包含114个子载波信道，其中108个子载波信道可用于传输数据。 !1735114283629.png 在单根天线（1x1单空间流）的情况下，采用MCS7，调制模式采用QAM64，每个OFDM Symbol可以携带6bit数据，传输编码率为5/6： - 20MHz频宽+保护间隔为0.8us的最大速率：（52个子载波6bit5/6*1根天线）/(3.2us+0.8us)=65Mbps - 20MHz频宽+保护间隔为0.4us的最大速率：（52个子载波6bit5/6*1根天线）/(3.2us+0.4us)=72.2Mbps - 40MHz频宽+保护间隔为0.8us的最大速率：（108个子载波6bit5/6*1根天线）/(3.2us+0.8us)=135Mbps - 40MHz频宽+保护间隔为0.4us的最大速率：（108个子载波6bit5/6*1根天线）/(3.2us+0.4us)=150Mbps 因此单条流的情况下，802.11n最高可以达到的数据传输速率是150Mbps。 !1735114937730.png 以802.11n所能支持最大的4T4R（即MCS31）情况下，调制模式为QAM64，一个OFDM Symbol可传输6bit数据，传输编码率为5/6， - 40MHz频宽+保护间隔为0.4us可达到的最大速率：（108个子载波6bit5/6*4根天线）/(3.2us+0.4us)=600Mbps. 因此在802.11n所能支持的最大四个空间流的情况下，802.11n能达到的最大数据传输速率是600Mbps。 802.11ac 802.11ac也就是WiFi5，相比于WiFi4也就是802.11n而言最大的变化是： - MIMO方面从WiFi4的4T4R提升到最高8T8R。 - 调试方式从WiFi4的最大QAM64提升到QAM256，每个OFDM Symbol可以传输8bit数据。 - 信道频宽从WiFi4支持的20/40MHz提升到20/40/80/160MHz频宽，最高可以在5G频段支持单信道160MHz的频宽。 - 20MHz频宽的情况下，子载波数量56个，其中52个可用于传输数据。 - 40MHz频宽的情况下，子载波数据114个，其中108个可用于传输数据。 - 80MHz频宽的情况下，子载波数据242个，其中234个可用于传输数据。 - 160MHz频宽的情况下，子载波数据484个，其中468个可用于传输数据。 !1735115611007.png 单条流的情况下，最高支持QAM256调制方式，一个symbol可容纳8bit数据，在160MHz信道频宽+保护间隔400us的情况下可达到的最大传输速率是：（468个子载波8bit5/6*1根天线）/(3.2us+0.4us)=866Mbps。 !image.png 类似的，计算802.11ac所能支持的最大8个空间流的情况下，所能达到的最大传输速率为：（468个子载波8bit5/6*8根天线）/(3.2us+0.4us)=6928Mbps。 802.11ax 802.11ax也就是所谓的WiFi6。 802.11ax的OFDM Symbol的周期与前面几代有了很大的差异： - 从802.11g一直到802.11ac，其OFDM的symbol周期都是3.2us，保护间隔是0.4/0.8us，子载波间隔是312.5KHz。 - 但是到了802.11ax，OFDM的symbol周期变成了12.8us，保护间隔是0.8/1.6/3.2us，子载波间隔是78.125KHz。 因为子载波间隔发生了变化，也就影响了不同信道频宽模式下的子载波数量： - HT20模式下有234个子载波可被实际用于传输数据。 - HT40模式下有468个子载波可被实际用于传输数据。 - HT80模式下有980个子载波可被实际用于传输数据。 - HT160模式下有1960个子载波可被实际用于传输数据。 此外，802.11ax能够支持的最大调制模式也从QAM256提升到了QAM1024，一个symbol可以容纳10bit数据。 !1735120986990.png MCS11在一条空间流的情况下，采用QAM1024调制方式，一个symbol最高带10bit数据，编码率5/6，在160MHz频宽，以及采用0.8us的情况下可以达到的最大单路流的传输速率是：（1960个子载波10bit5/6*1根天线）/(12.8us+0.8us)=1200.98Mbps。 !1735121257522.png 同样的道理，在802.11ax能够支持的最大8条空间流的情况下，计算其能够支持的最大数据传输速率就是：（1960个子载波10bit5/6*8根天线）/(12.8us+0.8us)=9607.843Mbps 参考资料 - 802.11gnacax理论速度计算 - 百度文库 - 802.11 WiFi 由浅入深系列文章[10]-理论速率 - 知乎 - 802.11a/b/g/n/ac速率表 - OpenWrt开发者之家 - 【Wi-Fi】802.11/802.11b/802.11g/802.11n/802.11a/802.11ac/802.11ax/802.11be_wifi速率对照表-CSDN博客
蓝牙BLE通信的安全模式和安全级别总结
BLE安全模式的定义：在蓝牙规范所定义的应用场景中，是指产品使用蓝牙BLE通信的时候，对于其通信过程中安全性的具体要求和相对应的工作流程、解决方案对策。不同的安全级别对应了不同的工作流程，也对应了不同的保护级别，用户可以根据产品对于安全性保护的需求以及产品本身的特性/IO能力等选择合适的安全级别。 基于对通信中安全性的具体要求，BLE在产品中的使用流程主要共有三种安全模式：LE Security Mode 1， Mode 2，Mode 3。每个安全模式下又包含有不同的安全级别。 这三个Security Mode之中，最常用的还是Mode 1的几个级别。 值得注意的是，对于安全模式以及安全级别的选择，与产品的具体应用场景、产品本身所具备的IO能力以及对于数据的保护程度和要求息息相关，并不一定是安全级别越高就越好。 Security Mode 1 Mode 1主要用于决定两个BLE设备之间配对的安全需求和执行流程，通过配对流程来对蓝牙设备使用的安全级别进行控制。Mode1是最常用的一种安全模式。 有关BLE设备之间的配对流程，我在其他的笔记中有非常详细的总结。 - BLE设备配对模式和流程详细解析（一） - BLE设备配对模式和流程详细解析（二） - BLE设备配对模式和流程详细解析（三） 对BLE配对流程及其连接状态下的通信密钥有清楚的认识，才能完整的理解各种不同的安全模式和安全级别。 以下解释Mode 1中所包含的不同安全级别。 Mode 1 Level 1: 无安全特性 Level 1没有任何安全特性，进行BLE通信的两个设备之间既不需要进行设备硬件身份的认证，通信过程的所有数据也不需要进行任何加密处理。配对的流程会完整走一遍，但是基本上也就只是走一个过程而已，对于安全性方面没有明确的要求。 所有工作在这个级别下的BLE外设设备，可以被任意的BLE Central设备直接连接，并且两者之间的通信全部是明文，不做任何加密处理，也不对数据包的内容进行完整性和真实性的验证，数据包的内容可以被任何BLE Sniffer工具监听到和解析。 当然Level 1的好处则是提供了最好的用户设备访问的体验，连接通信的速度最快，相互连接和数据访问的整个流程不做任何限制，因此使用起来最方便。 因为没有任何安全性保护，比较适合那些对于通信数据没有任何安全性保护需求的应用场景，例如蓝牙温湿度传感器。 Mode 1 Level 2: 数据加密+无硬件身份认证 在Level 2级别中，两个BLE设备之间进行配对的过程中不进行硬件身份认证，但是会完成整个配对流程，并在配对流程的最后交换双方的数据通信加密密钥。双方通信连接建立以后，所有的通信数据都是通过AES算法+IRK所衍生的会话密钥进行加密的，即使BLE Sniffer进行监听数据包也无法解出明文。 实际上这个级别实际上就对应于配对流程中的Just Works模式，进行配对的设备既没有显示屏用于显示配对数字，也没有键盘用于输入配对数字，因此配对过程中用户无法参与进去，也就没有办法做很有效的设备身份认证。 该安全等级相比Level 1提高了一些，但是缺少了配对过程的硬件身份认证环节，无法满足对数据安全性要求很高的应用。但是该过程不需要人为参与，用户使用的体验更好更方便。 这个级别也是Just Works这个配对模式能够支持的最高安全级别。 Mode 1 Level 3: 数据加密+硬件身份认证 Lever 3级别的配对流程中，要求对进行配对双方的硬件身份进行认证，这个认证要么需要用户人为参与（Passkey Entry），要么通过蓝牙之外的带外传输（OOB），因此能够通过完整的配对流程，也就是相当于完成了相互之间硬件身份认证的确认。在配对过程中完成双方硬件身份确认后，才进行后续密钥的交换流程，因此安全性保护方面更为完整。 只不过Level 3默认使用的是LE Legacy Pairing这种相对较老的配对方式，安全性方面相对Level 4稍差。 Mode 1 Level 4: 数据加密+硬件身份认证+强制使用SC Level 4跟Level3类似，都是提供了数据加密和硬件身份认证的全面保护，但是Level 4在Level 3的基础上强制要求进行BLE配对的双方设备，在配对的流程中一定要使用更安全的LE Secure Connections配对流程和机制，不能使用之前的LE Legacy Pairing模式。这使得工作在Level4的设备安全等级相对更高，而且可以支持Numerical Comparison这种硬件身份认证的执行流程。 Security Mode 2 Mode 2主要针对的是BLE设备连接状态下双方进行通信的数据包签名机制的问题。 所谓的数据包签名机制，就是对于BLE连接的两个设备所发出的每个数据包，按照一定的算法对这个数据包的内容进行签名，把数据包的内容和签名一起发出，接收端按照相同的签名算法和密钥验证这个数据包数据内容的完整性（这个数据包的内容是完整的，没有被修改的）和通信身份的真实性（这个数据包确实是由自己信赖的通信对端所发出的）。 针对Mode 2和BLE通信中的数据签名，我的看法是：如果数据包已经通过双方所共享的密钥进行加密了，那么这个数据包就没有必要再做用户身份的数据签名确认了，因为只有持有相同密钥的通信对端才能正确解析。既然都已经能够成功解密出来数据包，那也就说明通信对端是自己信赖的通信方。所以对于BLE通信而言，Mode 2、数据签名、CSRK密钥应该都是针对通信数据包内容不需要加密、但是需要确认通信双方身份的应用场景。 数据签名的计算逻辑如下图所示，主要依赖于双方配对流程中所协商的CSRK密钥。 !1734933198600.png - 数据签名的运算逻辑在我的另外一篇笔记中有非常详细的解释： Mode 2包含有两个安全级别。 Mode 2 Level 1：无身份认证+数据签名 在这个级别中，两个BLE设备在配对流程中使用不需要用户人为介入的association model，最典型的就是Just Works。这种方式无法提供有效的策略去进行硬件设备的身份认证以及对抗中间人攻击，因此使用这种方式最好是在一个安全的环节中进行设备之间的配对流程操作。 对于该级别的支持，在两个设备的配对流程中一定要协商和共享CSRK密钥，因为后续的连接状态下的数据通信机制，需要依赖这个CSRK密钥对数据包进行签名和匹配比较。 这个级别存在的最大问题是，因为Just Works没法有效的验证对方的硬件身份，所有的Central设备都可以与当前的这个BLE外设设备完成配对，分享CSRK密钥以及在后续的通信中使用CSRK密钥对收发的数据包进行签名验证。如果当前的产品应用对于通信对端的硬件身份认证有要求，这个level 1就不合适了。 Mode 2 Level 2：身份认证+数据签名 在该级别中，进行配对的两个BLE设备需要在配对流程中使用能够支持硬件身份认证和防止中间人攻击的association model，实际上也就是OOB、Passkey Entry以及Numerical Comparison这三种之一。 当然对于这种级别，两个设备的配对流程同样需要共享CSRK密钥。这样的话，通过配对过程中完整的身份认证机制确认只有自己信任的硬件设备才能够与自己完成配对过程分享CSRK密钥，后续通信中再基于CSRK密钥+数据签名等机制就可以确保通信双方的连接是在双方所信任的硬件上进行的，提升了通信的安全性。 Security Mode 3 Mode 3专门用于针对BLE外设设备广播数据的加密保护需求。即是否需要对广播数据进行加密？对广播数据进行加密是在蓝牙规范v5.4版本中引入的新功能，也就是所谓的Encrypted Advertising Data (EAD) 。加密广播功能的实现依赖于一个在同一个广播组内共享的16字节Broadcast Code。 实际的使用中，因为EAD功能是在v5.4版本才新推出，而且一般只会在LE Audio这类同步数据流（Isochronous Streams）的应用中才会用到广播加密功能，所以这种安全模式的实际应用场景很少。 针对不同的需求，Mode 3包含有3个安全级别。 Mode 3 Level 1：无加密 在该安全级别下，这个BLE外设设备不对广播数据做任何加密处理，广播数据以明文形式发布，所有的Central设备都可以正常扫描并解析出来。安全性最差，但是可以提供最方便的用户使用体验。 无加密广播的工作模式是蓝牙规范5.4版本之前默认的数据广播模式。 Mode 3 Level 2：广播加密+Broadcast Code无认证 处于该安全级别下的BLE外设设备所发出的广播包都会使用Broadcast Code进行加密保护，只有持有相同Broadcast Code的Central设备才能对这些广播包进行正确的解析。因此安全性相比Level 1有所提升，但是对于设备加入同步数据流广播组BIG（Broadcast Isochronous Groups），并没有身份验证环节，所有的设备都可以加入BIG并获取Broadcast Code，所以安全性方面仍然存在欠缺。 Mode 3 Level 3：广播加密+Broadcast Code身份认证 在Level 2的基础上，对加入同步数据流广播组BIG的BLE设备进行身份认证，要求提供验证码才能获取Broadcast Code对广播包进行解码，否则就会报错。 参考资料 - Bluetooth LE: Security Modes and Procedures Explained - Technical Articles - Securing BLE Connections—An Overview of the Security Protocol - Technical Articles
BLE设备配对模式和流程详细解析
BLE设备的配对流程，主要就是在两个设备之间建立相互信任的配对和绑定关系，产生两者后续加密通信和身份认证的密钥，并安全的交换这些密钥用于后续连接模式下的加密通信。 整个BLE配对过程的细节非常繁琐，因此大致分为三篇笔记的篇幅对完整的配对和绑定的流程进行深入的解析，以建立对蓝牙安全性的更深入理解： 1. 对BLE设备之间进行配对和绑定的过程以及支持的配对模式进行简要总结，详细描述配对流程第一阶段的实现步骤； 2. 对BLE设备配对流程的第二阶段LE Legacy Pairing模式的执行流程进行详细解释和说明。 3. 对BLE设备配对流程的第二阶段LE Security Connections模式的执行流程，以及第三阶段对密钥的分发流程进行详细解释和说明。 BLE设备的配对和绑定流程简述 BLE配对流程的主要作用既然是产生和交换密钥，那就必须要保证整个密钥交换流程的安全性，否则被攻击者监听到，这个密钥也就泄露了。此外，BLE设备之间在进行配对之前还要进行必要的硬件设备身份确认，身份确认通过以后（确认正在执行配对流程的两个设备是合法而且正确的，避免错配）才能执行后续的配对流程。 与配对（Pairing）流程相关联的还有一个绑定流程（Bonding）。这两个概念是先后的关系，简单的总结就是配对流程是在两个BLE设备之间建立信任关系，产生和交换用户后续加密通信的密钥；而绑定流程则是把配对流程所产生的密钥保存起来，后续两个设备之间重新连接的时候就可以直接使用之前已经交换和保存好的密钥，这样加密连接的建立速度更快，用户使用体验更好。因此，一旦经过了配对+绑定的完整过程，下次两个设备重新连接的时候，就可以跳过重新进行新的密钥协商和传递的过程，直接使用之前绑定流程中在两端保存的密钥信息来对通信进行加密和保护。 - 实际上配置之后自动执行一个绑定流程安全性也更好，这样就不需要每次两个设备之间建立连接的时候，都执行完整的身份认证、密钥协商和交换的过程，密钥和其他敏感信息泄露的风险更小。 符合蓝牙4.2及其之后版本规范的BLE设备有两种配对流程可以选择：经典的LE Legacy Pairing，以及更加安全的LE Secure Connections。这两者的区别主要是后者的配对密钥生成和交换方法更加安全，以及后者可以支持更完整的配对模式（Association model）。 整个BLE配对流程从顺序上可以分为三个阶段，其中第一阶段和第三阶段对于LE Legacy Pairing和LE Secure Connections来讲是完全一样的，两者的区别主要就在第二阶段。而对于两个BLE设备在进行配对操作的时候究竟会选择LE Legacy Pairing还是LE Secure Connections，则依赖于其支持的蓝牙规范版本（4.2之前版本只能使用LE Legacy Pairing）以及配对特性交互环节所交换的SC（Secure Connections）选项：如果配对的两者都支持SC选项，那么就会走LE Secure Connections流程，只要有一方不支持SC选项就走LE Legacy Pairing流程。 !1734512982950.png 配对流程阶段一：双方配对特性/能力交换 整个BLE配对流程的执行包含两个角色：Initiator和Responder。而配对流程总是由Initiator发起，Initiator向Responder发出一个Pairing Request包，Reponder收到以后返回一个Pairing Response消息。这两个消息中包含了双方各自的能力和特性等信息。 !image.png - IO Cap：用于表示进行配对操作的双方具备的输入（例如键盘，按键等）或者输出（例如显示屏等）设备方面的能力，由此来决定后续执行配对操作可以采用的安全等级和密钥的产生方法。根据双方IO能力的不同，可以支持的IO选项包括：DisplayOnly, DisplayYesNo, KeyboardOnly, NoInputNoOutput和KeyboardDisplay。 - DisplayOnly：该设备只有一个显示屏可用于显示数字字符串，无法接受输入 - KeyboardOnly：该设备具备输入数字的能力 - DisplayYesNo：该设备既有一个显示屏可以显示数字，也可以允许用户以某种方式（例如确认按键）选择YES或者NO - NoInputNoOutput：该设备没有可供用户使用的输入输出能力（显示屏或者键盘/按键） - KeyboardDisplay：该设备既可以支持输入数字/字符串，又有显示屏显示字符串/数字 - OOB Data Flag：用于标记双方是否具备BLE通信之外的其他手段（也就是所谓的带外通信，out of band）可以协助进行这个配对操作和设备认证操作，例如NFC或者二维码。可选的选项只有两个：OOB Authentication Data Not Present和OOB Authentication Data from a Remote Device Present. - AuthReq（Authentication Requirements）：这个field用于定义该设备对于配对流程所需要的安全性认证的需求，每个bit表示一个需求：BF（Bonding Flags）, MITM (Man In The Middle Protection)， SC（Secure Connections）和KP（Keypress）。 - BF（Bonding Flags）：用于决定后续配对过程完成后是否需要把本次配对交换的密钥保存起来用于两者以后的连接通信，也就是绑定过程是否自动运行。 - SC（Secure Connections）：用于决定后续的配对流程的执行是走LE Legacy Pairing还是LE Secure Connections流程。 - MITM (Man In The Middle Protection)：用于标记本设备后续的配对过程要能够应对中间人攻击。 - Max Encryption Key Size：配对过程中加密Key的最大长度，取值范围为7-16个字节，会影响后续通信连接的加密强度。 - Initiator Key Distribution / Responder Key Distribution：对于Initiator和Responser而言，可以支持分发的密钥类型。在配对过程中需要在两个设备之间交换和分发的密钥包括以下三个： Long Term Key (LTK)，Identity Resolving Key (IRK)和Connection Signature Resolving Key (CSRK)。这个设置表示在配对过程中这些密钥应该由哪一端分发。 在进行配对的两个BLE设备之间交换Pairing Request包和Pairing Response包以后，双方就都了解了本次配对的IO交互能力以及对于配对的安全性需求等方面的信息，下一步就是决定具体的配对流程执行的模式，也就是所谓的Association Model。 配对流程Association Model的协商 具体的Paring执行的流程，依据于配对双方所具备的IO能力以及对于配对安全性的具体需求，可以分为以下几种Association Model： - JW（Just Works）：安全性最低的配对流程操作方式，适用于两个设备都没有合理的手段去显示配对数字以及确认配对过程的执行。完全依赖于两个设备之间的通信，不需要用户参与配对操作的交互流程，这种配对方式无法应对中间人攻击MITM。 - PKE（Passkey Entry）：至少需要一个设备具备显示屏，另外一个设备具备输入能力。配对流程中，设备A显示一个数字，然后在设备B上输入这个数字后进行设备配对关系验证。因为它需要用户在这个流程中参与物理交互，因此有助于防止MITM攻击。 - 对于LE Secure Connections模式下，也可以是两个设备都没有显示屏，但是都有键盘，此时两个设备都通过键盘输入一个相同的数字。 - NC（Numeric Comparison，数字比较）：适合于两个设备都有显示屏用以显示匹配数字的内容，以及有手段确认两端显示的一致性（例如确认按键）。配对过程中用户通过比较两个设备上显示的数字是否一致来保证配对流程的安全执行。与PKE一样，需要用户参与配对过程的验证环节，可以有效应对中间人攻击。 - NC模式只在LE Secure Connections模式中存在，在LE Legacy Pairing模式中不存在。 - OOB（Out of Band，带外通信）：适合于两个设备都有蓝牙之外的带外通信能力。如果配对的双方都具备除蓝牙以外的另外一种带外通信能力的话，可以通过这种蓝牙通信之外的通信方式来交换安全性信息。 LE Legacy Pairing可以支持JW，PKE和OOB这三种association model，而LE Secure Connections则可以支持以上所有的四种association model。 下一步就是根据BLE设备之间交换Pairing Request包和Pairing Response包中所包含的配对设备IO能力，以及对于配对安全性的需求（SC，MITM等），就可以按照下面的逻辑来选择合适的配对模型。 !image.png - 首先检查两个设备的SC（Secure Connections）标注，如果两个设备都设置了这个标志，后续的配对流程就走LE Secure Connections；只要有一方没有设置这个标志，就走LE Legacy Pairing流程。无论是走哪个流程，接下来就是选择合适的association model。 - 接下来检查两个设备的OOB（Out of Band）标志，如果两个设备都通过这个标志表示具备除蓝牙之外的其他带外通信能力，则使用OOB association model。只要有一方不具备OOB标志，就没法使用OOB，接下来判断MITM标志的设置情况。 - 如果两个设置都没有设置MITM (Man In The Middle Protection)标志，后续的配对流程就会选择JW association model，这种情况下的配对流程无法应对中间人攻击。而如果有一方或者两方都设置了MITM标志，则接下来根据两端具备的IO能力来选择合适的association model以应对MITM攻击。 - 接下来就是要分析两端所具备的IO能力：是否有显示屏可以用于显示数字？是否有键盘可以用于输入数字和字符？具体如何选择按照两者所具备的IO能力进行选择。 !image.png 至此，蓝牙配对的第一阶段就结束了，这个阶段主要就是通过双方明文交互的Pairing Request和Pairing Response消息来确定配对的流程、需求以及Association Model。 接下来就要进入第二阶段，主要是进行双方硬件的身份认证，然后建立加密链接以方便在第三阶段传输密钥信息。 --- 配对流程阶段二：配对流程加密链路的建立LE Legacy Pairing 第一阶段双方通过交换Pairing Request和Pairing Response消息，完成了配对方式以及Association model的协商。 第二阶段主要的作用就是： - 完成双方硬件身份认证的流程，确认对方就是自己要进行配对的设备。 - 为第三阶段配对密钥在两个设备之间交换和传输提供一个加密链路。 而如前所述，BLE配对流程存在两种模式：LE Legacy Pairing和LE Security Pairing。两者在配对流程的第二阶段差异极大，因此需要完整的分开来进行描述。这部分是LE Legacy Pairing模式下第二阶段工作流程的详细总结。 对于LE Legacy Pairing模式而言，配对流程加密链路的建立需要依赖于一个短期的加密密钥STK（short term key），这个STK仅用于配对过程中加密通信链路的建立，不会在两个设备之间长期保存和使用。 LE Legacy Pairing模式的阶段二执行流程大致如下所示。 !1734689246347.png 临时密钥TK的生成 STK的生成又要依赖于一个临时密钥TK（Temporary Key）。这个临时密钥TK长度是128位，依赖于具体的association model： - 对于Just Works模式，TK是一个全0的值。因此最不安全。 - 对于Passkey Entry模式，由一端在屏幕上显示，以及用户在另一端设备上输入以进行确认的一个6位数字密码，这个数字密码占据TK的20bit，其他108bit使用0填充。安全性介于JW和OOB之间。 - 对于OOB模式，TK是一个通过OOB方式在两边传输的128bit随机数密钥。安全性最好。 通过这一步，进行配对的双方共享同一个TK，但是这个TK并不是通过此时还不安全的BLE发给对方的。 设备身份认证 这一步两个BLE设备会各自计算出来一个confirm value的128位值。confirm value的计算需要使用一个c1函数，其参数是前一步已经在BLE两端共享的TK，各自产生的随机数，以及在Pairing Request和Pairing Response消息中两者共享的数据。 对于Central设备而言，其产生的随机数是LP_RAND_I，计算出来的confirm value是LP_CONFIRM_I；对于Peripheral设备而言，其产生的随机数是LP_RAND_R，计算出来的confirm value是LP_CONFIRM_R。在两端参与计算的函数都是c1，计算参数除了LP_CONFIRM_I和LP_CONFIRM_R以外都是相同的，因此各自计算出来的LP_CONFIRM_I和LP_CONFIRM_R是不同的。 !1734603029013.png 然后Central设备把自己计算出来的confirm value也就是LP_CONFIRM_I发给Peripheral设备，Peripheral设备则把自己计算出来的LP_CONFIRM_R发送给Central设备。 Central设备收到Peripheral设备发过来的LP_CONFIRM_R以后，就把自己进行c1运算的随机数LP_RAND_I再发给Peripheral设备。此时Peripheral设备就同时有了Central设备的LP_RAND_I和LP_CONFIRM_I，然后Peripheral设备就会使用自己的TK以及收到的LP_RAND_I再进行以此c1运算，把计算结果与收到的LP_CONFIRM_I进行比较，如果两者匹配的话，对于Peripheral设备而言就可以确认它们两端参与c1运算的TK是相同的。此时Peripheral设备就完成了对Central设备身份的认证。 然后接下来同样的逻辑，Peripheral设备把自己的随机数LP_RAND_R发送给Central设备，此时Central设备就有了计算LP_CONFIRM_R的所有信息，同样执行一遍新的c1运算，把计算结果与之前收到的LP_CONFIRM_R进行比较。如果匹配的话，对于Central设备而言，它就可以清楚的知道自己的TK与Peripheral设备的TK是相同的。此时就是完成了Central设备对Peripheral设备身份的认证。 至此以上就通过确认双方的TK是一样的，Central设备和Peripheral设备之间完成了相互之间的身份认证，确定对方就是自己要进行配对和绑定的设备。当然因为Just Works模式下双方的TK是全0，这个身份确认是没有任何意义的，所以Just Works模式实际上没有配对设备的身份认证流程，无法应对中间人攻击MITM。只不过Just Works模式通过以上流程在两端传输了两个随机数LP_RAND_R和LP_RAND_I，这两个随机数要在后面生成STK的时候使用。 下图就是两个设备之间进行身份认证的完整通信和判断逻辑： !1734604490831.png 生成STK密钥 接下来就是生成用于在配对流程中对通信链路进行加密的128bit短期密钥STK。STK的生成需要用到一个s1函数。 STK = s1(TK, LP_RAND_R, LP_RAND_I) 从以上s1函数的参数来看，TK，LP_RAND_R和LP_RAND_I全部在前一个设备之间相互认证的环节中已经双向传输了。因此对于两个设备而言，就可以分别使用s1函数来计算STK。 - 对于两端STK的计算而言，s1函数是一样的，两端共享的TK，LP_RAND_R和LP_RAND_I这三个参数也是一样的，那么其计算结果STK肯定就是一样的。 - 而从传输安全的角度看，LP_RAND_R和LP_RAND_I这两个随机数是在设备认证阶段的未加密链路中传输的，存在泄露的风险。但是对于OOB和Passkey两种模式而言，TK是使用OOB和Passkey传输和确认过的，根本就没有通过BLE链路传输，因此不存在泄露的风险，那么TK没有泄露的情况下STK的计算肯定就是安全的。 - 只不过对于Just Works模式而言，TK是全0，LP_RAND_R和LP_RAND_I这两个随机数是在设备认证阶段的未加密链路中传输的，所以STK仍然存在有泄露的风险。 至此，Central设备和Peripheral设备就都有了可以用于对配对通信链路进行加密的STK密钥，后续配对流程的第三阶段就可以基于STK密钥来实现对配对流程的加密保护了。 --- 配对流程阶段二：配对流程加密链路的建立LE Security Pairing 与LE Legacy Pairing迥异的是，LE Security Connections模式下采用了公私钥体系来实现对配对流程通信链路加密密钥的传递：该模式下会使用公私钥体系来生成和交换一个长期密钥LTK（Long Term Key），这个LTK不光用于配对流程第三阶段的通信链路进行加密，还会保存起来用于后续连接状态下数据通道的加密。 如前所述，大体的执行流程方面，LE Security Connections也分为三个大的阶段，其中第一阶段和第三阶段与LE Legacy Pairing没有区别，两者的区别主要就是体现在这个第二阶段，而且执行流程上的差异还很大，就一定要完整的分开来进行描述。 LE Security Connections模式第二阶段的总体流程如下图所示。 !1734656427648.png 当配对流程使用LE Security Connections模式时，根据第一阶段Pairing Request和Pairing Response双方的协商，可以使用全部四种Association Model：Just Works，Numerical Comparison，Passkey Entry以及OOB。比LE Legacy Pairing多了一个Numerical Comparison。 LE Security Connections模式的第二阶段主要可以分为四个步骤。 公钥交换 LE Security Connections模式的第二阶段首先由配对流程的发起方Initiator（也就是发出Pairing Request的那一方，即Central设备）发起流程。Initiator向Responder（也就是在第一阶段发出Pairing Response的那一方，即Peripheral设备）发出自己的公钥PKa，Responser则向Initiator发回自己的公钥PKb。至此通信双方都有了对方的公钥。 PKa和PKb都是在未加密的链路上传输的，但因为是公钥，所以对于安全性来讲没有威胁。 计算DHKey 下一步两个设备各自基于蓝牙规范中定义的P256算法生成一个DHKey。 - Initiator设备：DHKey=P256（SKa，PKb）。SKa是Initiator设备的私钥，PKb是Responder设备的公钥。 - Responder设备：DHKey=P256（SKb，PKa）。SKb是Responder设备的私钥，PKa是Initiator设备的公钥。 也就是说，对于通信双方而言，这个P256算法的输入参数都是自己的私钥和对方的公钥。经过P256算法的巧妙设计，两端使用自己的私钥和对方的公钥计算出来的DHKey是相同的，也就是说，此时通信双方就计算出来一个相同的DHKey。 尽管PKa和PKb此前是在未加密的链路上以明文传输的，但是两个设备的私钥SKa和SKb只保存在自己设备内部，所以DHKey的计算就是安全的。 设备硬件身份认证 设备身份认证这一步的具体执行，就跟前面根据双方IO能力所协商出来的Association Model相关。可选的Association Model包括Just Works，Numerical Comparison，Passkey Entry以及OOB这四种。这一步的目的就是要确认进行配对的设备的身份的正确性，当然，Just Works因为缺少必要的身份认证手段，在LE Security Connections模式实际上仍然是不具备设备身份认证的能力，只是走一遍流程而已。 为方便描述整个身份认证环节的执行流程，以下统一把配对流程的发起方Initiator称为Device A，把Responder称为Device B。 设备身份认证之JW/NC Device B产生一个128bit的随机数Nb，然后以这个Nb还有两个设备的公钥（在公钥交换步骤已经拿到）作为参数，使用蓝牙规范所定义的f4算法计算出来一个confirm value B即Cb： - Cb=f4（PKa，PKb，Nb，0） 然后Device B把计算出来的这个Cb发送给Device A。（此时Device A还不知道Nb） 下一步Device A生成自己的128bit随机数Na，然后把这个随机数发给Device B，Device B则向Device A返回自己之前生成的随机数Nb。现在Device A就有了所有用于计算Cb的参数，因此Device A基于收到的Nb重新执行一次f4算法，把自己计算的confirm value结果与前面收到的Cb相比较。如果两者一致的话（双方一致就说明前面阶段在双方之间共享的PKa和PKb信息是相同的）就继续往下走，否则就退出配对流程。 到了这个阶段，实际上对于Just Works模式而言，设备身份认证的环节就结束了。这部分后面的步骤只是针对NC模式的。可以看到，上面的步骤只是通信双方生成并交换了随机数，并确认了双方持有的公钥信息的正确性，实际上并没有办法确认对方硬件身份的合法性。 现在两个设备都确认过了双方的公钥PKa和PKb，以及双方所产生的随机数Na和Nb，那么接下来双方都通过蓝牙规范所定义的g2函数，以（PKa，PKb，Na，Nb）为参数计算出来自己的Confirm value，并且显示在自己的屏幕上。因为g2函数以及以上的四个参数都是相同的，所以双方计算和显示出来的confirm value肯定是相同的。 接下来就需要用户检查两个屏幕上显示的六位数字是否相同，如果相同的话通过按键操作确认，这样就保证了进行配对操作的两个设备之间的身份的合法性和正确性。 !385bc5cf-7ede-460e-8cdd-c2975b2c27ae.png 设备身份认证之Passkey Entry 对于Passkey Entry而言，默认的标准使用流程是需要进行配对的两个设备，一端有显示屏用于显示配对数字，另外一端有键盘输入这个数字以确认双方配对的硬件身份。而在LE Secure Connections模式下，Passkey Entry也能够支持两端都没有显示屏，但是都有键盘的使用场景，此时在两端配对的过程中通过键盘输入相同的数字来辅助进行设备认证。 接下来的身份认证阶段的运算流程比较复杂，基于两端匹配的6位数字的每一个bit，要进行20次（6位十进制数字最高是999999，对应于十六进制的0xF423F，因此总共最多有20位）反复的迭代运算和比较。 整个迭代比较的流程如下： !image.png - 2a和2b步骤就是在device A和device B上输入相同的配对数字，是一个六位数字，输入正确的情况下两者应该是相同的。然后在A和B两端分别把这个数字ra和rb按照二进制进行分解，分解为20个bit，后续的每一轮迭代计算用到其中一个bit。每个bit的命名就是rai和rbi，i表示第几次迭代。 - 3a和3b步骤分别在A和B两端各自产生一个128bit的随机数Na和Nb。每一轮迭代都产生新的随机数，所以每一轮的随机数就是Nai和Nbi。 - 4a和4b步骤分别在A和B两端使用蓝牙规范定义的f4算法，以两者前面阶段已经交换的公钥PKa和PKb，各自产生的随机数Na/Nb，以及本次迭代的验证数字的这一个bit位rai/rbi参数进行计算，在两端分别计算得到这一轮的Confirm Value，也就是Cai和Cbi。 - 5-8这几步就是在两端分别交换各自这一轮产生的随机数Nai和Nbi，各自计算出来的Cai和Cbi，然后在两边交叉计算后进行比较验证两端计算出来的confirm value是否一致。 - 第8步骤在计算出来的confirm value匹配的情况下，进行下一轮迭代，选择配对数字ra/rb的下一个bit重新执行3-8这几个步骤，直到所有的bit全部验证通过。 经过以上非常繁琐的运算和判断的过程，两个设备上输出的六位数配对数字更是被拆解为bit进入运算，即使在配对的流程中使用MITM中间人攻击对配对流程的数据交互进行监听，也大大增加了破解的难度，因此安全性方面比LE Legacy Pairing要好很多。 设备身份认证之OOB 与LE Legacy Pairing过程的OOB模式类似，LE Security Connections流程下OOB模式也需要通过非蓝牙通信以外的带外通信方式（NFC、二维码等）辅助进行设备硬件身份认证流程执行中部分信息的传输，只不过两者的执行流程差异极大。 下图是LE Security Connections流程下OOB模式的身份认证通信流程： !image.png - 首先两者各自产生一个随机数ra和rb，然后各自使用f4算法，以自己的公钥和产生的随机数作为参数计算出来各自的confirm value也就是Ca和Cb。 - 然后通过蓝牙之外的带外通信能力，把自己用于配对通信流程的随机蓝牙地址BD_ADDR_A/BD_ADDR_B，两端产生的随机数ra/rb，以及两端各自计算出来的confirm value Ca/Cb传递给对端。 - 两端分别基于OOB信道传递过来的信息重新以f4算法，使用对方的公钥和对方产生的随机数，再计算出来一个confirm value，对这个confirm value和对方通过OOB传过来的Ca/Cb进行对比是否一致。如果一致的话表示双方的硬件身份认证成功。 - 最后就是双方各自产生一个新的随机数Na和Nb，并传递给对方，用于在下一阶段生成长期密钥LTK。 LTK的生成和校验 接下来就是在两端各自计算LTK。为了确保前面所有的环节都是正确的，以及确保两端计算的LTK是一致的，还需要通过另外一个MacKey来执行这个验证和确认的环节。 对于LTK和MacKey的计算而言，需要用到蓝牙规范中定义的f5算法。这个算法的输入参数包括DHKey，两端生成的随机数Na和Nb，以及两端在配对过程中所使用的蓝牙MAC地址BD_ADDR_C和BD_ADDR_P。 MacKey || LTK = f5(DHKey, Na，Nb, BD_ADDR_C, BD_ADDR_P) - 经过前面所有的环节，DHKey，随机数Na和Nb，蓝牙MAC地址BD_ADDR_C和BD_ADDR_P这几个值两端都已经知道了，所以就可以分别使用f5函数来独立的计算出来MacKey和LTK。如果没有出现意外的话，两端计算出来的LTK和MacKey应该是一样的。 至此后续用于对数据连接链路加密的长期密钥LTK就诞生了。那么怎么保证两端生成的这个LTK是一致的呢？此时还要再对MacKey进行一次校验，如果MacKey相同的话，LTK也就没问题了。 MacKey验证的过程依赖于蓝牙规范定义的f6算法，参数是两端各自计算出来的MacKey，两端之前阶段交换的随机数Na和Nb，两端在配对过程中交换的IOCap信息（包含在Pairing Request和Pairing Response信息中），两端在配对过程中所使用的蓝牙MAC地址BD_ADDR_C和BD_ADDR_P。 MacKey验证的逻辑流程如下： - Initiator按照f6算法计算出来自己的校验值EA，Responder按照6算法计算出来自己的校验值EB。注意两个计算的参数稍有差异，一个是IoCapA一个是IoCapB，所以EA和EB应该是不同的。 - Initiator把自己计算出来的EA发给Responder，Responder在自己这边重新按照与Initiator计算EA一样的参数和算法计算出来自己这边的EA，比较两个EA是否一致。如果一致的话，Responder就清楚的了解两端的MacKey和LTK是一致的。 - 相同的逻辑，Responder把自己计算出来的EB发给Initiator，Initiator在自己这边重新按照与Responder计算EB一样的参数和算法计算出来自己这边的EB，比较两个EB是否一致。如果一致的话，Initiator就清楚的了解两端的MacKey和LTK是一致的。 - 至此，Initiator和Responder就通过以上流程确认了两端MacKey和LTK的一致性。 可配合下图来完整理解LTK的生成和验证的逻辑： !image.png 下一步就可以使用两端生成并且确认过的LTK对通信链路进行加密保护进入配对流程的第三阶段了。 --- 配对流程阶段三： 到了第三阶段，就是基于第二阶段所生成的STK密钥（LE Legacy Pairing）或者LTK密钥（LE Secure Connections）对通信链路进行保护，后续配对流程的通信就全部是加密的了。 而第三阶段的主要作用也就是按照第一阶段双方在Pairing Request和Pairing Response消息中协商的要分享哪几个密钥（LTK, CSRK, IRK），密钥的长度，各个密钥由哪一端来分发等信息来安排好对于密钥分发的流程，最终的目的就是在两端同步后续进行数据通信的真正密钥。配对流程结束以后，短期密钥STK也就被废弃了（对于LE Legacy Pairing模式而言）。 - LTK, CSRK, IRK这三个才是两个设备之间后续数据通信过程中真正的通信密钥。 - 对于LE Security Connections模式而言，因为LTK在第二阶段已经交换过了，所以第三阶段就只需要通过加密连接在双方之间传输CSRK和IRK就好了。对于LE Legacy Pairing模式则需要在第三阶段的加密连接中传输上面的三个密钥。 以上在两端共享的密钥只会用于本次连接的后续通信，不会自动保存。下一次两个设备如何还要建立连接进行通信的话，那么就要按照以上配对流程完整的重新走一次以交换新的连接通信密钥。这样的话，看起来整个过程就太繁琐了。因此，如果在配对流程结束以后，把这次在两端共享的通信密钥保存下来，直接用于后续的通信过程，这样就可以省去每次连接都要配对的流程，而把配对密钥第三阶段通过加密连接交换的通信密钥保存起来的动作，就是绑定（Bonding）。经过绑定操作以后，两个设备以后重新连接就可以直接使用之前保存起来的通信密钥了。 - 配对流程结束后是否需要保存密钥（即执行bonding过程），取决于第一阶段Pairing Request和Pairing Response消息中所包含的Bonding Flags标志位。 !image.png 参考资料 - Understanding Bluetooth LE Pairing—Step by Step - Technical Articles - Developer Study Guide: Bluetooth® Low Energy Security V1.2.1 - BLE蓝牙技术详解