为了传输更高带宽的音视频流并且满足汽车内低延迟、高可靠性传输的要求，IEEE 802.1音视频桥接(Audio Video Bridging, AVB)工作组定义了一种基于一套独立于TCP/IP协议族的通信协议的实现方法。涉及到的协议大体如下：
IEEE802.1Qat，流预留协议(StreamReservation Protocol, SRP),为特定的数据流预留带宽的标准；
IEEE802.1Qav，时间敏感流的转发和排队规则(Forwarding and Queuing for Time-Sensitive Streams, FQTSS),流量整形的标准，可保证带宽和QoS的延迟参数。
以及其他的上层通信方案：
IEEE1722，音视频桥接传输协议(Audio/VideoBridging Transport Protocol, AVBTP)
IEEE 1733，实时传输协议(Real-timeTransport Protocol, RTP);
IEEE802.1AS， 广义精确时钟协议(GeneralizedPrecision Time Protocol, gPTP)，确保收发的终端之间严格时间同步的标准。
本文将对gPTP协议进行简单介绍和分析。
gPTP的用途是将车载网络中各个节点的时钟进行同步，因为各个节点的时钟都是互相独立运行的，而有些应用需要各个节点步调一致地执行。比如播放音频和视频的任务可能在不同的节点上实现，那么这两个设备必须要有相同的时钟基准，否则可能出现画面和声音对不上的情况。时钟同步本质上就是各方对一下表。
gPTP是基于主从关系的，也就是说，一个局部网络中的所有节点以master的时钟为基准，将自己的本地时钟与master的时钟进行同步。下面是个简单的示意图，需要注意的是，时钟同步是层层递进式的，slave也可以作为下一层网络的master。
gPTP协议位于OSI模型的层2之上，可以依赖于以太网传输。gPTP报文利用以太网传输时，MAC报文头中的Ethertype = 0x88F7。
gPTP报文由3部分组成：
Header (对所有gPTP都一样)
Body (取决于gPTP 报文类型)
TLV(type lengthvalue)
其中header是所有类型的gPTP报文都有的，它有34个字节，结构如下图所示：
gPTP报文头
报文头中的message Type标识了gPTP报文的类型，类型取值范围如下图所示：
gPTP报文类型
接下来对gPTP协议的具体任务和实现流程的介绍中将涉及到上图中的报文类型。
gPTP要完成的主要任务包括：
1.选择最佳主时钟
2.频率同步
3.时间同步
4.延迟时间测量
选择最佳主时钟：
gPTP的主时钟选择机制是“最佳主时钟算法(BMCA)”。选择算法启动时，所有可以成为主时钟的端点都会参与竞争。要启动BMCA算法，所有端点都通过发送Announce报文来宣告自己的能力。各个端点比较自己与其他端点的相关字段值，胜出者作为主时钟端点。但车辆是一个封闭的网络，不会出现节点总变化的情况，所以车载应用中，主时钟往往都是固定的，比如网关。
频率同步：
网络中各个节点的时钟的频率并不总是完全一致。比如，在实际为100秒的时间段时间，A节点的时钟可能计时为90秒，B节点的时钟可能计时为110秒(实际中不可能出现如此大的偏差，但偏差总是有的，这里只是举例说明)。所以gPTP Slave的时钟频率需要与Master相匹配。频率同步的实现方式如下图所示：
频率同步的实现方式
在实际的gPTP通信中，master会不停地发送Sync和Follow-up，slave能够测量出自己收到Sync报文的时间，即上图中的T2和T4(这个时间是以slave的本地时钟为基准的)。在每个sync报文之后，master都会发送一个follow-up报文，用来告诉slave自己发送上一条sync报文时的时间戳(以master的本地时钟为基准)。没有follow-up报文的话，slave无法知道Sync报文的实际发送时间，即上图中的T1和T3。所以sync和follow-up总是成对出现的。有了T1、T3和T2、T4，slave就能够计算出自己的时钟频率与master之间的偏差，计算式如下图所示：
延迟时间测量：
为了将自己的时钟与master同步，slave必须测量出自己与master之间报文传递的延迟时间。时延测量使用到的上文中提到的PDelay_Req、PDelay_Resp和PDelay_Resp_Followup三种gPTP报文。具体的测量方式如下图所示：
延迟时间测量
1.首先slave发送PDelay_Req报文，请求测量延迟时间；
2.PDelay_Req报文离开物理层时，slave利用本地时钟获得T1时间戳；
3.PDelay_Req报文到达应答方物理层，master利用本地时钟获得T2时间戳；
4.master生成一个PDelay_Resp报文并发送，将T2时间戳带给slave；
5.slave利用本地时钟可以捕获收到PDelay_Resp时的时间戳T4；
6.然后master会发送PDelay_Resp_Followup报文将T3带给slave；
这样slave就知道T1,T2,T3,T4这四个时间戳了，然后利用如下算式计算延迟时间：
计算延迟时间
其中R是在上节中提到的计算出的slave与master之间时钟频率的偏差。这种计算方法中，认为信道是对称的，即报文从slave到master和从master到slave所经历的延时是一样的。
时间同步：
根据上文计算出延迟时间和频率差异之后，slave就可以利用master不断发送的sync和follow_up报文将自己的时钟与master进行同步了。
具体的同步方式如下图所示：
将slave的时钟与master同步
计算式如下所示：
在上述计算式中，Tb是slave在某时刻的本地时间戳，Ta是该时刻master上的本地时间戳。同步的目的，就是根据Tb可以推算出Ta的值。在这个计算式中，slave通过sync和follow_up报文获得T1和T2，delay和R在之前的延迟时间和频率差异计算中已经获得。所以，slave能够根据本地时间戳Tb计算出master上的时间戳Ta，时间同步就实现了。
以上是我对gPTP协议的粗浅理解，抛砖引玉，如有疏漏，还请指正。

