WO2012068848A1

WO2012068848A1 - 一种时间同步的方法和系统

Info

Publication number: WO2012068848A1
Application number: PCT/CN2011/074720
Authority: WO
Inventors: 罗丽; 傅小明; 白磊
Original assignee: 中兴通讯股份有限公司
Priority date: 2010-11-26
Filing date: 2011-05-26
Publication date: 2012-05-31
Also published as: CN102006660B; CN102006660A

Abstract

本发明公开一种时间同步的方法和系统，其中，所述方法包括：从设备构造与主设备发送给从设备的同步报文长度一致的延迟请求报文，向主设备发送所述延迟请求报文；从设备根据所述同步报文的发送和接收时间，以及所述延迟请求报文的发送和接收时间，计算从设备与主设备的时间偏差，进而与主设备时间同步。采用本发明，在延时请求响应机制中将可以避免由于事件报文长度不一致带来的相位不对称问题。

Description

一种时间同步的方法和系统

技术领域

本发明涉及时钟同步领域，尤其涉及一种时间同步的方法和系统。

背景技术

在 3G无线通信领域，存在几种无线标准： CDMA( Code Division Multiple Access, 码分多址接入） 2000、 WCDMA ( Wideband Code Division Multiple Access, 宽带码分多址接入）、 TD-SCDMA ( Time Division-Synchronous Code Division Multiple Access, 时分同步码分多址接入）、 WIMAX ( Worldwide Interoperability for Microwave Access , 微波技术全球互通接入) 、 LTE ( Long Time Evolution,长期演进（ TDD/FDD ) )。对于基于 TDD( Time Division Duplex, 时分双工）系统，如 CDMA2000、 TD-SCDMA, LTE ( TDD ) 、 WIMAX等，为了保证小区切换能够顺利完成，需要严格的相位同步。基于 FDD( Frequency Division Duplex , 频分双工）系统，如 GSM ( Global System for Mobile Communications, 全球移动通讯系统）、 WCDMA、 LTE ( FDD )等，需要保证基站系统间保持频率同步。

为了保证相位同步，现在各产品线大量使用的是同步于 GPS ( Global Positioning System, 全球定位系统）等标准参考源方法，但是用 GPS做参考大大受制于美国的控制，曾出现过由于 GPS卫星系统升级导致地面大部分基站瘫痪的局面；另外还存在 GPS的安装成本高、不是所有的地方都可以安装等问题。随着 IEEE 1588协议（即 Precision Time Synchronization Protocol, 精确时钟同步协议，简称 PTP ) 的出现，通信系统也逐渐用网络的 PTP来用于基站同步，代替 GPS天馈系统，解决时钟同步问题。

IEEE1588 精密时钟同步协议是为克服以太网实时性不足而规定的一种对时机制，它的出现给我们带来了希望，它的主要原理是通过主从间收发特定报文，计算与参考源的时间偏差来达到同步的目的。目前同步设备厂商们正在试图用 IEEE1588网络时钟代替 GPS时钟源，但是发布的 IEEE1588-2008 在实现时还存在一些问题。发明内容

现有的 IEEE1588-2008标准没有明确描述各种报文必须的长度，这样可能导致不同厂家发送的报文长度不一致，报文长度不一致会引起延时不对称性问题，导致同步后主从之间会存在一定的相位偏差。当相位偏差超过协议要求时，将会引起小区切换不成功、掉话、相邻小区间干扰等问题。

本发明要解决的技术问题提出一种时间同步的方法和系统，解决 IEEE1588 用于时间同步时由于事件 4艮文长度不一致，引起的相位不对齐问题。

为了解决上述问题，本发明提供一种时间同步的方法，包括：

从设备构造与主设备发送给从设备的同步报文长度一致的延迟请求报文，向主设备发送所述延迟请求报文；

从设备根据所述同步报文的发送和接收时间，以及所述延迟请求报文的发送和接收时间，计算从设备与主设备的时间偏差，进而与主设备时间同步。

优选地，上述方法具有以下特点：

所述从设备构造与主设备发送给所述从设备的同步报文长度一致的延迟请求报文的步骤包括：所述从设备通过与主设备之间发送信令报文，进行协商，获知协商后的同步报文长度，进而构造与所述同步报文长度一致的延迟请求 ^艮文。

优选地，上述方法具有以下特点：

所述从设备与主设备之间发送信令报文，进行协商，获知协商后的同步报文长度的步骤包括：

从设备向主设备发送第一信令报文，其中的类型长度值（TLV ) 中携带待协商的同步报文长度信息；

所述主设备接收到所述第一信令报文后，获知待协商的同步报文长度信息，向所述从设备发送第二信令报文，其中的 TLV携带协商后的同步报文长度信息；所述从设备接收到所述第二信令报文后，获知协商后主设备即将发送的同步报文长度。

优选地，上述方法具有以下特点：

所述从设备构造与主设备发送给所述从设备的同步报文长度一致的延迟请求报文的步骤包括：从设备接收到主设备发送的同步报文后，获取所述同步报文的长度，进而构造与所述同步报文长度一致的延迟请求报文。

优选地，上述方法具有以下特点：

从设备构造延迟请求报文之前，所述主设备和从设备事先约定好同步报文和延迟请求报文的长度，使延迟请求报文的长度与同步报文长度相同。

为了解决上述问题，本发明提供一种时间同步的系统，包括主设备和从设备，

主设备设置为向从设备发送同步报文；

从设备设置为构造与所述同步报文长度一致的延迟请求报文，向主设备发送所述延迟请求报文；以及，根据所述同步报文的发送和接收时间，以及所述延迟请求报文的发送和接收时间，计算从设备与主设备的时间偏差，进而与主设备时间同步。

优选地，上述系统具有以下特点：

所述从设备是设置为通过与主设备之间发送信令报文，进行协商，获知协商后的同步报文长度，进而构造与所述同步报文长度一致的延迟请求报文；或者，接收到所述同步报文后，获取所述同步报文的长度，进而构造与所述同步报文长度一致的延迟请求报文；或者，与主设备事先约定好同步报文和延迟请求报文的长度，使延迟请求报文的长度与同步报文长度相同。

为了解决上述问题，本发明提供一种从设备，包括报文收发模块和同步模块，其中，

所述报文收发模块设置为构造与主设备发送给从设备的同步报文长度一致的延迟请求报文，向主设备发送所述延迟请求报文；

所述同步模块根据所述同步报文的发送和接收时间，以及所述延迟请求报文的发送和接收时间，计算从设备与主设备的时间偏差，进而与主设备时间同步。

优选地，上述从设备具有以下特点：

所述艮文收发模块是设置为通过与主设备之间发送信令报文，进行协商，获知协商后的同步报文长度，进而构造与所述同步报文长度一致的延迟请求报文；或者，接收到所述同步报文后，获取所述同步报文的长度，进而构造与所述同步报文长度一致的延迟请求报文；或者，根据与主设备事先约定好同步报文和延迟请求报文的长度，构造与所述同步报文长度一致的延迟请求报文。

优选地，上述从设备具有以下特点：

当从设备与主设备之间发送信令报文，进行协商，获知协商后的同步报文长度，进而构造与所述同步报文长度一致的延迟请求报文时，

所述报文收发模块是设置为向主设备发送第一信令报文，其中的类型长度值（TLV ) 中携带待协商的同步报文长度信息；接收到主设备发送的第二信令报文后，从所述第二信令报文的 TLV中获知协商后的同步报文长度。

釆用本发明，在延时请求响应机制中将可以避免由于事件报文长度不一致带来的相位不对称问题。

附图概述

图 1是本发明实施例所提供的延时请求响应机制示意图；

图 2是本发明实施例所提供的组网示意图；

图 3是本发明应用示例的方案一流程图；

图 4是本发明应用示例的方案二流程图。

本发明的较佳实施方式

IEEE 1588是一种以太网的时钟同步协议（ PTP协议），通过同步报文实现主从同步。 PTP协议可以承载在 Ethernet 802.3、 UDP/IPv4和 UDP/IPv6 , 802.3帧结构的形式如表 1所示，数据字段最少要 46个字节。对于 PTP报文，其内容放在 Data/Load (数据 /负载 )部分，因此 PTP报文最少要有 46个字节。

表 1 preamble SFD Des MAC Sour MAC Data /Load FCS

7 bytes 1 byte 6 bytes 6 bytes 2 bytes 46-1500 bytes 4 bytes

在延时请求响应机制中，使用图 1中的 Sync (同步）、 Follow— up (跟踪）、 Delay_Req (延迟请求 )和 Delay_Resp (延迟响应 ) 4艮文实现同步，图 1中 tl 和 t2分别为 Sync报文的发送和接收时间戳，即 tl 是 Sync报文出主设备 ( Master ) 时的时间， t2为 Sync报文到从设备（Slave ) 时的时间。 t3和 t4 分别为 Delay— Req报文的发送和接收时间戳，即 t3为 Delay— Req报文出从设备的时间， t4为 Delay— Req报文到主设备的时间。

表 2 为 Sync 和 Delay— Req报文的包结构，从表中可以看出 Sync 和 Delay— Req报文的有用长度为 44字节，如果 PTP标准协议承载在 Ethernet 802.3上，即没有 IP等包头，则 Sync和 Delay— Req报文的长度不满足要求，因此需要补偿至少 2个字节的长度。

表 2

如上面描述，需要补充一定的字节才能符合要求，这样有可能不同厂家补充的字节长度不一致，而在实际使用中主设备和从设备经常是来自不同的厂家。 PTP用于时间同步时常用的应用场景如图 2。主设备和从设备之间经过交换机或者路由器，并且速率不确定，中间有 FE/GE/10GE (百兆 /千兆 /万兆）等接口，下面将对由于事件报文长度不一致引起的问题进行分析。

为了分析 Sync报文和 Delay— Req报文长度不一致引起的问题，做如下假设：

(1 )线路（cable)延时是对称的，两个方向的线路传输延时相等；

(2)报文帧由交换机完全读入緩存后再开始转发；

( 3 ) Sync 4艮文的长度与 Delay_Req ^艮文长度不一致；

(4) 中间经过的都是 FE交换机；

( 5 )主设备和从设备的频率和时间是完全同步的；

( 6 )主设备和从设备中间都是 FE交换机。

在主设备到从设备的方向上，事件报文的延时为：

t2-N {L_sync__PKT + L_FCS)_hytes x ^_bits/byte x FE_m/bit + {L_Vxe__amhle )_hytes x ^_bits/byte x FE_m/bit +1 ( 1 ) 其中， U Sync报文的长度， N为主设备与从设备之间交换的级数，

L_Pie__amble 为帧前导的长度， ¾_∞/¾¾为 100M物理网口转发每 bit数据的时间。

在从设备到主设备的方向上，事件报文的延时为： t4 = N {J^

(2)

为 Delay— Req报文的长度， J_Fra为检验位 (FCS)长度。

平均线路传输延时为：

[(t2-tl) + (t4-t3)]

N, (3)

2 offsetFromMaster是从设备的时间与主设备的时间之差，其公式为（ 4 )

[(tl-t2) + (t4-t3)1 . _Λ、

< offsetFromMaster > =― '―^ ― ( 4 ) 将（1 )和（2)代入（4)为：

Λ₄ . N ~x (L_{del req}__PKT L __ρκτ ) x 8 x (FE)_m c

< offsetFromMaster > = J ) 因为上面 4叚设主设备和从设备的频率和时间完全同步，理论上 offsetFromMaster应该为 0, 而由（5 )可知，这个值与 Sync与 Delay— Req才艮文长度之差和经过的交换级数有关系。如果 Sync报文与 Delay— Req报文的长度一样时，这个值与交换级数无关，即为 0, 否则这个偏差将会随着交换级数的增加而增加。

假设 Sync报文长度比 Delay— Req报文长度多 20字节，当中间的交换为

FE交换时， offsetFromMaster的值为：

N x 20 x 8 x l0 一 _ΛΓ r

< offsetFromMaster > = = 800 x N b ) 为了证明这个理论的正确性，做了如下实验， Sync 报文的长度比 Delay— Req报文长度少 20个字节，交换级数与相位偏差的关系如表 3所示。

表 3

说明： "-"表示 Slave的相位超前于 Master的相位从表 3中看出，每增加一级 FE交换，相位偏差将会波动 800ns左右，由于网络有一些不确定性存在一些偏差，这样随着交换级数的增多，将会引起主从间相位不对称问题，最终对于无线系统基站将会导致小区间切换不成功、掉话以及相邻小区间干扰的问题。

将会导致主设备到从设备与从设备到主设备的延迟时间不同。承载在 Ethernet 802.3上的报文存在这个问题，同样承载在 UDP/IPv4和 UDP/IPv6存在同样的问题。只要 Sync报文和 Delay— Req报文长度一样将不会存在同样问题，因此，本发明的基本思想是：在延时请求响应机制中要保证 Sync报文和 Dleay— Req 艮文长度一样。

具体地，包括：从设备构造与 Sync报文长度一致的 Delay— Req报文，向主设备发送所述 Delay— Req报文；根据所述 Sync报文的发送和接收时间，以及所述 Delay— Req报文的发送和接收时间，计算从设备与主设备的时间偏差，进而与主设备时间同步。

其中，可以根据式（3 )计算线路传输延时。

本发明提出三种保证 Sync报文与 Delay— Req报文长度一样的方案。

方案一：从设备通过与主设备之间发送信令（Signaling )报文，进行协商，从设备获知协商后的主设备发送 Sync报文长度，从而构造与所述 Sync 才艮文长度一致的 Delay— Req 4艮文。

