CN103731252A - 一种ieee1588单播协商机制改进方法及系统 - Google Patents

Abstract

本发明公开了一种IEEE1588单播协商机制改进方法及系统，所述方法包括：对单播协商信息内容进行编码；基于所述编码后的单播协商信息，主时钟设备与从时钟设备建立连接并进行单播通信，解决了现有技术中现有的单播协商机制存在机制复杂、可靠性不高、效率较低、影响主从时钟设备处理能力、增加额外网络带宽，进而会影响主从时钟同步精度的技术问题，实现了单播协商机制简单、效率高，提高了主从时钟设备处理能力，节省网络宽带，对单播协商机制功能进行了扩展的技术效果。

Description

一种IEEE1588单播协商机制改进方法及系统

技术领域

本发明涉及电子信息技术领域，尤其涉及一种IEEE1588单播协商机制改进方法及系统。

背景技术

IEEE 1588是网络测量和控制系统的精确时钟同步协议（简称PTP）标准，该标准目前已发展到v2版本。PTP协议采用主从同步方式，在主从设备之间提供了基于网络数据包发送和接收时间戳的时钟同步功能。时钟同步精度主要取决于时间戳的准确性，时间戳的准确性又和系统获取时间戳的位置有很大关系。获取时间戳的位置一般有三个：硬件层、驱动层、应用层，越靠近物理层准确性越高。PTP协议采用软硬件相结合的方式，在接近物理层由硬件获取时间戳值，主从设备之间的时钟同步精度可达十纳秒级。IEEE 1588v2定义了多种数据包的传输协议，其中最主要且应用最广的是UDP/IP（三层协议，网络层）和IEEE802.3（二层协议，以太数据链路层）。二层PTP包和三层PTP包的数据封装格式不同，但数据内容是相同的。

PTP协议提供两种时延测量机制：E2E时延测量机制和P2P时延测量机制，两种测量机制的方法有所不同，适用于不同的场合。P2P时延机制用于点对点的时延测量，强调两个节点之间的时延测量，一般和透明时钟设备一起使用，有助于消除线路时延不对称性的影响。

两种时延测量机制都需要从时钟主动向主时钟发送时延请求帧，主时钟处理并回复时延请求帧。不同点在于，E2E时延机制中，主时钟将时延请求帧（delay_req）的接收时间戳插入时延回复帧（delay_resp）中并发送给从时钟。P2P时延机制中，主时钟计算时延请求帧（pdelay_req）在本系统的驻留时间，将驻留时间累加到时延回复帧（pdelay_resp）的纠正域（correctField）并发送给从时钟。主时钟在收到时延请求帧后，应该尽快处理并回复，以减小驻留时间。

PTP通信方式有两种：组播方式和单播方式，根据数据包传输协议栈的不同，又可分为三层组播/单播方式和二层组播/单播方式。组播方式下，目的组播地址和目的端口号（UDP）是固定的（PTP协议定义），PTP设备上电时需加入指定的多播组，加入多播组的PTP设备之间才可以相互通信。单播方式下，目的地址为接收端的目的地址（三层模式下是IP地址，二层模式下是MAC地址），PTP主从设备之间首先需要通过单播协商信令建立连接，然后才能点对点进行单播通信。组播通信方式比单播通信方式在实现和配置上要简单，能节省主时钟的系统资源，但组播包容易形成组播风暴、带宽占用率高（交换机的复制和转发）。单播通信方式在效率、可靠性方面比组播通信方式高，但实现起来比较复杂。单播主从时钟需要处理单播协商信令，主时钟还需要在本地管理从时钟的地址信息。1588单播协商机制的优点是：主从时钟可以协商发送数据包类型以及持续发送时间，从时钟可以按需定制同步服务，从时钟操作的灵活性、主动性大大提高。但由于1588单播协商机制实现的复杂性，其应用受到了限制。

目前，IEEE 1588v2协议定义了单播通信方式及相应的单播协商机制，单播信令信息格式如图1所示。图1中的内容包括34字节的1588帧头信息、10个字节的目标端口身份信息以及TLV（类型、长度、值）信息。图1为IEEE1588v2定义的数据帧头格式，图2为IEEE 1588v2定义的单播协商TLV信令格式，图3为IEEE 1588v2定义的时延请求帧和时延回复帧格式。