如何平衡AUTOSAR、IEEE和TSN？
车辆上的各种系统功能需要精确同步ECU之间的基本时间基准。由于以太网在汽车中的应用，开发人员和系统架构师需要通过某种方式来解决时间同步的措施。因为现有的方法不能用于以太网。不同领域的专家成立了委员会，致力于将以太网应用于要求高时间精度的任务中。
汽车上搭载的以太网应用范围广泛。除了使用摄像头和传感器(雷达)的先进驾驶辅助系统(ADAS)、实时音频/视频流媒体、与各种物理域同步的主干之外，板载数据记录也是此类使用案例中的一部分。此外，通过以太网网络连接的设备当然需要与其他物理系统(如CAN和FlexRay)同步。
以太网是以计算机网络和办公环境为前提而产生的标准，不具备技术应用所需的实时性能。交换机连接的以太网拓扑减少了网络访问过程中不必要的冲突，但这并不能实现完全确定的行为。特别是时间同步的精确任务需要传输路径上的传播时间以及交换机和网关相关延迟时间的任何信息。
在控制连接到以太网的系统时，这是不可避免的问题，也是为什么各种标准化组织正在努力向以太网添加实时性能，包括时间同步机制。目前，汽车行业使用的时间同步的主要方法是制定AUTOSAR 4.2.2、IEEE802.1AS和音频/Video Bridging任务组(现为TSN(Time Sensitive Networking)任务组)。基于修订版的IEEE802.1AS-rev。


AUTOSAR的Global time概念
AUTOSAR 4.2.2概念提供静态定义的GlobalTime Master(GTM)，该ECU将整个网络的精度最高的时间赋予到GTM。派生的子域可以扩展到不同的物理媒体。Time Gateway以一个从端口为起点，通过一个或多个主端口，将时间传递到端点(Time Slave)或其他Time Gateway。同步的时间必须根据这些网关内部处理所需的延迟时间进行修改。作为另一种方式，AUTOSAR也允许单独设置独立的时间库，并将当前时间从每个网关“注入”到它们中。
同步处理的细节取决于网络类型。如果是CAN或以太网，Time Slave会将发送方的时间戳与自己的接收时间戳进行比较，以校正接收到的Global time基础。FlexRay是一个确定性系统，周期时间固定，严格按照预定义的时间模式运行，因此同步比这简单，时间由FlexRay时钟隐式提供。CAN总是以软件计算时间戳，而以太网则以软件或硬件计算。此外，CAN和FlexRay最多可实现16个时域。相比之下，以太网只在一个时域，即“Global Time Domain”中运行。


