选择困难？FQTSS协议来帮你

叁歲伎倆 2022-12-25 11:50 505阅读 0赞

## **1、FQTSS协议在AVB中与其他协议间的关系** ##

讲到FQTSS，这里先为大家说明一下音视频传输实现的简要过程，说明的过程中我会结合用到的相关协议，帮助大家更好地理解AVB协议簇。

可以想象一下，当我们需要在某个通信网络中传输音视频流数据时，需要做哪些工作才能保证该流数据顺利地从源头到达目的地，且传输过程中的延迟时间不能影响实际体验（如音视频画面/声音同步、大型场合多屏幕显示播放同步等场景）？

首先，我们需要保证网络上有足够的带宽来传输我们期望的流数据，不然等到需要传输重要流数据但是带宽却不够，就尴尬了哈！这个顾虑可以通过SRP（流预留协议）进行保证，SRP的主要作用就是在通信网络启动后动态地分配不同流数据的网络带宽从而保证特定流数据有足够的传输带宽。当然，SRP在车载网络中不是必需的，这是因为车载通信网络相对比较固定，流数据的发送接收情况也很明确，采用静态配置同样可以达到流预留的效果。

然后，我们需要保证这些流数据在所有相关的Listener处（就是播放方/目的节点）有一个高可靠、高质量的时钟基准，这样大家就可以按照流数据的约定播放时间点（AVTP协议中的呈现时间）在同一个时间播放音视频，不至于因为各终端的时钟基准不一致影响用户体验。而这可由gPTP（时间同步协议）保证，当然gPTP不仅仅是提供时钟同步这么简单，它还有计算精确传输延时的作用，具体可见怿星往期推文[《一刻钟读懂gPTP》][gPTP]（认真听课的童鞋都知道）。

你以为带宽预留、时钟同步都保证了，Talker（数据发送方/数据源头）就能将想要的流数据在通信网络上顺利畅通地发出去么？没那么简单！假设现在有多个Talker都需要把自己的流数据发送到同一目的地，恰好这些流数据同时到达某Switch的同一发送端口，那么此时Switch就会有选择困难症了，到底先发哪一帧流数据呢？貌似先发谁都不好，因为其他Talker都会不爽的！而且如果发送先后顺序选择不当造成某些重要流数据延迟超出预期，这锅谁来背？哈哈，无需烦恼，FQTSS（时间敏感性流的转发和队列协议）就是用来解决此类问题的。

解决了所有潜在顾虑，现在我们可以放心地往通信网络上发送流数据了。本来如果整个网络中只存在一种格式的流数据编码，直接用标准以太网帧格式传输就行，但是现实中我们会有许多种音视频媒体编码格式，那么在发送方处就需要将这些不同格式的流数据加以区分进行发送，这样接收方也能正确识别并解析这些数据进而呈现给用户，另外还需要保证所有接收终端在约定好的同一时间播放同一流数据，因此AVTP（音视频传输协议）应运而生，当然AVTP作用也不限于此。到此，正式进入到FQTSS的世界。

## **2、FQTSS的作用对象及工作原理** ##

FQTSS：Forwarding and Queuing of Time Sensitive Streams，时间敏感性流的转发和队列。从字面上来看，该协议可以管理时间敏感性流的转发和队列，但听起来还是很抽象，接下来为大家详细介绍该协议。

![357030425f44bfcfb1f553b7e2068173.png][]

**协议作用对象**

协议名称看似说明了该协议的作用对象，但大伙可别被误导了，认为该协议对非时间敏感性流无作用，其实它对非时间敏感性流同样有用。因为只有将网络节点发送端口处所有队列中的流进行有序管理，才能优先保证时间敏感性流的传输，这是相辅相成的。

**协议作用**

列队转发作用，根据实际需求将端口处接收到的帧按照流量类别以及优先级进行排队并有序发送，但也会限制高优先级流的带宽占用，防止高优先级流一直占用网络而导致低优先级流一直无法发送的不合理现象。

那么FQTSS究竟是如何实现该作用的呢？主要是通过基于信用的流量整形和严格优先级这两种算法实现的。提到算法选择，就不得不先说说流量类别了。

**流量类别（Tracfic Class）**

目前FQTSS作用对象有两种流量，SR类和非SR类。SR类就是需要进行流预留的类别，非SR类为不需要进行流预留的类别。

对于SR类，AVB中定义了两类常见的标准SR流：A类和B类，均有其固定属性。

![050bcf22b2bf427be072f3f0e40908da.png][]