用于单播协商机制的TLV信令消息类型包括：单播请求传输信令（REQUEST_UNICAST_TRANSMISSION TLV），同意单播请求传输信令（GRANT_UNICAST_TRANSMISSION TLV），取消单播请求传输信令（CANCEL_UNICAST_TRANSMISSION TLV），确认取消单播传输信令（ACKNOWLEDGE_CANCEL_UNICAST_TRANSMISSION TLV），使能单播协商机制传输信令（UNICAST_NEGOTIATION_ENABLE TLV）。

以单播请求TLV信令消息格式为例，说明TLV消息的基本含义。其他信令消息格式内容可参考1588协议，含义类似。tlvType域表示TLV信令类型，含义如表1所示。

表1

lengthField域表示信息长度，不包括tlvType域和lengthField域。Messagetype域表示请求的单播消息类型，含义如表2。

表2

logInterMessagePeriod域表示该消息的发包间隔，以2的幂次方表示，含义同1588协议。

durationField域表示发送messageType指定消息的持续时间，单位为秒，也称老化时间。

单播协商机制的基本原则：单播请求时，需要同意；取消单播请求时，需要确认；同意或确认后才生效，否则无效。1588单播协商机制的基本流程如图4所示，具体为：

（1）slave（从时钟）通过发REQUEST_UNICAST_TRANSMISSION TLV信令消息向mater（主时钟）提出单播请求。该单播请求包中包含了请求发送数据包的类型及持续时间等信息。

（2）master收到单播请求TLV信令消息后，如果同意该请求就回复GRANT_UNICAST_TRANSMISSION TLV信令消息。如果不同意，则发CANCEL_UNICAST_TRANSMISSION TLV消息。

（3）slave收到master的拒绝TLV信令消息后，需要再发确认TLV消息ACKNOWLEDGE_CANCEL_UNICAST_TRANSMISSION TLV，表示协商不成功。

（4）slave收到master的同意TLV信令消息后，无需再回复，表示协商成功。

（5）slave需要周期性重复以上（1）~（4）步，重复周期应小于durationField域规定时间。

（6）master如果在durationField时间内未收到单播请求TLV信令，则停止发送已请求的数据包，直到下一周期单播协商成功。

（7）master和slave均可主动发送CANCEL_UNICAST_TRANSMISSION TLV消息，取消单播消息发送，收到对方确认信令后生效。

（8）通过发UNICAST_NEGOTIATION_ENABLE TLV信令可取消单播协商机制。取消单播协商机制后，master和slave不再发送或响应单播TLV信令。

但本申请发明人在实现本申请实施例中发明技术方案的过程中，发现上述技术至少存在如下技术问题：

IEEE 1588v2单播协商机制的缺点主要有以下几个方面：

1、单播协商机制复杂，效率低。采用复杂的信令协商机制，TLV信令种类较多，需要经过请求、回复（同意、拒绝）、确认等多个步骤才能建立单播连接。由于协议复杂，导致可靠性不高，效率较低。

2、实现复杂，影响主从时钟设备的处理能力。主时钟设备的处理能力，是1588设备的一个重要指标。对于1588主时钟设备来说，实现1588单播协商机制需要额外处理单播协商信令，增加了处理器的负担，降低了主时钟设备的处理能力。正常情况下，主时钟设备只需要监听事件消息UDP端口并接收和处理事件消息即可。三层单播工作模式下，1588单播协商信令采用通用消息端口（通用消息和事件消息采用不同的UDP端口号），主时钟还需要监听通用消息UDP端口并接收和处理单播协商信令（因端口号不同），大大增加了主时钟的处理负担，从而对主时钟设备的处理能力造成较大影响，尤其是在一个主时钟对多个从时钟的应用环境下。二层单播工作模式下，虽然不存在UDP端口不同的问题，但主时钟设备仍然需要处理单播协商信令。

对于1588从时钟设备来说，不存在UDP端口号不同的问题（需要同时监听通用消息端口和事件消息端口），但需要定期发送和处理单播协商信令，同样会增加从时钟设备处理器的负担，从而会影响其处理能力和效率。

3、增加网络占用带宽，影响同步精度。如附图中单播信令帧格式所示，以单播请求TLV信令为例，其帧长度约为44字节（PTP帧头加TLV信息），相当于同步帧sync的帧长。周期性发送的单播协商信令无疑会增加网络占用带宽，网络带宽变化会对数据包时延变化（PDV）造成影响，从而会影响主从时钟同步精度。一对一同步情况下，单播协商信令对网络带宽及同步精度影响不明显。一对多同步情况下，影响比较明显。实际应用中，往往一个主时钟需要同步几十甚至上百个从时钟。