Signaling报文可以用来协商主设备和从设备的发包速率和持续时间，这种文只有在单播方式下生效。本方案通过增加相应的 TLV ( Type Length Value , 类型长度值）来增加 Signaling报文的消息字段，协商报文长度。

具体地，可包括如下步骤：从设备向主设备发送第一信令报文，其中的 TLV中携带待协商的同步报文长度信息；主设备接收到所述第一信令报文后，获知待协商的同步报文长度信息，向所述从设备发送第二信令报文，其中的 TLV携带协商后的同步报文长度信息；从设备接收到所述第二信令报文后，获知协商后主设备即将发送的同步报文长度。

现有技术中，从设备发送 Singaling报文请求主设备以固定的时间间隔和持续时间发送 Announce (通知）、 Sync, Delay_Resp才艮文，其中 Signaling才艮文格式如表 4所示，其中请求主设备的内容在 TLV中携带，单播协商 TLV 包括 REQUEST_U ICAST_TRANSMISSION ( 请求单播传输）、 GRANT U ICAST TRANSMISSION ( 授权单播传输）、 CANCEL U ICAST TRANSMISSION ( 取消单播传输）和 ACKNOWLEDGE CANCEL U ICAST TRANSMISSION (确认取消单播传输 ) , 这些 TLV包括消息类型、发送时间间隔和发送持续时间，如表 5所示。

表 4

表 5 现有技术 REQUEST— UNICAST— TRANSMISSION TLV格式

为了保证主设备发送的 Sync报文与从设备发送的 Delay— Req报文长度一样，可以将这些 TLV增加表示报文长度的信息，称为 messageLength, 本实施例的 TLV的形式如表 6所示。 messageLength共 2个字节，默认值为 Oxffff, 因为以太网包的长度为 64〜： 1518,去除 FCS (校验位），报文长度为 60〜： 1514, 因此这个值为 0x003C~0x05EA内为有效值，否则都认为无效。

表 6 本发明 REQUEST— UNICAST— TRANSMISSION TLV格式 Bits

Octets Offset

7 6 5 4 3 2 1 0

tlvType 2 0 lengthField 2 2 messageType reserved 1 4 loglnterMessagePeriod 1 5 durationField 4 6 messageLength (信息长度) 2 10

主设备回应从设备 GRANT— UNICAST— TRANSMISSION TLV报文，也需要对这个 TLV 增加报文长度信息。如表 7 所示，为现有技术 GRANT— UNICAST— TRANSMISSION TLV格式 ,表 8为本实施例增加了报文长度信息的 TLV格式。这样从设备通过 Signaling报文可以获取主设备发送的同步报文的长度，依据这个长度来确定 Delay— Req的报文长度。从而可以保证在延迟响应机制中事件报文长度一致。

表 Ί 现有技术 GRANT— UNICAST— TRANSMISSION TLV格式

Bits

Octets Offset

6 5 4 3 2 1 0

tlvType 2 0 lengthField 2 2 messageType reserved 1 4 loglnterMessagePeriod 1 5 durationField 4 6 reserved 1 10

0 0 0 0 0 0 R 1 11 本发明 GRANT— UNICAST— TRANSMISSION TLV格式

下面以一具体的应用示例说明方案一的实现步骤，如图 3所示：步骤 301 , 配置从设备，以单播的形式与主设备通信，同时配置单播协商功能。

步骤 302, 配置从设备发送 Signaling协商请求报文参数，包括报文类型、报文持续时间和本发明提出的报文长度，按照表 6 中本发明定义的 REQUEST— UNICAST— TRANSMISSION TLV形式的内容，通过 Signaling报文发送给主设备。

步骤 303 , 主设备收到这个 Signaling报文后，按照表 8中的本发明定义的 GRANT— UNICAST— TRANSMISSION TLV 形式的内容，发出携带 GRANT— UNICAST— TRANSMISSION TLV的报文给从设备，这时从设备可从报文中获取主设备发送的 Sync报文长度。

步骤 304, 从设备以与 Sync报文同步的长度发送 Delay— Req报文。

方案二：从设备接收到 Sync报文后，获取所述 Sync报文的长度，从而构造与所述 Sync报文长度一致的 Delay— Req报文。

在本方案中，从设备直接获取 Sync报文的长度，然后发送 Delay— Req报文，适用于单播和组播的情况，如图 4所示，其具体实施步骤为：

步骤 401 , 主设备主动发送 Sync报文；

步骤 402, 从设备在获取到 Sync报文后，获取 Sync报文的长度信息，以相同的长度发送 Delay— Req报文。

方案三：主设备和从设备事先约定好 Sync报文和 Delay— Req报文的长度，使 Delay— Req报文的长度与 Sync报文长度相同。

具体地，可根据协议要求，确定相应报文的固定长度。可做如下要求：要求 1588的报文长度，对于承载在 Ethernet 802.3上的报文，由于报文消息小于 46个字节，这时在没有 VLAN ( Virtual Local Area Network, 虚拟局域网）标签的情况下，确定 1588 ^艮文长度为 64字节，即可以并且必须增加 2个字节的附加字节，在下列情况下不能加入附加字节：

( 1 )承载在 Ethernet 802.3上的报文，带有 VLAN标签；

( 2 )承载在 UDP/lPv4或者 UDP/lPv6的报文。

相应地，本发明实施例的时间同步的系统，包括主设备和从设备，其中，主设备设置为向从设备发送同步报文；

优选地，所述从设备是设置为通过与主设备之间发送信令报文，进行协商，获知协商后的同步报文长度，从而构造与所述同步报文长度一致的延迟请求报文；或者，接收到所述同步报文后，获取所述同步报文的长度，从而构造与所述同步报文长度一致的延迟请求报文；或者，与主设备事先约定好同步报文和延迟请求报文的长度，使延迟请求报文的长度与同步报文长度相同。

本发明实施例的从设备，包括报文收发模块和同步模块，其中，所述报文收发模块设置为构造与主设备发送给从设备的同步报文长度一致的延迟请求报文，向主设备发送所述延迟请求报文；

优选地，所述报文收发模块是设置为通过与主设备之间发送信令报文，进行协商，获知协商后的同步报文长度，从而构造与所述同步报文长度一致的同步报文；或者，接收到所述同步报文后，获取所述同步报文的长度，从而构造与所述同步报文长度一致的延迟请求报文；或者，根据与主设备事先约定好同步报文和延迟请求报文的长度，构造与所述同步报文长度一致的延迟请求报文。优选地，当从设备与主设备之间发送信令报文，进行协商，获知协商后的同步报文长度，从而构造与所述同步报文长度一致的延迟请求报文时，所述报文收发模块是设置为向主设备发送第一信令报文，其中的 TLV中携带待协商的同步报文长度信息；接收到主设备发送的第二信令报文后，从所述第二信报文的 TLV中获知协商后的同步报文长度。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现，相应地，上述实施例中的各模块 /单元可以釆用硬件的形式实现，也可以釆用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

工业实用性

本发明提出一种时间同步的方法和系统，通过从设备构造延迟请求报文并发送给主设备；从设备根据所述同步报文的发送和接收时间，以及所述延迟请求报文的发送和接收时间，计算从设备与主设备的时间偏差，进而与主设备时间同步，解决 IEEE1588用于时间同步时由于事件报文长度不一致，引起的相位不对齐问题。

Claims

权利要求书

1、一种时间同步的方法，包括：

从设备构造与主设备发送给所述从设备的同步报文长度一致的延迟请求报文，向所述主设备发送所述延迟请求报文；

从设备根据所述同步报文的发送和接收时间，以及所述延迟请求报文的发送和接收时间，计算所述从设备与所述主设备的时间偏差，进而与所述主设备时间同步。

2、如权利要求 1所述方法，其中，所述从设备构造与主设备发送给所述从设备的同步报文长度一致的延迟请求报文的步骤包括：

所述从设备通过与所述主设备之间发送信令报文，进行协商，获知协商后的所述同步报文长度，进而构造与所述同步报文长度一致的所述延迟请求报文。

3、如权利要求 2所述方法，其中，

所述从设备与所述主设备之间发送信令报文，进行协商，获知协商后的同步报文长度的步骤包括：

从设备向所述主设备发送第一信令报文，其中的类型长度值（TLV ) 中携带待协商的同步报文长度信息；

所述主设备接收到所述第一信令报文后，获知所述待协商的同步报文长度信息，向所述从设备发送第二信令报文，其中的 TLV携带协商后的同步报文长度信息；

所述从设备接收到所述第二信令报文后，获知协商后所述主设备即将发送的同步报文长度。

4、如权利要求 1所述的方法，其中，所述从设备构造与主设备发送给所述从设备的同步报文长度一致的延迟请求报文的步骤包括：

所述从设备接收到所述主设备发送的同步报文后，获取所述同步报文的长度，进而构造与所述同步报文长度一致的所述延迟请求报文。

5、如权利要求 1所述的方法，其还包括：所述从设备构造延迟请求报文之前，所述主设备和所述从设备事先约定好所述同步报文和所述延迟请求报文的长度，使所述延迟请求报文的长度与所述同步报文长度相同。

6、一种时间同步的系统，包括主设备和从设备，其中，

所述主设备设置为向所述从设备发送同步报文；

所述从设备设置为：构造与所述同步报文长度一致的延迟请求报文，向所述主设备发送所述延迟请求报文；以及，根据所述同步报文的发送和接收时间，以及所述延迟请求 ^艮文的发送和接收时间，计算所述从设备与所述主设备的时间偏差，进而与所述主设备时间同步。

7、如权利要求 6所述的系统，其中，

所述从设备是设置为：通过与所述主设备之间发送信令报文，进行协商，获知协商后的同步报文长度，进而构造与所述同步报文长度一致的延迟请求报文；或者，接收到所述同步报文后，获取所述同步报文的长度，进而构造与所述同步报文长度一致的延迟请求报文；或者，与所述主设备事先约定好所述同步报文和所述延迟请求报文的长度，使所述延迟请求报文的长度与所述同步报文长度相同。

8、一种从设备，包括报文收发模块和同步模块，其中，

所述报文收发模块设置为：构造与主设备发送给所述从设备的同步报文长度一致的延迟请求报文，向所述主设备发送所述延迟请求报文；

所述同步模块设置为：根据所述同步报文的发送和接收时间，以及所述延迟请求报文的发送和接收时间，计算所述从设备与所述主设备的时间偏差，进而与所述主设备时间同步。

9、如权利要求 8所述的从设备，其中，

所述报文收发模块是设置为：通过与所述主设备之间发送信令报文，进行协商，获知协商后的所述同步报文长度，进而构造与所述同步报文长度一致的所述延迟请求报文；或者，接收到所述同步报文后，获取所述同步报文的长度，进而构造与所述同步报文长度一致的延迟请求报文；或者，根据与所述主设备事先约定好所述同步报文和所述延迟请求报文的长度，构造与所述同步报文长度一致的所述延迟请求报文。

10、如权利要求 9所述的从设备，其中，

当所述从设备与所述主设备之间发送信令报文，进行协商，获知协商后的所述同步报文长度，进而构造与所述同步报文长度一致的所述延迟请求报文时，

所述报文收发模块是设置为：向所述主设备发送第一信令报文，其中的类型长度值（TLV ) 中携带待协商的所述同步报文长度信息；接收到所述主设备发送的第二信令报文后，从所述第二信令报文的 TLV中获知协商后的所述同步报文长度。