若用户选择使用这两类，必须严格遵守规范定义的固定属性配置，但是SR类别优先级的数值可以适当进行调整，只要保证相对的优先关系不变即可，这个视具体使用场景而定。当然用户也可以根据实际项目需求自定义其他类别的SR流以及相应属性配置，但是在类别的属性定义上不得与标准类别相同，相对来说比较灵活，也能更好地满足需求。

对于非SR类，即Best-Effort流，仅仅通过配置优先级保证其传输。

**传输选择算法**

FQTSS定义了两种传输选择算法：基于信用的流量整形算法（CBS：Credit Based Shaper）以及严格优先级（Strict priority）算法。

基于信用的流量整形算法：当信用值≥0时，相关的流才能发送出去，否则无法发送。发送流时会消耗信用，不发送流且流在发送队列中时信用会一直累积直到流可以被发送出去，不发送流且流不在队列中时信用累积的最大值只能到0。

严格优先级算法：严格按照优先级进行发送，当基于信用的流信用用完无法发送时，尽力而为（Best-Effect）流才可以发送，且发送顺序严格按照优先级从高到低依次发送，直到基于信用的流再次可以发送。

FQTSS协议规定SR类流使用基于信用的流量整形算法，非SR类流使用严格优先级传输算法。

一般来说，基于信用的流量整形算法的流传输优先级均高于严格优先级传输的流，换句话说，当这两种流同时需要往外发送时，优先发送前者（只要信用值≥0），但也不是无限制的发送前者，因为发送前者是需要消耗信用的，如果信用值＜0，则停止发送前者（当前正在传输的流不会受到影响，会保证其完整传输），转为发送尽力而为流，直到基于信用流的信用累积≥0时再次转为发送基于信用的流。

那么属于同类别流但处于不同队列的发送顺序又是如何的呢？

*  不同队列的多个SR类流等待发送时，先比较信用值，再比较优先级。有信用的可以发送，优先级高的先发送；
 *  不同队列的多个非SR流等待发送时，只看优先级；
 *  同队列的流按照FIFO原则依次发送。

基于严格优先级传输的算法比较好理解，无需过多说明，接下来我们详细说明基于信用的流量整形算法到底是如何工作的，先分析下图：

![7dabaac5db98911f27b8b3750f2bccd3.png][]

上图描述了处于同一队列的3个待传输SR类流传输情形，其在队列中先后顺序为A>B>C。

*  首先，因为有其他队列中的帧正在传输导致A/B/C流无法传输，这个时候信用值以“idle slope”的速率进行累积；
 *  等待冲突帧传输完毕后，这时候信用累积值≥0，按照队列顺序A开始传输，同时信用值以“send slope”速率进行消耗；
 *  当A传输完毕时，信用累积值仍然≥0，按照队列顺序B开始传输，同时信用值以“send slope”速率进行消耗；
 *  当B传输完毕时，信用累积值＜0，此时C无法发送，需要等待信用累积，同时以“idle slope”速率累积信用值；
 *  当信用值由负值变为0时，且当前无其他冲突帧传输，C开始传输，同时信用值以“send slope”速率进行消耗，直到C传输完毕，这时队列中无发送需求，信用值重新累积直至为0不再增加。

以上就是基于信用的流量整形算法的工作机制，总结CBS机制如下：

*  当Credit≥0时，SR流量才能传输；
 *  当SR流量无法传输时，Credit将以idleSlope的速率增加；
 *  当SR流量正在传输时，Credit将以sendSlope的速率减少；
 *  若Credit＞0，但队列中没有待传输SR流，Credit将直接设置为0；
 *  若Credit＜0，但队列中没有待传输SR流，Credit则以idleSlope的速率累积信用值达到最大值0；若有待传输SR流，Credit则以idleSlope的速率持续累积信用。

## **3、FQTSS参数配置** ##

在上一章节中出现了不少关于FQTSS的配置参数，说明如下：

**带宽可用性参数**

*  **portTransmitRate：**端口传输速率，如100M/s；
 *  **deltaBandwidth（N）：**SR类流（N）可使用的最大预留带宽，表示为portTransmitRate的百分比，如30%，实际预留带宽值小于等于该值；
 *  **adminIdleSlope（N）：**若当前网络SRP未运行，该参数有效。operIdleSlope（N）值会一直等于此值，相当于SR类流（N）的默认带宽预留值，单位bits/s；
 *  **operIdleSlope（N）：**为SR类流（N）配置的实际带宽预留值，单位bits/s，数值上等于adminIdleSlope（N）。

**Tspec参数：**