综上所述，在现有技术中，由于现有的单播协商机制采用复杂的信令协商机制，TLV信令种类较多，现有的单播协商机制实现复杂以及增加网络占用带宽，所以现有的单播协商机制存在机制复杂、可靠性不高、效率较低、影响主从时钟设备处理能力、增加额外网络带宽，进而会影响主从时钟同步精度的技术问题。

发明内容

本申请实施例通过提供一种IEEE1588单播协商机制改进方法及系统，解决了现有技术中现有的单播协商机制存在机制复杂、可靠性不高、效率较低、影响主从时钟设备处理能力、增加额外网络带宽，进而会影响主从时钟同步精度的技术问题，实现了单播协商机制简单、效率高，提高了主从时钟设备处理能力，节省网络宽带，对单播协商机制功能进行了扩展的技术效果。

为解决上述技术问题，本申请实施例一方面提供了一种IEEE1588单播协商机制改进方法，所述方法包括：

对单播协商信息内容进行编码；

基于所述编码后的单播协商信息，主时钟设备与从时钟设备建立连接并进行单播通信。

进一步的，所述基于所述编码后的单播协商信息，主时钟设备与从时钟设备建立连接并进行单播通信具体包括：

所述从时钟设备定期向所述主时钟设备发送时延请求帧，所述时延请求帧中携带单播协商信息编码；

所述主时钟设备接收所述时延请求帧，向所述从时钟设备发送时延请求回复帧，所述时延请求回复帧中携带所述单播协商信息编码；

所述主从时钟设备单播协商成功后，所述主时钟设备向所述从时钟设备发送相应的单播数据帧，其中，协商不成功时，所述主时钟设备不发送单播数据帧；

所述主时钟设备超过老化时间未收到携带有效单播协商信息编码的时延请求帧时，停止向所述从时钟设备发送单播数据帧，直到再次收到时延请求帧；

所述单播协商机制使能时，所述主从时钟设备通过时延请求/回复帧中携带的单播协商信息编码建立连接；所述单播协商机制不使能时，所述主从时钟设备通过时延请求帧建立连接。

进一步的，所述对单播协商信息内容进行编码具体为：利用时延请求帧/回复帧的保留域来携带单播协商信息。

进一步的，所述时延请求帧具体包括：delay_req帧和pdelay_req帧；所述时延回复帧具体包括：delay_resp帧和pdelay_resp帧。

进一步的，所述时延请求帧/回复帧的保留域为一预设保留域。

进一步的，所述单播协商机制的基本功能包括但不限于：单播数据帧请求、同意、确认、取消及设置数据帧持续发送时间、单播协商使能。

进一步的，所述对单播协商信息内容进行编码具体为利用4个比特位编码来实现所述单播协商机制的基本功能。

另一方面，本申请实例还提供一种IEEE1588单播协商机制改进系统，所述系统包括：

网络接口模块、CPU模块、输入输出模块、时钟模块、1588时戳处理模块、MAC模块、PHY模块，其中，所述CPU模块为完成PTP协议处理功能的模块，所述PTP协议包含采用上述方法的单播协商机制；

其中，所述CPU模块与所述1588时戳处理模块、所述输入输出模块、所述MAC模块连接，所述输入输出模块与所述时钟模块、所述CPU模块连接，所述时钟模块与所述CPU模块、所述输入输出模块、所述1588时戳处理模块、所述PHY模块连接，所述1588时戳处理模块与所述时钟模块、所述MAC模块、所述PHY模块连接、所述CPU模块连接，所述MAC模块与所述CPU模块、所述PHY模块、所述1588时戳处理模块连接，所述PHY模块与所述MAC模块、所述1588时戳处理模块、所述CPU模块、所述时钟模块连接。

本申请实施例中提供的一个或多个技术方案，至少具有如下技术效果或优点：

