解决什么问题
TSN 对新手不友好的地方，是它不是一个单一协议。你会同时看到 802.1AS、802.1Qbv、802.1Qbu、802.1CB、802.1Qcc、CBS、TAS、FRER、gPTP、CNC 等词。只按标准编号记忆，很快就会混乱。
更合理的方式是把它们放进能力地图。每个能力回答一个工程问题：时间怎么对齐，流量怎么分类，队列怎么竞争，窗口怎么安排，大帧怎么处理，路径资源怎么配置，故障怎么恢复，最后怎么验证。
背景与直觉
端到端确定性像一条链。链路上任何一环失控，关键流量的边界都可能失效。共同时间失控，时间窗口就会错位；队列分类失控，关键流量可能进错队列；调度窗口失控，关键帧可能错过时隙；配置失控，不同设备对同一条流的理解可能不一致；冗余失控，故障时可能两条路径一起失效；验证失控，系统只是看起来正常。
这张地图不是为了把所有标准一次讲完，而是建立位置感。以后学到一个机制，你能立刻知道它在链条上补哪一段，以及它依赖前后哪些环节。
怎么解决
可以把 TSN 能力分为八组。
| 能力 | 代表机制 | 回答的问题 |
|---|---|---|
| 共同时间 | 802.1AS / gPTP | 所有设备如何理解同一个“现在” |
| 分类与队列 | 802.1Q, PCP, traffic class | 哪些帧进入哪些队列 |
| 整形 | CBS 等 | 如何把突发流量压成更稳定节奏 |
| 时间调度 | 802.1Qbv / TAS | 哪些队列在什么时候可以发送 |
| 阻塞控制 | 802.1Qbu / 802.3br | 普通大帧如何不长期挡住关键帧 |
| 流级配置 | 802.1Qcc, CUC/CNC | talker 到 listener 的路径如何一致配置 |
| 冗余连续性 | 802.1CB / FRER | 链路或设备故障时如何保持关键流连续 |
| 验证 | 测试、测量、分析 | 配置结论如何被证据支撑 |
依赖关系比清单更重要
能力地图不是并列清单。很多机制之间有依赖。
Qbv 依赖共同时间，否则 gate open/close 的时刻没有统一坐标。Qbv 也依赖队列分类，否则关键帧可能没有进入被保护队列。帧抢占会影响 guard band，因此会改变 Qbv 预算。Qcc 需要知道设备和拓扑能力，否则集中配置无法判断一条流能否被接纳。FRER 会让同一条流占用多条路径，因此会影响资源规划和调度可行性。
这也是为什么工程里常出现“单点功能测试通过，系统集成失败”。单个机制能工作，不代表能力组合后的假设仍然一致。
带来了什么新问题
能力越多，组合复杂度越高。你可能同时希望低延迟、高链路利用率、高可靠性、低配置复杂度和低成本，但这些目标经常冲突。关键窗口开得越多，普通流量空间越少；冗余路径越多，带宽和调度压力越大；验证越严格，测试成本越高。
工程上也会出现“支持标准”和“会正确组合”之间的差距。设备支持 802.1Qbv 不代表你能自动得到端到端调度；支持 FRER 不代表路径真的独立；支持 gPTP 不代表误差足够小。
检查点
- 如果有人说“这个交换机支持 TSN”，你应该继续问它支持哪几类能力？
- 一条控制流需要 250us 内到达且故障不断流，你会在能力地图上圈出哪些机制？