来源：TSNLAB 微信公众号
阅读过TSN资源管理技术那篇文章的读者一定记得，TSN方案运转有一个基本逻辑，或者说前提条件，就是端设备（用户）要把自己发送流量的信息和对网络的需求告知网络，网络才能有的放矢地制定方案。反正，如果用户“耍流氓”，自顾自地使用网络，发送大量流量，那不论你网络有三头六臂，路由器或交换机上使用什么天花乱坠的调度机制，也没法提供确定的传输时延和可靠性的保障。
这种端（用户）与网络之间的契约精神，是TSN和我们传统的、统计复用的IP网络的一大本质区别。我们日常生活中使用互联网，我们作为用户，或者说我们使用的APP，都希望尽可能地使用更大的带宽（排除某些APP为了让用户付费而限速的情况）。不论TCP历代各种算法，还是最近几年比较火的QUIC，本质上改变不了用户在使用带宽时需要博弈的底层逻辑。从经济学的角度来看，因为无法统一管理所有用户，所以最终会导致一个非最优解的纳什均衡。TSN则没有这个问题，因为端侧是受管控的，如果有的端违反了契约精神，TSN也有办法（可靠性相关技术）治它。
当然不是说统计复用的IP网络不好，它对于互联网而言仍然是非常有效率的方案。而TSN则会首先在较小规模的局域网使用，这里的端相对易于受到统一机制的管控。
下图来自IEC/IEEE 60802联合工作组的1.3版本文稿，描述了工业端侧应用和TSN网络的关系。请重点关注步骤1、2、3，应用对于网络服务质量（QoS，Quality of Service）的要求，包括应用自己的信息和特征，要传递给网络（图中是集中式网络配置CNC控制器）。这件事情可以由一个具体的端设备（用户）来发起，也可以由集中式用户配置CUC控制器作为具体端设备的代理来发起。不论如何，这个都是端侧，或者说用户侧，需要在准备阶段就完成的任务。
TSN对于各行业的Profile标准中，包括已完成的AVB Profile，以及正在进行的工业自动化网络Profile、车载网络Profile等，都会同时制定对于TSN网桥（bridge，具体形态可以是路由器、交换机、网桥等）和TSN端设备（end-station）的功能和性能要求。在理想的情况下，网络中的网桥和端设备都支持TSN，就可以顺利部署TSN方案了。
这就是TSN端设备和TSN网络设备同样重要的原因。而且，当前世界上几乎所有存量的端设备都是不支持TSN的，如何通过软件技术，配合最小的硬件改动，实现存量端设备对TSN的兼容组网，是我们认为当下TSN技术发展的关键方向之一，对于加速TSN的应用落地具有重大的促进意义。不论你是否也有同样的想法，欢迎关注TSNLAB，和我们取得联系，一起助力TSN发展吧！