由于采用了利用时延请求帧/回复帧的保留域来携带单播协商信息，在不影响PTP时延请求机制和流程的情况下，实现1588v2定义的单播协商机制基本功能，且本方法及实现系统的主从时钟设备不需要额外监听信令消息接收端口，也不需要处理1588单播协商TLV信令的技术手段，所以，有效解决了现有技术中现有的单播协商机制存在机制复杂、可靠性不高、效率较低、影响主从时钟设备处理能力、增加额外网络带宽，进而会影响主从时钟同步精度的技术问题，进而实现了单播协商机制简单、效率高，提高了主从时钟设备处理能力，节省网络宽带，对单播协商机制功能进行了扩展的技术效果。

附图说明

图1为本申请实施例中IEEE1588v2定义的数据帧头格式；

图2为本申请实施例中IEEE 1588v2定义的单播协商TLV信令格式；

图3为本申请实施例中IEEE1588v2定义的时延请求帧和时延回复帧格式；

图4为本申请实施例中一种IEEE1588单播协商机制改进方法流程图；

图5为传统的IEEE 1588v2定义的单播信令协商基本流程示意图；

图6为应用本申请方法改进后的1588单播通信方式示意图；

图7为本申请实施例中一种IEEE1588单播协商机制改进系统的示意图；

图8为本发明所述的主从时钟设备单播协商使能时的基本处理流程；

图9为本发明所述的主从时钟设备单播协商不使能时的基本处理流程。

具体实施方式

本申请实施例通过提供一种IEEE1588单播协商机制改进方法及系统，解决了现有技术中现有的单播协商机制存在机制复杂、可靠性不高、效率较低、影响主从时钟设备处理能力、增加额外网络带宽，进而会影响主从时钟同步精度的技术问题，实现了单播协商机制简单、效率高，提高了主从时钟设备处理能力，节省网络宽带，对单播协商机制功能进行了扩展的技术效果。

本申请实施中的技术方案为解决上述技术问题。总体思路如下：

首先对单播协商信息内容进行编码；然后基于所述编码后的单播协商信息，主时钟设备与从时钟设备建立连接并进行单播通信，即采用了利用时延请求帧/回复帧的保留域来携带单播协商信息，在不影响PTP时延请求机制和流程的情况下，实现1588v2定义的单播协商机制基本功能，且本方法及实现系统的主从时钟设备不需要额外监听信令消息接收端口，也不需要处理1588单播协商TLV信令的技术手段，所以，有效解决了现有技术中现有的单播协商机制存在的机制复杂、可靠性不高、效率较低、影响主从时钟设备处理能力、增加额外网络带宽，进而会影响主从时钟同步精度的技术问题，进而实现了单播协商机制简单、效率高，提高了主时钟处理能力，节省网络宽带，对单播协商机制功能进行了扩展的技术效果。

为了更好的理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明。

实施例一

在实施例一中，提供了一种IEEE1588单播协商机制改进方法，图5为传统的IEEE 1588v2定义的单播信令协商基本流程示意图，图6为应用本申请方法改进后的1588单播通信方式示意图，请参考图4，图4为本申请实施例中一种IEEE1588单播协商机制改进方法流程图，所述方法包括：

S10，对单播协商信息内容进行编码。

其中，在本申请实施例中，所述对单播协商信息内容进行编码具体为：利用时延请求帧/回复帧的保留域来携带单播协商信息。

其中，在本申请实施例中，所述时延请求帧具体包括：delay_req帧和pdelay_req帧；所述时延回复帧具体包括：delay_resp帧和pdelay_resp帧。在实际应用中，delay_req帧和delay_resp帧用于端到端时延测量机制（E2E）中，pdelay_req帧和pdelay_resp帧用于点到点时延测量机制（P2P）中。所述时延请求帧/回复帧的保留域为帧头信息字节1的高4位，但不限于此。

其中，在本申请实施例中，所述保留域的选择如下：

PTP时延请求帧/回复帧的保留域是指PTP帧格式中的reserved区域（参考图1、图3），主要有：（1）帧头信息字节1（offset）的高4个比特，目前暂未定义及使用。（2）帧头信息字节5。已使用，一般用于恢复时延请求帧接收时间戳的整数秒。（3）帧头信息字节16~字节19，已使用，一般用于恢复时延请求帧接收时间戳的小数秒。（4）delay_resp帧字节44~字节54，已使用，用于携带接收时间戳值。（5）pdelay_req帧字节44~字节54，未使用，以上所述保留域（2）、（3）、（4）已被使用，保留域（5）仅适用pdelay_req帧，无法通用也不利于统一编码。因此只有PTP帧头保留域（1）可以利用。