以太网ECU同步的基础：IEEE802.1AS
从AUTOSAR 4.2.1开始，同步时间库管理器(StbM)现在可用。它将FlexRay、CAN和以太网总线特定的基于时间的生成器(BusTime Sync Provider Module)抽象为运行时环境，以便在应用程序中使用“演示时间”。在各个物理总线上使用的个别协议在TimeSync模块中实现，以太网的BusProvider基于IEEE802.1的“generalized Precision Time”使用“协议(GPTP)”。为了使其符合汽车中的常见用例，需要在AUTOSAR范围内进行各种更改，添加，有时限制。
在介绍以太网与CAN和FlexRay之间的区别时，我们先从CAN和FlexRay同步的基本特性来介绍一下。

两者有16个同步时间库和可选的最多16个静态连接的偏移时间库。在CAN上，时间信息通过两条消息传输。第一条消息包含秒信息，第二条消息包含纳秒信息。因此，为了检测可能在纳秒范围内出现的溢出，第二条消息包含溢出检测。“Time Gateway Synchronization Status”用于检测应用程序是否与子域和Global Time Master同步。它还使用序列计数和Cyclic Redundancy Check(CRC)。


汽车专用gPTP的实现
IEEE 802.1AS规定了在通过交换机连接的以太网网络上同步时间的标准方法。它由三个核心过程组成：同步时间传递(Sync/Follow_Up)、消息传播延迟时间测量(Pdelay)和最佳主时钟算法(BMCA)，负责实际同步的是由Sync消息和Follow_Up消息组成的两个步骤。Pdelay是一种专门的协议，用于测量两个端口之间的消息传播延迟时间。不仅如此，ECU还可以利用Pdelay来检测自己是否属于“时间同步系统”，即具有时间同步功能的网络。通过最佳主时钟算法，确定网络节点，如果可能的话，动态配置网络中包含的节点提供最佳系统时间的ECU，并将其设置为Global Master。
但是，在汽车上的实施在很大程度上与IEEE标准不同。IEEE允许动态设置，如网络拓扑结构和BMCA(Global Master选择)，而汽车中的大多数都是静态预定义的。这是创建唯一的系统描述和优化通信矩阵所必需的。其他不同之处在于，软件/硬件支持时间戳、是否存在有效载荷数据及其内容、出于安全原因需要为车辆配备VLAN等。
通过扩展交换机驱动程序提供端口信息
妨碍以太网上准确时间同步的一个重要挑战是，AUTOSAR 4.2.2版本对以太网交换机功能的响应是有限的。也就是说，交换机驱动程序不能将收到消息的端口号转发到上层。结果，Sync和Follow_Up消息的特定端口传输变得困难，交换机上的Pdelay机制基本上不可用。Pdelay机制无法将它们分配给各个通信端口，因为发送的Pdelay请求会触发多个响应(Pdelay_Resp/Pdelay_Resp_Follow_Up)。因此，Pdelay不提供有用的信息。此外，当前规范不允许交换机单独设置特定于端口的时间戳。无法确定开关内的延迟，也不能进行准确的时间修正。AUTOSAR 4.3改善了这种情况，并预计将增加支持的IEEE-802.1AS功能。具体来说，端口特定的交换机信息从交换机驱动程序和以太网驱动程序到基本软件组件的整体得到一致支持，现在也应该可以使用必要的输入输出的戳。
有效载荷数据：不可缺少的元素
在车辆中使用IEEE802.1AS时，还需要采取一些其他措施。与此相关的是“(汽车制造商特定的)有效载荷数据”、多个时域支持、冗余和备份策略等问题。有效载荷数据是Follow_Up消息中的附加信息，不受此标准覆盖。但是，这对于特殊的应用程序和功能来说是必不可少的，例如调试信息和其他状态信息。

