第2章 TSN核心标准

2、TSN核心标准：IEEE 802.1Qbv、802.1Qbu、802.1CB深度解读

各位好，咱们今天聊聊TSN的三个核心标准。说实话，这三个标准是TSN的基石，搞懂了它们，边缘计算网络里的实时通信问题基本就解决了一大半。

我个人习惯把这三个标准比作交通管理：Qbv是红绿灯，Qbu是应急车道，CB是备用路线。你想想看，一个城市要保证车辆准时到达，这三样缺一不可。下面我一个一个说。

2.1 IEEE 802.1Qbv：时间感知整形器（TAS）

Qbv，全称是Time-Aware Shaper，时间感知整形器。说白了，它就是给网络流量排班表。

核心思想：把时间切成一个个小窗口，每个窗口只允许特定类型的流量通过。比如，前100微秒只走控制指令，后200微秒走视频流，再留50微秒给普通数据。

关键参数：

门控列表（Gate Control List, GCL）：定义了每个时间窗口的开关状态
周期时间（Cycle Time）：整个调度周期，比如1ms
时间槽（Time Slot）：每个窗口的持续时间

我在项目中遇到过一个问题：有个客户做工业机器人控制，要求端到端延迟小于100微秒。一开始他们用普通交换机，延迟抖动大得离谱。后来上了Qbv，把控制流量放在第一个时间槽，优先级最高，延迟直接降到50微秒以内。

避坑指南：我曾经在配置GCL时犯过一个低级错误——时间槽之间没留保护带。结果呢？时钟漂移导致两个窗口的流量撞车了。嗯，这里要注意，每个时间槽之间至少要留一个最大帧传输时间的保护间隔。

配置示例（基于Linux tc工具）：

# 创建一个Qbv调度，周期1ms
tc qdisc add dev eth0 parent root handle 1: taprio \
    num_tc 4 \
    map 0 1 2 3 3 3 3 3 3 3 3 3 3 3 3 3 \
    queues 1@0 1@1 1@2 1@3 \
    base-time 0 \
    sched-entry S 0x01 50000 \   # 前50us，只开队列0
    sched-entry S 0x02 100000 \  # 接下来100us，只开队列1
    sched-entry S 0x04 50000 \   # 再50us，只开队列2
    sched-entry S 0x08 800000 \  # 最后800us，开队列3
    flags 0x02

你想想看，这个配置就像给每个流量类型分配了专用车道。控制流量走队列0，视频走队列1，普通数据走队列3。时间一到，门就打开，其他门全关。

2.2 IEEE 802.1Qbu：帧抢占（Frame Preemption）

Qbu解决的是另一个问题：低优先级的大帧堵住了高优先级的小帧。

举个例子：一个1500字节的普通数据帧正在传输，突然来了一个60字节的控制指令。按照传统方式，控制指令得等这个大家伙传完，这一等可能就是几十微秒。对于实时控制来说，这太长了。

Qbu怎么做的？它允许高优先级帧打断低优先级帧的传输。被打断的帧会暂停，等紧急帧传完后再继续。

实现机制：

发送端把低优先级帧切成一个个小片段（Fragment）
每个片段前面加一个校验码（mCRC）
高优先级帧来了，直接插入到片段之间
接收端把片段重新组装成完整帧

我记得有一次调试一个运动控制系统，发现偶尔会出现控制指令延迟超标。查了半天，原来是某个摄像头在发送大尺寸的JPEG图像，把控制指令堵住了。启用Qbu后，问题立刻解决。

注意事项：

Qbu需要链路两端都支持，否则会回退到普通模式
帧抢占会增加CPU开销，大约5%-10%
不是所有流量都适合被抢占，比如视频流被切碎后解码可能出问题

配置示例（基于IEEE 802.3br）：

# 启用帧抢占（假设网卡支持）
ethtool --set-priv-flags eth0 frame-preemption on

# 设置抢占优先级（优先级7为可抢占）
tc qdisc add dev eth0 parent root handle 1: mqprio \
    num_tc 2 \
    map 0 0 0 0 1 1 1 1 \
    queues 1@0 1@1 \
    hw 1

说白了，Qbu就是给网络加了个"紧急通道"。普通数据走慢车道，紧急数据走快车道，还能随时超车。

2.3 IEEE 802.1CB：帧复制与消除（FRER）

CB标准，全称Frame Replication and Elimination for Reliability。名字很长，但核心就四个字：冗余传输。

为什么需要冗余？因为网络不可靠。线缆可能被老鼠咬断，交换机可能突然重启，电磁干扰可能造成误码。对于自动驾驶、工业安全这类场景，丢一个包可能就是事故。

CB的做法很简单：发送端把每个数据包复制两份，走两条不同的路径。接收端收到后，只保留第一个到达的，丢弃重复的。

关键组件：

序列号生成器（Sequence Number Generator）：给每个包打上唯一序列号
复制点（Replication Point）：把包复制到多个路径
消除点（Elimination Point）：根据序列号去重
个体恢复（Individual Recovery）：从丢失的包中恢复数据

我在一个智慧工厂项目里用过CB。客户要求控制指令的丢包率低于10^-9，单条链路根本做不到。我们部署了双冗余网络，主路径走有线，备用路径走5G。CB自动复制和去重，丢包率直接降到10^-12。

避坑指南：我曾经以为CB是万能的，结果发现它有个大坑——序列号溢出。如果序列号用16位，65535个包后就会回绕。接收端可能把新包当成重复包丢弃。嗯，后来我改用32位序列号，问题解决。

配置示例（基于Linux 802.1CB实现）：

# 创建冗余组
ip link add name frer0 type frer \
    member eth0 member eth1 \
    seq-gen 32 \
    seq-recovery 10

# 配置序列号生成
echo "seq-gen enable" > /sys/class/net/frer0/frer/seq_gen

# 配置消除窗口（10ms内到达的重复包丢弃）
echo "seq-recovery window 10000" > /sys/class/net/frer0/frer/seq_recovery

你想想看，CB就像给重要数据买了双保险。一条路断了，另一条路还能到。而且接收端自动去重，上层应用完全无感。

2.4 三个标准的协同工作

这三个标准不是孤立的，它们经常一起用。我画个场景你就明白了：

场景	Qbv作用	Qbu作用	CB作用
工业机器人控制	保证控制指令准时发送	紧急停止指令优先传输	双链路冗余防断线
自动驾驶V2X	周期性广播安全消息	碰撞预警消息抢占	多路径传输防丢包
远程手术	视频流和控制流分时传输	控制指令打断视频帧	主备链路无缝切换

实际部署时，我建议先上Qbv，把基础的时间调度搞定。然后根据业务需求决定要不要加Qbu和CB。如果控制指令经常被大帧堵住，就上Qbu。如果网络环境恶劣，丢包率高，就上CB。

我的个人经验：

Qbv的GCL配置要留余量，别把时间槽排得太满
Qbu只对关键流量启用，别全开，否则CPU扛不住
CB的冗余路径要物理隔离，别走同一个交换机

好了，这三个标准就讲到这里。说白了，Qbv管时间，Qbu管优先级，CB管可靠性。三个一起用，你的边缘计算网络就能做到"准时、可靠、不丢包"。下一章咱们聊聊TSN的时钟同步，那可是所有时间调度的基础。