其中，在本申请实施例中，利用时延请求帧/回复帧的保留域携带单播协商信息，考虑到不改变现有时延请求帧/回复帧的格式及处理方便，因此采用PTP帧头信息字节1的保留域。该保留域仅有4个比特，通过有效编码可以携带1588单播协商基本功能信息，由于保留域位数有限，无法继续扩展其他功能。利用本发明所述方法的思想，可以扩大保留域范围。本发明所述的时延请求包的保留域不限于PTP帧头信息字节1的保留域。在不考虑时延请求/回复数据帧格式完整性及处理难易度情况下，保留域的选择替代方案如下：

改变时延请求帧/回复帧的帧格式，增加TLV信息保留域，用于单播模式下传递单播协商TLV信息。TLV信息保留域可附在原时延请求帧/回复帧的后面，TLV信息定义可采用IEEE 1588单播协商机制方式。

利用时延请求帧/回复帧已使用的保留域，比如帧头信息中已使用的保留域。PTP帧头保留域一般用于接收端插入数据包接收时间戳信息，如果利用此保留域传递单播协商信息编码，那么在插入接收时间戳信息之前就要取出单播协商信息编码。时间戳插入功能一般在靠近物理层由硬件模块（1588时戳处理模块）完成，因此需要软件模块（CPU模块）和硬件模块交互来完成此功能。所述保留域的选择替代方案均在本申请的保护范围之内。

其中，在本申请实施例中，根据IEEE 1588单播协商机制及TLV信令的定义，所述单播协商机制的基本功能包括单播数据帧请求、同意、确认、取消及设置数据帧持续发送时间等。

其中，在本申请实施例中，单播协商信息包括单播数据帧请求、同意、确认、取消及数据帧持续时间、单播协商使能信息。相应的单播协商基本功能包括数据帧请求、同意、确认、取消及设置数据帧持续发送时间、单播协商使能功能。

其中，在本申请实施例中，所述的单播数据帧类型包括sync、announce、delay_resp、pdelay_resp。

其中，在本申请实施例中，所述的单播协商信息编码指利用4个比特位编码实现所述的单播协商基本功能。

其中，在本申请实施例中，具体编码方式可根据功能需要灵活设置，下面给出了两种单播协商信息编码方式，但不限于此。两种编码方式都可达到相同的目的。

单播协商信息编码及含义：假设PTP帧头信息字节1的高4位比特代号分别为“b7、b6、b5、b4”，编码方式一如表3所示，编码方式二如表4所示。

表3

表4

在步骤S10之后，本申请实施例的方法便进入步骤S20，即：基于所述编码后的单播协商信息，主时钟设备与从时钟设备建立连接并进行单播通信。

其中，在本申请实施例中，所述基于所述编码后的单播协商信息，主时钟设备与从时钟设备建立连接并进行单播通信具体包括：

所述从时钟设备定期向所述主时钟设备发送时延请求帧，所述时延请求帧中携带单播协商信息编码；

所述主时钟设备接收所述时延请求帧，向所述从时钟设备发送时延请求回复帧，所述时延请求回复帧中携带所述单播协商信息编码；

所述主从时钟设备单播协商成功后，所述主时钟设备向所述从时钟设备发送相应的单播数据帧，其中，协商不成功时，所述主时钟设备不发送单播数据帧；

所述单播协商机制使能时，所述主从时钟设备通过时延请求/回复帧中携带的单播协商信息编码建立连接；所述单播协商机制不使能时，所述主从时钟设备通过时延请求帧建立连接。

所述主时钟设备超过老化时间未收到携带有效单播协商信息编码的时延请求帧时，停止向所述从时钟设备发送单播数据包，直到再次收到时延请求帧。

请参考图5，以从时钟请求sync单播帧为例来说明单播协商基本流程。假设主从时钟采用E2E时延测量机制，单播协商信息编码采用上述编码方式二。

1、从时钟发delay_req帧，帧头保留域为“0001”（请求单播sync包）。

2、主时钟收到delay_req后，回复delay_resp帧。delay_resp帧帧头保留域为“0001”时，则表示同意；delay_resp帧帧头保留域为“0101”时，则表示不同意。

3、主时钟主动取消发送单播sync帧时，delay_resp帧帧头保留域为“0101”（取消发送）。