作为解决这个问题的对策。将所需的附加信息存储在gPTP消息中包含的AUTOSAR特定类型长度值(TLV)字段中，TimeSlave根据设置评估或忽略该字段。
IEEE标准标准中时域的不足
IEEE802.1AS目前只提供一个时域。然而，汽车应用需要更多的时域来评估UTC时间、GPS时间和传感器特定信号。因此，gPTP消息标头中现有的域号必须具有大于0的数量。在IEEE 802.1AS中，允许的域号目前只有“0”，其他数值将被节点忽略。当前的TSN规范(IEEE 802.1AS-ref)以添加到IEEE 802.1AS的形式新包含了至少一个时域。然而，这不足以满足汽车的要求。为了解决这个问题，AUTOSAR允许定义额外的时域。
使用备份标准实现容错同步
在未来的车辆架构和AUTOSAR版本中，人们越来越重视安全和安全问题。与此同时，在静态定义的唯一时间生成器(Global Time Master)发生故障的情况下，备份主机，一般是如何处理冗余概念的问题突然浮现出来。为此，至少需要另一个作为备份主机继续工作的时间生成器。目前的最佳标准时钟算法不能解决这个问题。BMCA的速度相对较慢，并且基于超时检测工作，因此ECU已经进入了它本来应该避免的同步超时状态。标准必须防止同步超时的发生，而不是通过相互代表对方进行操作而不是这样的形式。标准制定委员会将继续讨论包括这些在内的大量问题。


结论
IEEE802.1AS是在以太网上实现时间同步的适当参考资料，符合IEEE标准的gPTP协议可用于信息娱乐领域。很明显，在未来的TSN标准中会有更多的汽车需求，但它在多大程度上是全面的，这还是个未知数。无论如何，IEEE和AUTOSAR在相互补充的同时不断发展。但是，由于它们的发布周期的差异，它的完成还需要很长的时间。
重要的是，系统架构师、开发人员和供应商能够高效、经济地推进以太网项目。载体开发工具可支持特定以太网硬件，例如矢量ECU和网络测试工具CANoe和AUTOSAR基本软件中的MICROSAR。这些产品支持基于AUTOSAR的gPTP或符合IEEE的gPTP的时间同步。它还提供功能和软件解决方案，用于将同步时间用于音频/视频流媒体等。