*  **MaxIntervalFrames：**流的最大传输速度，对于A类流量，该值为8000帧/秒的倍数（如值为2，代表帧的最大传输速度为16000帧/秒）；对于B类流量，该值为4000帧/秒的倍数；
 *  **MaxFrameSize：**最大帧尺寸，仅仅指负载数据，不包括帧间间隔和802.1Q帧报头开销，我们在计算实际带宽消耗时需要考虑这些附加帧开销。

**CBS算法参数：**

*  **Transmit：**某一队列中，如果当前有帧正在进行传输，则置为True，否则置为False；
 *  **Credit：**信用值，单位bits；
 *  **IdleSlope：**帧未被发送时的信用累积速率，单位bits/s，数值上等于operIdleSlope；
 *  **SendSlope：**帧被发送时的信用消耗速率，单位bits/s，该值=IdleSlope-portTransmitRate；
 *  **TransmitAllowed：**表示当前队列中的帧是否可以发送，当信用值≥0时，置为Ture，表示可以发送；否则置为False，表示不可以发送。

## **4、与实际应用结合的FQTSS应用场景** ##

前面章节介绍CBS作用原理时是基于单一队列的SR类流的帧传输情况，那么针对Switch某个发送端口的真实传输情形又是怎样的呢？如下图所示：

![ffd58b98217079b14e3bd198fddb88ee.png][]

该发送端口共设计有4个队列，优先级依次为3、2、1、0，分别用于传输SR\_A、SR\_B、BestEffort\_0、BestEffort\_1这四类流量（traffic）。(附：一个端口可以设计最多8个队列，分别对应VLAN tag的8个优先等级。)其中A、B是SR类流，使用基于信用的流量整形算法；0、1是BestEffort类流，使用严格优先级的传输算法。

在实际传输中，任何队列不为空即为有发送需求，可能出现的发送场景如下：

*  若A/B中有任何一方需要发送，且信用值满足发送条件，则可以发送，此时0/1无法发送；
 *  若A/B同时需要发送且信用值均满足发送条件，A类优先发送（若A优先级大于B），B随后发送，0/1无法发送；
 *  若A/B中有任何一方需要发送，但是信用值不满足条件，则无法发送，此时0/1可以发送，且发送顺序按照优先级进行，直到A/B满足发送条件且需要发送。

## **5、结语** ##

FQTSS协议其实是在严格优先级算法（Strict Priority）的基础上发展起来的，在严格优先级算法中，高优先级队列中的帧优先级最高，发送权最大。如果将音视频流量放入最高优先级的队列中，带宽够用的情况下，肯定能保证延时最小。但为了保证低优先级的数据流也有发送机会，所以需要限制高优先级的流的带宽占用，故有了CBS算法。

FQTSS协议配合SRP协议实现音视频流量传输的延时保障，通过SRP协议的Tspec参数，静态计算配置数据流的预留带宽，使用FQTSS协议作为传输整形算法，让音视频流优先发送，但发送的同时给普通数据流发送机会。

关于FQTSS的介绍就到这里，希望各位都能有所收获，后续我们会持续更新AVB/TSN相关的技术分享，感兴趣的童鞋记得评论区留言或者私信小怿噢！

[怿星科技][Link 1]作为一家聚焦汽车电子新兴及关键技术的服务公司，已在国内较早地开展AVB/TSN技术研究，具备了丰富的设计和测试经验，能够提供AVB/TSN技术相关的架构设计、测试服务、协议栈开发和集成服务。

![173001637e366ad400d7f67fe987b880.png][]

[gPTP]: https://link.zhihu.com/?target=http%3A//mp.weixin.qq.com/s%3F__biz%3DMzIwMDgzOTg3Mg%3D%3D%26mid%3D2247487370%26idx%3D1%26sn%3D6d8e45e9aca1ce53ec4002fd1bd75d46%26chksm%3D96f64825a181c133f8eb1aea954ef4a0669c0e3ec3ff010e7fad43eee5d52a40c57ee8cdeb23%26scene%3D21%23wechat_redirect
[357030425f44bfcfb1f553b7e2068173.png]: /images/20221120/c6afdd261dde4ab886b932d0e95f7fad.png
[050bcf22b2bf427be072f3f0e40908da.png]: /images/20221120/c31434a7df0e42a3b417acbec87bc26e.png
[7dabaac5db98911f27b8b3750f2bccd3.png]: /images/20221120/91fa4e7854274a4eb46199c0ecc19121.png
[ffd58b98217079b14e3bd198fddb88ee.png]: /images/20221120/885ca1e70bdd4ffd92232e0212fdd6b8.png
[Link 1]: http://www.e-planet.cn/
[173001637e366ad400d7f67fe987b880.png]: /images/20221120/14ac470738144bda8c788f7890ec7c68.png