4、从时钟主动取消单播请求时，delay_req帧帧头保留域为“0101”，主时钟收到该帧后，回复delay_resp帧，delay_resp帧帧头保留域值为“0001”（表示确认）。

5、从时钟需要设置单播sync帧的发送持续时间时（老化时间），delay_req帧的帧头保留域值为“10**”（比如“1011”，表示老化时间为160秒）。如果主时钟同意设置sync帧的发送持续时间，则delay_resp帧帧头保留域为“00**”；不同意时，delay_resp帧帧头保留域为“01**”。

6、从时钟主动取消单播协商机制时，delay_req帧帧头保留域为“0000”。主时钟回复delay_resp帧，delay_resp帧帧头保留域值为“0000”表示确认。从时钟收到确认消息后，以后发送的delay_req帧帧头保留域为无效值（保留编码）。

7、主时钟收到的delay_req帧帧头保留域为无效值时，不处理单播协商编码信息，回复的delay_resp帧帧头保留域也为无效值。从时钟收到delay_resp帧帧头保留域为无效值时，不处理单播协商编码信息。

对应实施例一中的方法，实施例一还提供一种IEEE1588单播协商机制改进系统，请参考图7，所述系统包括：网络接口模块、CPU模块10、输入输出模块20、时钟模块30、1588时戳处理模块40、MAC模块50、PHY模块60，其中，所述CPU模块10为完成PTP协议处理功能的模块，所述PTP协议包含采用上述方法的单播协商机制；其中，所述CPU模块10与所述1588时戳处理模块40、所述输入输出模块20、所述MAC模块50连接，所述输入输出模块20与所述时钟模块30、所述CPU模块10连接，所述时钟模块30与所述CPU模块10、所述输入输出模块20、所述1588时戳处理模块40、所述PHY模块60连接，所述1588时戳处理模块40与所述时钟模块30、所述MAC模块50、所述PHY模块60连接、所述CPU模块10连接，所述MAC模块50与所述CPU模块10、所述PHY模块60、所述1588时戳处理模块40连接，所述PHY模块60与所述MAC模块50、所述1588时戳处理模块40、所述CPU模块10、所述时钟模块30连接。

其中，在本申请实施例中，所述网络接口模块实现基本的以太网功能，所述1588时戳处理模块40实现IEEE 1588时间戳处理功能，为专用的支持1588功能的处理芯片，所述时钟模块30为系统提供时钟信号源，其频率可受控，所述CPU模块10完成PTP协议处理功能，其中包括实现本发明所述的IEEE 1588单播协商机制改进方法。

请参考图8，主从时钟设备单播协商使能时的处理流程为：

（1）从时钟设备主动向主时钟设备发送单播时延请求帧，主时钟设备接收时延请求帧并向从时钟设备发送单播时延回复帧。时延请求帧和时延回复帧中携带了单播协商编码信息。

（2）主时钟设备接收到从时钟设备发来的时延请求帧后，获得并解析单播协商编码信息。

（3）主时钟设备如果同意从时钟设备的请求，则向从时钟设备发送携带同意信息的时延回复帧。如果不同意，则发送携带不同意信息的时延回复帧。

（4）从时钟设备的请求内容包括单播数据包发送请求、单播协商使能或不使能请求、设置单播数据帧持续发送时间请求。

（5）主时钟设备同意从时钟设备的请求后，记录从时钟设备的IP地址（或MAC地址），更新本地客户表相关参数。

（6）主时钟设备根据本地客户表参数确定是否发送相应的单播数据帧。主时钟设备超过老化时间（单播数据包持续发送时间）未收到客户的单播请求信息时，停止向该客户发送相应的单播数据包并更新本地客户表相关参数，直到再次收到请求信息。

（7）主时钟设备可主动向从时钟设备发送取消信息，中止相应单播数据帧的发送。从时钟设备也可主动向主时钟设备发送取消发送的请求信息，主时钟设备收到该消息后，发确认信息，同时中止相应单播数据包的发送。

请参考图9，主从时钟设备单播协商机制取消后的处理流程：

（1）从时钟设备主动向主时钟设备发送单播时延请求帧，该时延请求帧中携带单播协商机制取消（不使能）编码信息。

（2）主时钟设备接收到从时钟设备发来的时延请求帧后，获得并解析出单播协商机制取消信息。主时钟设备向从时钟设备发送带有确认信息的时延回复帧。