为了传输更高带宽的音视频流并且满足汽车内低延迟、高可靠性传输的要求，IEEE 802.1音视频桥接（Audio Video Bridging, AVB）工作组定义了一种基于一套独立于TCP/IP协议族的通信协议的实现方法。涉及到的协议大体如下：
IEEE802.1Qat，流预留协议（Stream Reservation Protocol, SRP）,为特定的数据流预留带宽的标准；
IEEE802.1Qav，时间敏感流的转发和排队规则（Forwarding and Queuing for Time-Sensitive Streams, FQTSS）,流量整形的标准，可保证带宽和QoS的延迟参数。
以及其他的上层通信方案：
IEEE1722，音视频桥接传输协议（Audio/Video Bridging Transport Protocol, AVBTP）
IEEE 1733，实时传输协议（Real-time Transport Protocol, RTP）;
IEEE802.1AS， 广义精确时钟协议（Generalized Precision Time Protocol, gPTP），确保收发的终端之间严格时间同步的标准。
本文将对gPTP协议进行简单介绍和分析。
gPTP的用途是将车载网络中各个节点的时钟进行同步，因为各个节点的时钟都是互相独立运行的，而有些应用需要各个节点步调一致地执行。比如播放音频和视频的任务可能在不同的节点上实现，那么这两个设备必须要有相同的时钟基准，否则可能出现画面和声音对不上的情况。时钟同步本质上就是各方对一下表。
gPTP是基于主从关系的，也就是说，一个局部网络中的所有节点以master的时钟为基准，将自己的本地时钟与master的时钟进行同步。下面是个简单的示意图，需要注意的是，时钟同步是层层递进式的，slave也可以作为下一层网络的master。
gPTP协议位于OSI模型的层2之上，可以依赖于以太网传输。gPTP报文利用以太网传输时，MAC报文头中的Ethertype = 0x88F7。
gPTP报文由3部分组成：
Header （对所有gPTP都一样）
Body （取决于gPTP 报文类型）
TLV(type length value)
其中header是所有类型的gPTP报文都有的，它有34个字节，结构如下图所示：
报文头中的message Type标识了gPTP报文的类型，类型取值范围如下图所示：
接下来对gPTP协议的具体任务和实现流程的介绍中将涉及到上图中的报文类型。
gPTP要完成的主要任务包括：
选择最佳主时钟
频率同步
延迟时间测量
时间同步
选择最佳主时钟：
gPTP的主时钟选择机制是“最佳主时钟算法（BMCA）”。选择算法启动时，所有可以成为主时钟的端点都会参与竞争。要启动BMCA算法，所有端点都通过发送Announce报文（前文中提到过的message Type）来宣告自己的能力。各个端点比较自己与其他端点的相关字段值，胜出者作为主时钟端点。但车辆是一个封闭的网络，不会出现节点总变化的情况，所以车载应用中，主时钟往往都是固定的，比如网关。
频率同步：
网络中各个节点的时钟的频率并不总是完全一致。比如，在实际为100秒的时间段时间，A节点的时钟可能计时为90秒，B节点的时钟可能计时为110秒（实际中不可能出现如此大的偏差，但偏差总是有的，这里只是举例说明）。所以gPTP Slave的时钟频率需要与Master相匹配。频率同步的实现方式如下图所示：
在实际的gPTP通信中，master会不停地发送Sync和Follow-up，slave能够测量出自己收到Sync报文的时间，即上图中的T2和T4（这个时间是以slave的本地时钟为基准的）。在每个sync报文之后，master都会发送一个follow-up报文，用来告诉slave自己发送上一条sync报文时的时间戳（以master的本地时钟为基准）。没有follow-up报文的话，slave无法Sync报文的实际发送时间，即上图中的T1和T3。有了T1、T3和T2、T4，slave就能够计算出自己的时钟频率与master之间的偏差，计算式如下图所示：
延迟时间测量：
为了将自己的时钟与master同步，slave必须测量出自己与master之间报文传递的延迟时间。时延测量使用到的上文中提到的PDelay_Req、PDelay_Resp和PDelay_Resp_Followup三种gPTP报文。具体的测量方式如下图所示：
1.首先slave发送PDelay_Req报文，请求测量延迟时间；
2.PDelay_Req报文离开物理层时，slave利用本地时钟获得T1时间戳；
3.PDelay_Req报文到达应答方物理层，master利用本地时钟获得T2时间戳；
4.master生成一个PDelay_Resp报文并发送，将T2时间戳带给slave；
5.slave利用本地时钟可以捕获收到PDelay_Resp时的时间戳T4；
6.然后master会发送PDelay_Resp_Followup报文将T3带给slave；
这样slave就知道T1,T2,T3,T4这四个时间戳了，然后利用如下算式计算延迟时间：
其中R是在上节中提到的计算出的slave与master之间时钟频率的偏差。这种计算方法中，认为信道是对称的，即报文从slave到master和从master到slave所经历的延时是一样的。
时间同步：
根据上文计算出延迟时间和频率差异之后，slave就可以利用master不断发送的sync和follow_up报文将自己的时钟与master进行同步了。
具体的同步方式如下图所示：
计算式如下所示：
在上述计算式中，Tb是slave在某时刻的本地时间戳，Ta是该时刻master上的本地时间戳。同步的目的，就是根据Tb可以推算出Ta的值。在这个计算式中，slave通过sync和follow_up报文获得T1和T2，delay和R在之前的延迟时间和频率差异计算中已经获得。所以，slave能够根据本地时间戳Tb计算出master上的时间戳Ta，时间同步就实现了。
以上是我对gPTP协议的粗浅理解，抛砖引玉，如有疏漏，还请指正。 