（3）单播协商机制取消后，主时钟设备以是否收到从时钟设备的时延请求帧为依据来更新本地客户列表参数。主时钟设备不区分单播数据帧类型，向有效客户发送所有必要的单播数据帧（sync、announce、delay_resp、pdelay_resp等）。

（4）主时钟设备在规定时间内未收到从时钟设备发送的时延请求帧时，则停止向该从时钟设备发送单播数据帧并更新本地客户列表参数，直到重新收到时延请求帧。

其中，在本申请实施例中，主从时钟设备在端到端时延测量机制（E2E）模式下，所述的单播时延请求帧类型为delay_req，单播时延回复帧类型为delay_resp。主从时钟设备在点到点时延测量机制（P2P）模式下，所述的单播时延请求帧类型为pdelay_req，单播时延回复帧类型为pdelay_resp。主时钟设备在P2P二步工作模式下，pdelay_resp_follow_up帧不携带单播协商信息编码。

其中，在本申请实施例中，从时钟设备根据需要周期性向主时钟设备发送包含有效单播协商信息编码的单播时延请求帧。从时钟设备在单播协商请求时，在时延请求帧中携带有效单播协商信息编码，其他情况下时延请求帧中携带无效单播协商信息编码。主时钟设备收到带有无效单播协商信息编码的时延请求帧后，不处理单播协商编码，不更新本地客户列表参数。

其中，在本申请实施例中，主时钟设备在本地维护一个客户列表。客户列表参数包括但不限于：单播协商使能、目的IP地址、目的MAC地址、有效性标记、计数值、持续时间等。其中，目的IP地址用于三层PTP工作模式，目的MAC地址用于二层PTP工作模式；有效性标记、计数值、持续时间和请求的单播数据包类型相关联。

其中，在本申请实施例中，主时钟设备判断客户有效性规则：单播协商机制使能时，如果主时钟设备同意从时钟设备的单播请求，则判定该从时钟设备为有效客户；如果主时钟设备取消从时钟设备的单播请求或者从时钟设备超过老化时间未发送新的携带有效单播协商信息编码的时延请求帧时，则判定该从时钟设备为无效客户并从客户列表中清除。 

单播协商机制不使能时，如果主时钟设备收到从时钟设备的时延请求帧，则判定该从时钟设备为有效客户；如果主时钟设备取消从时钟设备的单播请求或者从时钟设备超过老化时间未发送时延请求帧时，则判定从时钟设备为无效客户并从客户列表中清除。

其中，在本申请实施例中，主时钟设备包含一个客户端数量门限，该门限可设置。当主时钟设备本地客户列表有效客户总数超过门限时，主时钟设备主动拒绝新进客户端的单播请求，保证现有客户的单播请求。

其中，在本申请实施例中，主时钟设备根据有效客户数量，均匀分配发往不同客户的单播sync和announce包发送间隔。主时钟设备根据客户有效性标记，即时发送时延请求回复帧（delay_resp帧或pdelay_resp帧）。

本申请实施例提供的一种IEEE1588单播协商机制改进方法及系统降低了主从时钟设备实现单播协商机制的复杂性。利用时延请求包/回复包的保留域来携带单播协商信息编码，在不影响PTP时延请求机制和流程的情况下，实现1588v2定义的单播协商机制基本功能。此过程中，未改变1588数据包的结构，不增加额外数据包类型，不需要发送和处理1588单播协商TLV信令，实现简单。

本申请实施例提供的一种IEEE1588单播协商机制改进方法及系统提高了主从时钟设备单播模式下的处理能力。本发明所述方法的单播协商功能编码简单，仅4个比特，处理简单。单播协商编码由时延请求帧/回复帧携带，主从时钟设备在正常处理时延请求帧/回复帧的同时，可以很容易获得并处理单播协商信息。另外，主从时钟设备不需要额外监听信令消息接收端口（三层模式），也不需要处理1588单播协商TLV信令。

本申请实施例提供的一种IEEE1588单播协商机制改进方法及系统在单播协商过程不占用额外网络带宽。单播协商信息已通过编码方式插入时延请求帧/回复帧的保留域中，整个过程不需要1588单播协商TLV信令参与，相对于原1588单播协商机制，节省了网络带宽。

本申请实施例提供的一种IEEE1588单播协商机制改进方法及系统对1588v2单播协商机制功能进行了扩展。本发明保留了1588单播协商机制中的单播请求、同意、确认、取消及设置老化时间的功能，扩展了单播协商使能控制机制。单播协商使能时，主从时钟设备通过单播协商信息建立单播连接并收发同步数据帧。单播协商不使能时，主从时钟设备不需要处理单播协商信息，仍然可以通过时延请求包建立单播连接并收发同步数据包。通过扩展，本发明提供了一种无单播协商机制时的简单、有效的PTP单播通信方法。

上述本申请实施例中的技术方案，至少具有如下的技术效果或优点：

由于采用了利用时延请求帧/回复帧的保留域来携带单播协商信息，在不影响PTP时延请求机制和流程的情况下，实现1588v2定义的单播协商机制基本功能，且本方法及实现系统的主从时钟设备不需要额外监听信令消息接收端口，也不需要处理1588单播协商TLV信令的技术手段，所以，有效解决了现有技术中现有的单播协商机制存在机制复杂、可靠性不高、效率较低、影响主从时钟设备处理能力、增加额外网络带宽，进而会影响主从时钟同步精度的技术问题，进而实现了单播协商机制简单、效率高，提高了主从时钟设备处理能力，节省网络宽带，对单播协商机制功能进行了扩展的技术效果。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (8)

1.一种IEEE1588单播协商机制改进方法，其特征在于，所述方法包括：

对单播协商信息内容进行编码；

基于所述编码后的单播协商信息，主时钟设备与从时钟设备建立连接并进行单播通信。

2.如权利要求1所述的方法，其特征在于，所述基于所述编码后的单播协商信息，主时钟设备与从时钟设备建立连接并进行单播通信具体包括：

所述从时钟设备定期向所述主时钟设备发送时延请求帧，所述时延请求帧中携带单播协商信息编码；

所述主时钟设备接收所述时延请求帧，向所述从时钟设备发送时延请求回复帧，所述时延请求回复帧中携带所述单播协商信息编码；

所述主从时钟设备单播协商成功后，所述主时钟设备向所述从时钟设备发送相应的单播数据帧，其中，协商不成功时，所述主时钟设备不发送单播数据帧；

所述主时钟设备超过老化时间未收到携带有效单播协商信息编码的时延请求帧时，停止向所述从时钟设备发送单播数据帧，直到再次收到时延请求帧；

所述单播协商机制使能时，所述主从时钟设备通过时延请求/回复帧中携带的单播协商信息编码建立连接；所述单播协商机制不使能时，所述主从时钟设备通过时延请求帧建立连接。

3.如权利要求1所述的方法，其特征在于，所述对单播协商信息内容进行编码具体为：利用时延请求帧/回复帧的保留域来携带单播协商信息。

4.如权利要求3所述的方法，其特征在于，所述时延请求帧具体包括：delay_req帧和pdelay_req帧；所述时延回复帧具体包括：delay_resp帧和pdelay_resp帧。

5.如权利要求4所述的方法，其特征在于，所述时延请求帧/回复帧的保留域为一预设保留域。

6.如权利要求1所述的方法，其特征在于，所述单播协商机制的基本功能包括但不限于：单播数据帧请求、同意、确认、取消及设置数据帧持续发送时间、单播协商使能。

7.如权利要求6所述的方法，其特征在于，所述对单播协商信息内容进行编码具体为利用4个比特位编码来实现所述单播协商机制的基本功能。

8.一种IEEE1588单播协商机制改进系统，其特征在于，所述系统包括：

网络接口模块、CPU模块、输入输出模块、时钟模块、1588时戳处理模块、MAC模块、PHY模块，其中，所述CPU模块为完成PTP协议处理功能的模块，所述PTP协议包含使用权利要求1-7所述的方法的单播协商机制；

其中，所述CPU模块与所述1588时戳处理模块、所述输入输出模块、所述MAC模块连接，所述输入输出模块与所述时钟模块、所述CPU模块连接，所述时钟模块与所述CPU模块、所述输入输出模块、所述1588时戳处理模块、所述PHY模块连接，所述1588时戳处理模块与所述时钟模块、所述MAC模块、所述PHY模块连接、所述CPU模块连接，所述MAC模块与所述CPU模块、所述PHY模块、所述1588时戳处理模块连接，所述PHY模块与所述MAC模块、所述1588时戳处理模块、所述CPU模块、所述时钟模块连接。

Images