为了传输更高带宽的音视频流并且满足汽车内低延迟、高可靠性传输的要求，IEEE 802.1音视频桥接（Audio Video Bridging, AVB）工作组定义了一种基于一套独立于TCP/IP协议族的通信协议的实现方法。涉及到的协议大体如下：
IEEE802.1Qat，流预留协议（Stream Reservation Protocol, SRP）,为特定的数据流预留带宽的标准；
IEEE802.1Qav，时间敏感流的转发和排队规则（Forwarding and Queuing for Time-Sensitive Streams, FQTSS）,流量整形的标准，可保证带宽和QoS的延迟参数。
以及其他的上层通信方案：
IEEE1722，音视频桥接传输协议（Audio/Video Bridging Transport Protocol, AVBTP）
IEEE 1733，实时传输协议（Real-time Transport Protocol, RTP）;
IEEE802.1AS， 广义精确时钟协议（Generalized Precision Time Protocol, gPTP），确保收发的终端之间严格时间同步的标准。
本文将对gPTP协议进行简单介绍和分析。
gPTP的用途是将车载网络中各个节点的时钟进行同步，因为各个节点的时钟都是互相独立运行的，而有些应用需要各个节点步调一致地执行。比如播放音频和视频的任务可能在不同的节点上实现，那么这两个设备必须要有相同的时钟基准，否则可能出现画面和声音对不上的情况。时钟同步本质上就是各方对一下表。
gPTP是基于主从关系的，也就是说，一个局部网络中的所有节点以master的时钟为基准，将自己的本地时钟与master的时钟进行同步。下面是个简单的示意图，需要注意的是，时钟同步是层层递进式的，slave也可以作为下一层网络的master。
gPTP协议位于OSI模型的层2之上，可以依赖于以太网传输。gPTP报文利用以太网传输时，MAC报文头中的Ethertype = 0x88F7。
gPTP报文由3部分组成：
Header （对所有gPTP都一样）
Body （取决于gPTP 报文类型）
TLV(type length value)
其中header是所有类型的gPTP报文都有的，它有34个字节，结构如下图所示：
报文头中的message Type标识了gPTP报文的类型，类型取值范围如下图所示：
接下来对gPTP协议的具体任务和实现流程的介绍中将涉及到上图中的报文类型。
gPTP要完成的主要任务包括：
选择最佳主时钟
频率同步
延迟时间测量
时间同步
选择最佳主时钟：
gPTP的主时钟选择机制是“最佳主时钟算法（BMCA）”。选择算法启动时，所有可以成为主时钟的端点都会参与竞争。要启动BMCA算法，所有端点都通过发送Announce报文（前文中提到过的message Type）来宣告自己的能力。各个端点比较自己与其他端点的相关字段值，胜出者作为主时钟端点。但车辆是一个封闭的网络，不会出现节点总变化的情况，所以车载应用中，主时钟往往都是固定的，比如网关。
频率同步：
网络中各个节点的时钟的频率并不总是完全一致。比如，在实际为100秒的时间段时间，A节点的时钟可能计时为90秒，B节点的时钟可能计时为110秒（实际中不可能出现如此大的偏差，但偏差总是有的，这里只是举例说明）。所以gPTP Slave的时钟频率需要与Master相匹配。频率同步的实现方式如下图所示：
在实际的gPTP通信中，master会不停地发送Sync和Follow-up，slave能够测量出自己收到Sync报文的时间，即上图中的T2和T4（这个时间是以slave的本地时钟为基准的）。在每个sync报文之后，master都会发送一个follow-up报文，用来告诉slave自己发送上一条sync报文时的时间戳（以master的本地时钟为基准）。没有follow-up报文的话，slave无法Sync报文的实际发送时间，即上图中的T1和T3。有了T1、T3和T2、T4，slave就能够计算出自己的时钟频率与master之间的偏差，计算式如下图所示：
延迟时间测量：
为了将自己的时钟与master同步，slave必须测量出自己与master之间报文传递的延迟时间。时延测量使用到的上文中提到的PDelay_Req、PDelay_Resp和PDelay_Resp_Followup三种gPTP报文。具体的测量方式如下图所示：
1.首先slave发送PDelay_Req报文，请求测量延迟时间；
2.PDelay_Req报文离开物理层时，slave利用本地时钟获得T1时间戳；
3.PDelay_Req报文到达应答方物理层，master利用本地时钟获得T2时间戳；
4.master生成一个PDelay_Resp报文并发送，将T2时间戳带给slave；
5.slave利用本地时钟可以捕获收到PDelay_Resp时的时间戳T4；
6.然后master会发送PDelay_Resp_Followup报文将T3带给slave；
这样slave就知道T1,T2,T3,T4这四个时间戳了，然后利用如下算式计算延迟时间：
其中R是在上节中提到的计算出的slave与master之间时钟频率的偏差。这种计算方法中，认为信道是对称的，即报文从slave到master和从master到slave所经历的延时是一样的。
时间同步：
根据上文计算出延迟时间和频率差异之后，slave就可以利用master不断发送的sync和follow_up报文将自己的时钟与master进行同步了。
具体的同步方式如下图所示：
计算式如下所示：
在上述计算式中，Tb是slave在某时刻的本地时间戳，Ta是该时刻master上的本地时间戳。同步的目的，就是根据Tb可以推算出Ta的值。在这个计算式中，slave通过sync和follow_up报文获得T1和T2，delay和R在之前的延迟时间和频率差异计算中已经获得。所以，slave能够根据本地时间戳Tb计算出master上的时间戳Ta，时间同步就实现了。
以上是我对gPTP协议的粗浅理解，抛砖引玉，如有疏漏，还请指正。