CN105515705A - 一种时钟状态查询方法、通信设备及系统 - Google Patents

Abstract

本发明提供一种时钟状态查询方法、通信设备及系统，包括生成时钟状态查询请求消息，将时钟状态查询请求消息发送至对端设备，接收对端设备发送的时钟状态响应消息，时钟状态响应消息包括对端设备的时钟状态信息，根据时钟状态响应消息，获取对端设备的时钟状态信息，将时钟状态确认消息发送至对端设备。本发明通过以上技术方案，解决了在网络中由于设备之间的相互封闭，从而为设备提供业务带来诸多不便的问题。通过上述技术方案，实现设备彼此之间时钟状态的互相学习、了解，实现设备间时钟状态的透明化，为系统决策提供时钟方面的依据，满足了业务对时钟的特殊要求，保证了解状态的互联互通性，也为后续时钟的演进提供支撑。

Description

一种时钟状态查询方法、通信设备及系统

技术领域

本发明涉及通信领域，尤其涉及一种时钟状态查询方法、通信设备及系统。

背景技术

随着网络技术的快速发展，数据业务需求的不断增长，推动了宽带技术及通信设备的快速发展，引发了电信网络的大调整，原有的满足语音业务的传输网络渐渐无法胜任数据业务的需求增长。整个网络趋向于扁平化态势，宽带接入进入了快速发展中，无论是有线宽带接入，还是无线宽带接入，均受到了运营商及用户的一致青睐。

随着网络技术的变化和发展，对时钟提出了新的要求，特别是无线宽带技术，尤其是以时分模式运营的无线设备，需要互相了解彼此间时钟获取方式、时钟状态以及时钟精度等等参数，以保证终端客户在不同基站之间切换业务不中断。随着WIMAX(WorldwideInteroperabilityforMicrowaveAccess，全球微波互联接入)、LTE(LongTermEvolution，长期演进)的无线技术的普及、推广和商业，如何实现通信设备间时钟状态的相互了解、相互学习，就变得更加紧迫。

虽然通信设备之间彼此了解相互之间的时钟状态如此重要，但是目前还没有统一的、保证时钟状态学习互联互通的协议。

发明内容

本发明提供给了一种时钟状态查询方法、通信设备及系统，解决了在网络中由于通信设备之间的相互封闭，从而为通信设备提供业务带来诸多不便的问题。

为解决上述技术问题，本发明提供了一种时钟状态查询方法，包括：

生成时钟状态查询请求消息；

将所述时钟状态查询请求消息发送至对端设备；

接收所述对端设备发送的时钟状态响应消息，所述时钟状态响应消息包括所述对端设备的时钟状态信息；

根据所述时钟状态响应消息，获取所述对端设备的时钟状态信息；

将时钟状态确认消息发送至所述对端设备。

在本发明的一种实施例中，在生成时钟状态查询请求消息之前，还包括：

建立本端设备与所述对端设备之间的通信链接。

在本发明的一种实施例中，建立本端设备与所述对端设备之间的通信链接具体包括：

生成建链请求消息；

将所述建链请求消息发送至所述对端设备；

接收所述对端设备发送的建链响应消息；

根据所述建链响应消息，生成建链确认消息；

将所述建链确认消息发送至所述对端设备。

在本发明的一种实施例中，在根据所述时钟状态响应消息，获取所述对端设备的时钟状态信息之前，还包括：

验证所述时钟状态响应消息是否正确；

若正确，则进入根据所述时钟状态响应消息，获取所述对端设备的时钟状态信息的步骤。

在本发明的一种实施例中，生成时钟状态查询请求消息具体包括：

获取本端设备的时钟状态信息；

生成时钟状态查询请求消息，所述时钟状态查询请求消息包括所述本端设备的时钟状态信息；

和/或，

在将时钟状态确认消息发送至所述对端设备之前，还包括：

获取本端设备的时钟状态信息；

生成时钟状态确认消息，所述时钟状态确认消息包括所述本端设备的时钟状态信息。

本发明还提供一种时钟状态查询方法，包括：

接收对端设备发送的时钟状态查询请求消息；

根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息；

将所述时钟状态响应消息发送至所述对端设备；

接收所述对端设备发送的时钟状态确认消息。

在本发明的一种实施例中，在接收对端设备发送的时钟状态查询请求消息之前，还包括：

建立本端设备与所述对端设备之间的通信链接。

在本发明的一种实施例中，建立本端设备与所述对端设备之间的通信链接具体包括：

接收所述对端设备发送的建链请求消息；

根据所述建链请求消息，生成建链响应消息；

将所述建链响应消息发送至所述对端设备；

接收所述对端设备发送的建链确认消息。

在本发明的一种实施例中，在根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息之前，还包括：

验证所述时钟状态查询请求消息是否正确；

若正确，则进入根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息的步骤。

在本发明的一种实施例中，根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息具体包括：

根据所述时钟状态查询请求消息，获取本端设备的时钟状态信息；

生成时钟状态查询请求信息；

生成时钟状态响应消息，所述时钟状态响应消息包括所述本端设备的时钟状态信息、时钟状态查询请求信息。

本发明还提供一种时钟状态查询方法，包括：

第一通信设备生成时钟状态查询请求消息，将所述时钟状态查询请求消息发送至第二通信设备；

所述第二通信设备接收所述第一通信设备发送的时钟状态查询请求消息，根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括所述第二通信设备的时钟状态信息，将所述时钟状态响应消息发送至所述第一通信设备；

所述第一通信设备接收所述第二通信设备发送的时钟状态响应消息，所述时钟状态响应消息包括所述第二通信设备的时钟状态信息，根据所述时钟状态响应消息，获取所述第二通信设备的时钟状态信息，将时钟状态确认消息发送至所述第二通信设备；

所述第二通信设备接收所述第一通信设备发送的时钟状态确认消息。

在本发明的一种实施例中，在第一通信设备生成时钟状态查询请求消息，将所述时钟状态查询请求消息发送至第二通信设备之前，还包括：

建立所述第一通信设备与所述第二通信设备之间的通信链接。

本发明还提供一种通信设备，包括：

第一生成模块，用于生成时钟状态查询请求消息；

第一发送模块，用于将所述第一生成模块生成的时钟状态查询请求消息发送至对端设备，还用于将时钟状态确认消息发送至所述对端设备；

第一接收模块，用于接收所述对端设备发送的时钟状态响应消息，所述时钟状态响应消息包括所述对端设备的时钟状态信息；

第一获取模块，用于根据所述第一接收模块接收的时钟状态响应消息，获取所述对端设备的时钟状态信息。

在本发明的一种实施例中，还包括：

第一通信模块，用于建立本端设备与所述对端设备之间的通信链接。

在本发明的一种实施例中，所述第一生成模块还用于生成建链请求消息，还用于根据建链响应消息，生成建链确认消息；

所述第一发送模块还用于将所述第一生成模块生成的建链请求消息发送至所述对端设备，还用于将所述第一生成模块生成的建链确认消息发送至所述对端设备；

所述第一接收模块还用于接收所述对端设备发送的建链响应消息。

在本发明的一种实施例中，还包括：

第一验证模块，用于验证所述时钟状态响应消息是否正确；

所述第一获取模块用于若所述第一验证模块验证正确，则根据所述时钟状态响应消息，获取所述对端设备的时钟状态信息。

在本发明的一种实施例中，所述第一获取模块还用于获取本端设备的时钟状态信息；

所述第一生成模块具体用于生成时钟状态查询请求消息，所述生成时钟状态查询请求消息包括所述本端设备的时钟状态信息，还用于生成时钟状态确认消息，所述时钟状态确认消息包括所述本端设备的时钟状态信息。

本发明还提供一种通信设备，包括：

第二接收模块，用于接收对端设备发送的时钟状态查询请求消息，还用于接收所述对端设备发送的时钟状态确认消息；

第二生成模块，用于根据所述第二接收模块接收的时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息；

第二发送模块，用于将所述第二生成模块生成的时钟状态响应消息发送至所述对端设备。

在本发明的一种实施例中，还包括：

第二通信模块，用于建立本端设备与所述对端设备之间的通信链接。

在本发明的一种实施例中，所述第二接收模块还用于接收所述对端设备发送的建链请求消息，还用于接收所述对端设备发送的建链确认消息；

所述第二生成模块还用于根据所述第二接收模块接收的建链请求消息，生成建链响应消息；

所述第二发送模块还用于将所述第二生成模块生成的建链响应消息发送至所述对端设备。

在本发明的一种实施例中，还包括：

第二验证模块，用于验证所述时钟状态查询请求消息是否正确；

所述第二生成模块用于若所述第二验证模块验证正确，则根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息。

在本发明的一种实施例中，还包括：

第二获取模块，用于根据所述第二接收模块接收的时钟状态查询请求消息，获取本端设备的时钟状态信息；

所述第二生成模块还用于生成时钟状态查询请求信息；

所述第二生成模块具体用于生成时钟状态响应消息，所述时钟状态响应消息包括所述本端设备的时钟状态信息、时钟状态查询请求信息。

本发明还提供一种时钟状态查询系统，包括至少一个第一通信设备以及至少一个第二通信设备，所述第一通信设备为上述第一种通信设备，所述第二通信设备为上述第二种通信设备；

所述第一通信设备生成时钟状态查询请求消息，将所述时钟状态查询请求消息发送至第二通信设备，所述第二通信设备接收所述第一通信设备发送的时钟状态查询请求消息，根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括所述第二通信设备的时钟状态信息，将所述时钟状态响应消息发送至所述第一通信设备，所述第一通信设备接收所述第二通信设备发送的时钟状态响应消息，所述时钟状态响应消息包括所述第二通信设备的时钟状态信息，根据所述时钟状态响应消息，获取所述第二通信设备的时钟状态信息，将时钟状态确认消息发送至所述第二通信设备，所述第二通信设备接收所述第一通信设备发送的时钟状态确认消息。

本发明的有益效果：

本发明提供一种时钟状态查询方法、通信设备及系统，通过本技术方案，可以实现设备彼此之间时钟状态的互相学习、了解，为系统决策提供时钟方面的依据，实现设备间时钟状态的透明化，克服了目前系统中设备之间时钟状态彼此相互封闭的弊端，满足了业务对时钟的特殊要求，实现了设备彼此之间了解时钟状态，从而保证了解状态的互联互通性，为不同设备之间时钟状态的互相学习提供了解决思路和方法，也为后续时钟的演进提供支撑。此外，无论对于无线宽带技术，还是有线带宽技术，通过本技术方案，就能够互相了解、学习彼此之间时钟获取方式、时钟状态以及时钟精度等参数，以保证终端客户在不同基站之间切换业务不中断，为系统的运营、操作提供判定依据。例如，在移动通信领域，终端在不同基站设备之间的切换，通过本技术方案，基站就可以判定涉及切换的两基站的时钟状态条件是否满足用户业务成功切换的条件，降低因为时钟状态问题导致用户业务切换掉话的概率，从而提升移动终端在不同基站设备之间的切换成功率。

附图说明

图1为本发明实施例一提供的时钟状态查询方法的流程图；

图2为本发明实施例二提供的时钟状态查询方法的流程图；

图3为本发明实施例三提供的通信设备的结构示意图；

图4为本发明实施例四提供的通信设备的结构示意图；

图5为本发明实施例五提供的时钟状态查询系统的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例只是本发明中一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面通过具体实施方式结合附图对本发明作进一步详细说明。

实施例一：

如图1为本发明一实施例提供的时钟状态查询方法的流程图，如图1所示，该时钟状态查询方法包括：

S101：生成时钟状态查询请求消息；

S102：将时钟状态查询请求消息发送至对端设备；

S103：接收对端设备发送的时钟状态响应消息，时钟状态响应消息包括对端设备的时钟状态信息；

S104：根据时钟状态响应消息，获取对端设备的时钟状态信息；

S105：将时钟状态确认消息发送至对端设备。

具体地，为了实现通信设备之间彼此相互了解时钟状态，保证了解状态的互联互通性，克服目前通信设备之间时钟状态彼此相互封闭的弊端，对于任何一个通信设备而言，均可以针对其所想要了解、学习的另一个通信设备，发起时钟状态的查询请求。该时钟状态查询方法为针对发起端的查询方法，即本实施例中的本端设备为发起端，对端设备为响应端。

在本实施例中，为了保证在时钟状态查询过程中的安全性及可靠性，优选地，在发起时钟状态的查询请求之前，可以先针对本端设备以及本端设备想要查询的对端设备，建立本端设备与对端设备之间的通信链接，即建立发起端与响应端之间的通信链接，需要说明的是，该建立通信链接的过程可理解为本端设备与对端设备进行初始化的过程，通过该初始化的过程，为时钟状态的查询提供安全、可靠的通信链路，当然，若通信设备之间已经建立了相应的通信链接或已经完成初始化过程，则本端设备可不进行上述过程，根据实际需要，直接向对端设备发起时钟状态的查询请求。对于上述建立通信链接的方式，其包括但不局限于以下方式：

本端设备生成建链请求消息，将该建链请求消息发送至对端设备，对端设备对该建链请求消息进行响应，本端设备接收对端设备响应后发送的建链响应消息，根据该建链响应消息，生成建链确认消息，再将该建链确认消息发送至对端设备，用以告诉对端设备，本端设备已接收到响应消息，即表示本端设备与对端设备之间的通信链路建立成功。需要说明的是，通过上述建立通信链接的过程，让本端设备与对端设备彼此之间了解、学习对端的标识信息，对于本端设备而言，该建链请求消息包括本端设备的标识信息，和/或，该建链确认消息包括本端设备的标识信息，对端设备可以通过该建链请求消息和/或建链确认消息了解、学习本端设备的标识信息，从而可以为之后的时钟状态查询提供必要的基础信息，该标识信息包括但不局限于设备ID号，该设备ID号可以由用户自行定义，使其可以对设备进行标识，例如，对于基站而言，优选地，采用基站ID号作为设备ID号。

在上述建立通信链接的过程中，本端设备需要根据对端设备的响应结果，执行相应的操作。具体地，如果本端设备接收到对端设备发送的建链响应消息，对该建链响应消息进行验证，若验证为正确，即发送该建链响应消息的对端设备为本端设备想要查询时钟状态的对端设备，根据该建链响应消息，生成建链确认消息，将该建链确认消息发送至对端设备，用于告诉对端设备，本端设备已接收到响应消息，则表示建立通信链接成功，本次会话成功，即初始化成功；若验证为错误，即发送该建链响应消息的对端设备不是本端设备想要查询的对端设备，将拒绝消息发送至对端设备，则表示建立通信链接失败，本次会话结束，即初始化失败；若本端设备接收到对端设备发送的拒绝消息，则表示建立通信链接失败，本次会话结束，即初始化失败。针对上述建链请求消息、建链确认消息以及拒绝消息的发送形式，可以以报文的形式在通信设备之间相互发送，当然，也可以采用其他形式。

对于上述初始化过程而言，通信双方中的任何一方均可以发起建链请求，此处定义发起建链请求的一方为发起端，即本端设备，响应建链请求的一方为响应端，即对端设备，发起端在发出建链请求消息后，如果此时接收到自己所发出的建链请求消息的响应端的建链请求消息，则发起端必须采用拒绝操作，并向响应端发送拒绝消息，针对该发起端，需要至少设置一个定时器，优选地，可以将该定期器的时长设定为10分钟，当定时器超时后，则需要响应对端的建链请求消息，而不应该发送拒绝消息，需要说明的是，本实施例中的等待时间不作限制，可根据实际需要进行设定。

为了实现上述初始化过程，本实施例提供一种初始化消息的统一格式，当然，该初始化消息的格式并不局限于本实施例提供的格式，用户可根据实际需要，自行定义相应的格式，该初始化消息的统一格式如表1所示。

01234567890123456789012345678901

表1

其中，标记位：占用8bits，固定为0xaf；

版本号：占用8bits，当前固定填0x01；

分组长度：该字段占16bits，用于表述上述格式的长度(占用多少个字节)；

发起端随机ID：由发起端产生的随机数，用16bits标识；

响应端随机ID：由响应端产生的随机数，用16bits标识；

类型：用于标识消息类型，用8bits标识，其取值如表2所示；

标识值	标识值含义
		01	表示建链请求消息
02	表示建链响应消息
		03	表示建链确认消息
04	表示拒绝消息
		05	表示时钟状态查询消息
06	表示时钟状态响应消息
		07	表示时钟状态确认消息
08～0f	预留字段

表2

预留：使用0xff填写；

校验和：报文的校验字段，用于校验消息是否正确；

子类型：表示消息的子码类型，用8bits表示，其取值如表3所示；

标识值	标识值含义
		00	拒绝消息中使用，表示消息的后续字节不用关注

01	请求设备信息，表示消息后续内容为发起端的时钟信息
		02	响应设备信息，表示消息后续内容为响应端的时钟信息
03	用于建链请求消息、建链响应消息及建链确认消息
		04～0f	预留字段

表3

IP版本：占4bits，0x4表示消息发起端为IPv4地址，0x6表示消息发起端为IPv6地址；

设备ID号：占20bits，用于标识设备的ID，要求设备的ID号在网络中是唯一的；

IP地址：该字段填写消息发起端的源IP地址，其中，IPv4占用32bits，Ipv6占用128bits。

针对上述统一格式中的随机ID的生成方法，可以由通信双方自行定义其生成随机ID的函数，且相互之间保持独立。本实施例提供一种定义方式，该随机ID的函数的输入参数包括设备ID号、承载报文的IP地址(源端+目的端)、协议类型、传输层端口号(如果无，建议取全1)、差生随机数的时间(年、月、日、小时、分钟、秒)，当然，用户也可根据实际需求，自行定义。当通信双方中的任何一方接收到对端的消息后，必须验证该随机ID是否正确，对于不正确的随机ID，任何一方均可以发送拒绝消息，从而中断本次会话。

根据上述初始化消息的统一格式，建链请求消息的格式如表4所示：

01234567890123456789012345678901

表4

建链确认消息的格式如表5所示：

01234567890123456789012345678901

表5

发起端拒绝消息的格式如表6所示：

01234567890123456789012345678901

表6

对于建链请求消息中的发起端随机ID由发起端产生并填写，对于建链请求消息中的响应端随机ID，发起端使用0来填写。在之后的消息交互中，通信双方仅对自己产生的随机ID作加1处理，并保留对端的随机ID。通信双方核对本端随机ID，如果接收的消息中的本端随机ID不为本端发送的消息的随机ID(即当前随机ID)，则丢弃该消息，并发送拒绝消息给对端。本端的随机ID必须由本端进行修改，即针对发起端而言，其只能修改发起端的随机ID，不得私自修改响应端的随机ID。对于拒绝消息，不需要填写响应端随机ID，但需要填写类型、子类型、本端IP地址、设备ID号，以备发起端作验证所用。

结合上述格式，该初始化过程中消息流的交互流程描述如下：

情况1：初始化成功：

情况2：初始化失败：

发起端(Initiator)响应端(Responder)建链请求消息(发起端随机IDi+响应端随机0)--->

<---拒绝消息(发起端随机IDi+响应端随机0)

在本实施例中，若通信双方已建立通信链接或已完成初始化，则本端设备可向对端设备发起时钟状态查询请求。本端设备生成时钟状态查询请求消息，将该时钟状态查询请求消息发送至对端设备，对端设备对该时钟状态查询请求消息进行响应，本端设备接收对端设备响应后发送的建链响应消息，该建链响应消息包络对端设备的时钟状态信息，根据该建链响应消息，获取对端设备的时钟状态信息，将时钟状态查询确认消息发送至对端设备，用以告诉对端设备，本端设备已接收到响应消息，并获取到对端设备的时钟状态信息，即表示本次查询成功。

在上述时钟状态查询的过程中，本端设备需要根据对端设备的响应结果，执行相应的操作。具体地，本端设备接收到对端设备发送的时钟状态响应消息，对该时钟状态响应消息进行验证，若验证为正确，即发送该时钟状态响应消息的对端设备为本端设备想要查询时钟状态的对端设备，则根据该时钟状态响应消息，获取对端设备的时钟状态信息，并生成时钟状态确认消息，将该时钟状态确认消息发送至对端设备，用于告诉对端设备，本端设备已接收到响应消息，并获取到对端设备的时钟状态信息，即表示本次查询成功；若验证为错误，即发送该时钟状态响应消息的对端设备不是本端设备想要查询的对端设备，将拒绝消息发送至本端设备想要查询的对端设备，即表示本次查询失败；若本端设备接收到对端设备发送的拒绝消息，则表示对端设备拒绝本端设备的时钟状态查询请求，即表示本次查询失败。

对于上述查询过程而言，发起端在发出时钟状态查询请求消息后，如果此时接收到自己所发出的时钟状态查询请求消息的响应端的时钟状态查询请求消息，则发起端必须采用拒绝操作，并向响应端发送拒绝消息，针对该发起端，需要至少设置一个定时器，优选地，可以将该定期器的时长设定为10分钟，当定时器超时后，则需要响应对端的时钟状态查询请求消息，而不应该发送拒绝消息，需要说明的是，本实施例中的等待时间不作限制，可根据实际需要进行设定。

在上述技术方案中，本端设备可以了解并学习对端设备的时钟状态信息，若对端设备也同样想了解并学习本端设备的时钟状态信息，其可以在同一次查询过程中完成相应的操作，本实施例可以通过以下方式使对端设备同样了解并学习本端设备的时钟状态信息：

方式一、在查询过程中，本端设备可以先获取本端设备的时钟状态信息，获取完成后，生成时钟状态查询请求消息，该时钟状态查询请求消息包括本端设备的时钟状态信息，将该时钟状态查询请求消息发送至对端设备，以便对端设备了解并学习本端设备的时钟状态信息；

方式二、在查询过程中，本端设备接收到对端设备发送的时钟状态响应消息后，可以获取本端设备的时钟状态信息，获取完成后，生成时钟状态确认消息，该时钟状态确认消息包括本端设备的时钟状态信息，将该时钟状态确认消息发送至对端设备，以便对端设备了解并学习本端设备的时钟状态信息；

方式三、在查询过程中，本端设备可以先获取本端设备的时钟状态信息，获取完成后，生成时钟状态查询请求消息，该时钟状态查询请求消息包括本端设备的时钟状态信息，将该时钟状态查询请求消息发送至对端设备，本端设备接收到对端设备发送的时钟状态响应消息后，可以获取本端设备的时钟状态信息，获取完成后，生成时钟状态确认消息，该时钟状态确认消息包括本端设备的时钟状态信息，将该时钟状态确认消息发送至对端设备，以便对端设备了解并学习本端设备的时钟状态信息。

在上述技术方案中，对于时钟状态查询请求消息、时钟状态确认消息以及拒绝消息的发送方式，一方面，可以将这些交互消息嵌入到其它协议中，例如，基站之间的X2AP信令中、基站与核心网之间的S1AP信令中，将这些交互消息嵌入到这些协议的扩展字段进行发送，在此种情况下，可以不用建立通信设备之间的通信链接或初始化过程，交互消息的安全性由嵌入协议保证，对于如何在协议中嵌入交互消息，需要根据各个被嵌入协议消息的特点灵活定义，本实施例不做具体描述；另一方面，由于该过程发生于应用层，因此，该交互消息可以承载在UDP(UserDatagramProtocol，用户数据报协议)、TCP(TransmissionControlProtocol，传输控制协议)、SCTP(STREAMCONTROLTRANSMISSIONPROTOCOL，流控制传输协议)等传输层协议之上。如果通过UDP协议来承载，建议通信双方自定义UDP端口号，为了保证安全，建议选择未被定义的端口使用；如果通过TCP协议来承载，建议通信双方自定义TCP端口号，为了保证安全，建议选择未被定义的端口使用；如果通过SCTP协议来承载，建议通信双方自定义如何处理承载与SCTP流的关系，具体实现方式不属于本本实施范畴；对于LTE基站与LTE基站之间、LTE基站与EPC核心网之间，建议采用SCTP传输层协议来承载交互报文。如果采用其它传输层协议，建议用户根据网络及需求自行定义。

为了实现上述查询过程，本实施例提供一种查询消息的统一格式，当然，该查询消息的格式并不局限于本实施例提供的格式，用户可根据实际需要，自行定义相应的格式，该查询消息的统一格式如表7所示。

01234567890123456789012345678901

表7

针对上述格式中的标记、版本号、分组长度、发起端随机ID、响应端随机ID、类型、子类型以及检验和，这些字段的定义与初始化消息保持一致。

发起端设备ID号：表示查询发起端的设备ID号，这个字段在时钟查询过程中通信双方必须都要填写，响应端可通过初始化过程学习对端的设备ID号；

响应端设备ID号：表示查询响应端的设备ID号，这个字段在时钟查询过程中通信双方必须都要填写，发起端可通过初始化过程学习对端的设备ID号；

CkF：表示时钟类型、时钟子类型、时钟状态，这三个字段表示的时钟是发起端时钟状态还是响应端时钟状态，该字段占4bits，0x1表示发起端时钟状态，0x2表示响应端时钟状态；

OpFL：表示消息有无Option区域，该区域表述的项目是多少，每个项目由一个TLV(Type-length-value，类型-长度-值)表示，0x0表示无Option区域，0xn表示有n(1～f)个TLV；

时钟类型：占8bits，表示某一端的时钟类型，时钟类型的划分如表8所示；

表8

时钟子类型：占8个bits，表示某一端的时钟子类型，时钟子类型的划分如表9所示；

表9

时钟状态：表示发送消息端当前的时钟状态，目前暂定三种状态，0x01表示时钟正常锁定，时钟可用；0x02表示时钟失锁，时钟可用；0x00表示时钟不可用；0x03～0x0f为预留值；

Option区域：Option区域由若干个TLV格式构成，每个TLV代表着不同的意义，每个TLV均有一定的格式要求。Option区域的TLV的个数由OpFL字段定义，如果Option区域的TLV的数量大于OpFL字段中值，响应端对于多出的TLV作丢弃处理，但必须保证消息的校验和；如果Option区域的TLV的数量小于OpFL字段中值，响应端对该消息作丢弃处理，可利用拒绝报文的预留字段自行定义拒绝原因，本实施例不作强制规定。

TLV：TLV属于消息的Option区域的内容，是构成该区域的组件，不同的TLV表达的意义不相同，每个TLV的类型由类型+表述标识构成，长度字段表述的是该TLV所占用的字节数，值区域根据不同的类型，有所区别，其格式如表10所示；

01234567890123456789012345678901

表10

类型：具体参考时钟类型；

表述标识：表示该TLV的具体表述的内容，单独的表述标识无法确定具体内容，需要结合类型，各种组合描述如下：

当类型字段值为0x01，表述标识字段只能取0x01，表示时间的精度，考虑自此系统无参考时钟，此时系统无具体精度数值；

当类型字段值为0x02，表述标识字段可以取0x02(系统的搜星数)、0x03(系统的锁星数)、0x01(系统的时钟精度，差值)；

当类型字段值为0x03，表述标识字段可以取0x01(系统的时钟精度，差值)、0x4(上级时钟的时钟源类型)；

当类型字段值为0x04，表述标识字段可以取0x01(系统的时钟精度，差值)；

当类型字段值为0x05，表述标识字段可以取0x01(系统的时钟精度，差值)、0x05(时钟服务器标识，一般建议取时钟服务器的IP地址表述)；

当类型字段值为0x06，表述标识字段可以取0x01(系统的时钟精度，差值)、0x05(时钟服务器标识，一般建议取时钟服务器的IP地址表述)；

当类型字段值为0x07，表述标识字段可以取0x01(系统的时钟精度，差值)、0x05(时钟服务器标识，一般建议取时钟服务器的IP地址表述)。

长度：占16bits，表示该TLV的长度占多少字节；

针对TLV中的值域，当表述标识为“时钟精度”时，此值域的格式如表11所示：

01234567890123456789012345678901

时间单位表述

精度表述

表11

说明：一个TLV的字节数不大于8字节。

时间单位表述：指示精度表述域的时间单位，如表12所示；

标识值	标识值含义
		01	秒(s)
02	毫秒(ms)
		03	微妙(μs)
04	纳秒(ns)
		05	皮秒(ps)

表12

精度表述：表述的是某一端的时间精度，该值是系统的输入时钟与输出时钟的差，或者是具体的精度数据，具体表述为一个整数，该整数值所带的时间单位由“时间单位表述”字段指示。

根据上述查询消息的统一格式，时钟状态查询请求消息的格式如表13所示：

01234567890123456789012345678901

表13

时钟状态确认消息的格式如表14所示：

01234567890123456789012345678901

表14

结合上述格式，该查询过程中消息流的交互流程描述如下：

通过上述技术方案，以通信设备之间互相学习彼此的时钟状态为思想，定义彼此之间通信的消息格式，克服目前系统中存在的弊端，满足业务对时钟的特殊要求。

实施例二：

如图2为本发明实施例二提供的时钟状态查询方法的流程图，如图2所示，该时钟状态查询方法包括：

S201：接收对端设备发送的时钟状态查询请求消息；

S202：根据时钟状态查询请求消息，生成时钟状态响应消息，时钟状态响应消息包括本端设备的时钟状态信息；

S203：将时钟状态响应消息发送至对端设备；

S204：接收对端设备发送的时钟状态确认消息。

具体地，为了实现通信设备之间彼此相互了解时钟状态，保证了解状态的互联互通性，克服目前通信设备之间时钟状态彼此相互封闭的弊端，针对对端设备发起的时钟状态查询请求，本端设备需要对该时钟状态查询请求进行响应，从而完成对端设备的查询过程。该时钟状态查询方法是针对响应端的查询方法，即本实施例中的本端设备为响应端，对端设备为发起端。

在本实施例中，为了保证在时钟状态查询过程中的安全性及可靠性，优选地，在响应时钟状态的查询请求之前，可以先针对本端设备以及想要查询本端设备的对端设备，建立本端设备与对端设备之间的通信链接，即建立发起端与响应端之间的通信链接，需要说明的是，该建立通信链接的过程可理解为本端设备与对端设备进行初始化的过程，通过该初始化的过程，为时钟状态的查询提供安全、可靠的通信链路，当然，若通信设备之间已经建立了相应的通信链接或已经完成初始化过程，则本端设备可不进行上述过程，根据实际需要，直接响应向对端设备发起的时钟状态的查询请求。对于上述建立通信链接的方式，其包括但不局限于以下方式：

当本端设备接收对端设备发送的建链请求消息时，根据该建链请求消息，生成建链响应消息，将该建链响应消息发送至对端设备，之后接收对端设备发送的建链确认消息，即表示本端设备与对端设备之间的通信链路建立成功，初始化成功，本次会话结束；当本端设备接收到对端设备发送的建链请求消息时，可以拒绝该建链请求，将拒绝消息发送至对端设备，则表示建立通信链接失败，初始化失败，本次会话结束。需要说明的是，通过上述建立通信链接的过程，让本端设备与对端设备彼此之间了解、学习对端的标识信息，对于本端设备而言，该建链响应消息包括本端设备的标识信息，对端设备可以通过该建链响应消息了解、学习对端设备的标识信息，从而可以为之后的时钟状态查询提供必要的基础信息。针对上述建链响应消息以及拒绝消息的发送形式，可以以报文的形式在通信设备之间相互发送，当然，也可以采用其他形式。

对于上述初始化过程而言，当通信双方中的任何一方发起建链请求时，此处定义发起建链请求的一方为发起端，即对端设备，响应建链请求的一方为响应端，即本端设备，当响应端接收到建链请求消息后，有权拒绝该建链请求，但是响应端不允许立即发起建链请求，必须等待一段时间，例如等待10分钟以上，才可以发起建链请求；当响应端接收到建链请求消息后，就不得再发送建链请求消息，只有当本次会话结束一段时间后，例如本次会话结束3分钟后，方可以发起建链请求；在响应端接收到建链请求消息之前，可能先接收到发起端的拒绝消息，此时响应端必须等待发起端的建链请求消息，不得主动发送建链请求消息，只有等待一段时间后，例如等待时间必须在10分钟以上，才可以发起建链请求消息，针对该响应端，需要至少设置两个定时器，当响应端接收到建链请求消息或者拒绝消息时，启动第一个定时器，优选地，可以将该第一个定时器的时长设定为10分钟；当本次会话结束后，启动第二个定时器，优选地，可以将该第二定时器的时长设定为3分钟，只要这两个定时器中的任何一个超时，即定时器溢出，响应端均有权向对端发起建链请求，否则不能发起建链请求，需要说明的是，本实施例中的等待时间不作限制，可根据实际需要进行设定。

根据实施例一中提供的初始化消息的统一格式，该建链响应消息的格式如表15所示：

01234567890123456789012345678901

表15

响应端拒绝消息的格式如表16所示：

01234567890123456789012345678901

表16

对于建链响应消息中的响应端随机ID由响应端产生并填写，对于建链响应消息中的发起端随机ID，根据建链请求消息中的发起端随机ID填写。在之后的消息交互中，通信双方仅对自己产生的随机ID作加1处理，并保留对端的随机ID。通信双方核对本端随机ID，如果接收的消息中的本端随机ID不为本端发送的消息的随机ID(即当前随机ID)，则丢弃该消息，并发送拒绝消息给对端。本端的随机ID必须由本端进行修改，即针对发起端而言，其只能修改发起端的随机ID，不得私自修改响应端的随机ID。对于拒绝消息，不需要填写响应端随机ID，但需要填写类型、子类型、本端IP地址、设备ID号，以备发起端作验证所用。

在本实施例中，若通信双方已建立通信链接或已完成初始化，则本端设备可响应对端设备发起时钟状态查询请求。本端设备接收对端设备发送的时钟状态查询请求消息，根据该时钟状态查询请求消息，获取本端设备的时钟状态信息，生成时钟状态响应消息，该时钟状态响应消息包括本端设备的时钟状态信息，将该时钟状态响应消息发送至对端设备，若本端设备接收到对端设备发送的时钟状态确认消息，即表示对端设备已经获取到本端设备的时钟状态信息，本次查询成功，若本端设备接收到对端设备发送的拒绝消息，即表示对端设备没有获取到本端设备的时钟状态信息，本次查询失败。

在上述时钟状态查询的过程中，本端设备需要根据对端设备的请求结果，执行相应的操作。具体地，本端设备接收到对端设备发送的时钟状态查询请求消息，对该时钟状态查询请求消息进行验证，若验证为正确，则根据该时钟状态查询请求消息，生成时钟状态响应消息，该时钟状态响应消息包括本端设备的时钟状态信息，将该时钟状响应消息发送至对端设备，若接收到对端设备发送的时钟状态确认消息，则说明对端设备已接收到时钟状态响应消息，并获取到本端设备的时钟状态信息，即表示本次查询成功，若本端设备接收到对端设备发送的拒绝消息，则表示本次查询失败；若验证为错误，本端设备将拒绝消息发送至对端设备，则表示本端设备拒绝对端设备的时钟状态查询请求，即本次查询失败。

对于上述查询过程而言，当响应端接收到时钟状态查询请求消息后，有权拒绝该查询请求，但是响应端不允许立即发起时钟状态查询请求消息，必须等待一段时间，例如等待10分钟以上，才可以发起查询请求；当响应端接收到时钟状态查询请求消息后，就不得再发送时钟状态查询请求消息，只有当本次会话结束一段时间后，例如本次会话结束3分钟后，方可以发起查询请求；在响应端接收到时钟状态查询请求消息之前，可能先接收到发起端的拒绝消息，此时响应端必须等待发起端的时钟状态查询请求消息，不得主动发送时钟状态查询请求消息，只有等待一段时间后，例如等待时间必须在10分钟以上，才可以发起时钟状态查询请求消息，针对该响应端，需要至少设置两个定时器，当响应端接收到时钟状态查询请求消息或者拒绝消息时，启动第一个定时器，优选地，可以将该第一个定时器的时长设定为10分钟；当本次会话结束后，启动第二个定时器，优选地，可以将该第二定时器的时长设定为3分钟，只要这两个定时器中的任何一个超时，即定时器溢出，响应端均有权向对端发起查询请求，否则不能发起查询请求，需要说明的是，本实施例中的等待时间不作限制，可根据实际需要进行设定。

在上述技术方案中，对端设备可以了解并学习本端设备的时钟状态信息，若本端设备也同样想了解并学习对端设备的时钟状态信息，其可以在同一次查询过程中完成相应的操作，本实施例可以通过以下方式使本端设备同样了解并学习对端设备的时钟状态信息：

方式一、在查询过程中，若对端设备发送的时钟状态查询请求消息包括对端设备的时钟状态信息，则本端设备可以根据该时钟状态查询请求消息，获取对端设备的时钟状态信息，以便本端设备了解并学习对端设备的时钟状态信息；

方式二、在查询过程中，若对端设备发送的时钟状态查询请求消息没有包括对端设备的时钟状态信息，则本端设备根据时钟状态查询请求消息，获取本端设备的时钟状态信息，还生成时钟状态查询请求信息，生成时钟状态响应消息，该时钟状态响应消息包括本端设备的时钟状态信息、时钟状态查询请求信息(例如在时钟状态响应消息的Option区域填写该信息)。本端设备接收对端设备发送的时钟状态确认消息，该时钟状态确认消息中包括对端设备的时钟状态信息，本端设备根据该时钟状态确认消息，获取对端设备的时钟状态信息，以便本端设备了解并学习本端设备的时钟状态信息；

方式三、在查询过程中，若对端设备发送的时钟状态查询请求消息包括对端设备的时钟状态信息，本端设备生成的时钟状态响应消息既可以包括时钟状态查询请求信息，也可以不包括时钟状态查询请求信息，将该时钟状态响应消息发送至对端设备，接收对端设备发送的时钟状态确认消息，该时钟状态确认消息同样也包括对端设备的时钟状态信息，本端设备可根据时钟状态查询请求消息和/或时钟状态确认消息，获取对端设备的时钟状态信息，以本端设备了解并学习对端设备的时钟状态信息。

在上述技术方案中，对于时钟状态响应消息以及拒绝消息的发送方式，一方面，可以将这些交互消息嵌入到其它协议中，例如，基站之间的X2AP信令中、基站与核心网之间的S1AP信令中，将这些交互消息嵌入到这些协议的扩展字段进行发送，在此种情况下，可以不用建立通信设备之间的通信链接或初始化过程，交互消息的安全性由嵌入协议保证，对于如何在协议中嵌入交互消息，需要根据各个被嵌入协议消息的特点灵活定义，本实施例不做具体描述；另一方面，由于该过程发生于应用层，因此，该交互消息可以承载在UDP(UserDatagramProtocol，用户数据报协议)、TCP(TransmissionControlProtocol，传输控制协议)、SCTP(STREAMCONTROLTRANSMISSIONPROTOCOL，流控制传输协议)等传输层协议之上。如果通过UDP协议来承载，建议通信双方自定义UDP端口号，为了保证安全，建议选择未被定义的端口使用；如果通过TCP协议来承载，建议通信双方自定义TCP端口号，为了保证安全，建议选择未被定义的端口使用；如果通过SCTP协议来承载，建议通信双方自定义如何处理承载与SCTP流的关系，具体实现方式不属于本本实施范畴；对于LTE基站与LTE基站之间、LTE基站与EPC核心网之间，建议采用SCTP传输层协议来承载交互报文。如果采用其它传输层协议，建议用户根据网络及需求自行定义。

根据实施例一中提供的查询消息的统一格式，该时钟状态响应消息的格式如表17所示：

01234567890123456789012345678901

表17

通过上述技术方案，以通信设备之间互相学习彼此的时钟状态为思想，定义彼此之间通信的消息格式，克服目前系统中存在的弊端，满足业务对时钟的特殊要求。

实施例三：

如图3为本发明实施例三提供的通信设备的结构示意图，如图3所示，该通信设备1包括：

第一生成模块11，用于生成时钟状态查询请求消息；

第一发送模块12，用于将第一生成模块11生成的时钟状态查询请求消息发送至对端设备，还用于将时钟状态确认消息发送至对端设备；

第一接收模块13，用于接收对端设备发送的时钟状态响应消息，时钟状态响应消息包括对端设备的时钟状态信息；

第一获取模块14，用于根据第一接收模块13接收的时钟状态响应消息，获取对端设备的时钟状态信息。

优选地，该通信设备1还包括第一通信模块15，该第一通信模块15用于建立本端设备与对端设备之间的通信链接。

优选地，第一生成模块11还用于生成建链请求消息，还用于根据建链响应消息，生成建链确认消息，第一发送模块12还用于将第一生成模块11生成的建链请求消息发送至对端设备，还用于将第一生成模块11生成的建链确认消息发送至对端设备，第一接收模块13还用于接收对端设备发送的建链响应消息。

优选地，该通信设备1还包括第一验证模块16，该第一验证模块16用于验证时钟状态响应消息是否正确，第一获取模块14用于若第一验证模块16验证正确，则根据时钟状态响应消息，获取对端设备的时钟状态信息，该第一验证模块16还用于验证建链响应消息是否正确。

优选地，第一获取模块14还用于获取本端设备的时钟状态信息，第一生成模块11具体用于生成时钟状态查询请求消息，生成时钟状态查询请求消息包括本端设备的时钟状态信息，还用于生成时钟状态确认消息，时钟状态确认消息包括本端设备的时钟状态信息。

实施例四：

如图4为本发明实施例四提供的通信设备的结构示意图，如图4所示，该通信设备2包括：

第二接收模块21，用于接收对端设备发送的时钟状态查询请求消息，还用于接收对端设备发送的时钟状态确认消息；

第二生成模块22，用于根据第二接收模块21接收的时钟状态查询请求消息，生成时钟状态响应消息，时钟状态响应消息包括本端设备的时钟状态信息；

第二发送模块23，用于将第二生成模块22生成的时钟状态响应消息发送至对端设备。

优选地，该通信设备2还包括第二通信模块24，该第二通信模块24用于建立本端设备与对端设备之间的通信链接。

优选地，第二接收模块21还用于接收对端设备发送的建链请求消息，还用于接收对端设备发送的建链确认消息，第二生成模块22还用于根据第二接收模块21接收的建链请求消息，生成建链响应消息，第二发送模块23还用于将第二生成模块22生成的建链响应消息发送至对端设备。

优选地，该通信设备2还包括第二验证模块25，该第二验证模块25用于验证时钟状态查询请求消息是否正确，第二生成模块22用于若第二验证模块25验证正确，则根据时钟状态查询请求消息，生成时钟状态响应消息，时钟状态响应消息包括本端设备的时钟状态信息，该第二验证模块25还用于验证建链请求消息是否正确。

优选地，该通信设备2还包括第二获取模块26，该第二获取模块26用于根据第二接收模块21接收的时钟状态查询请求消息，获取本端设备的时钟状态信息，第二生成模块22还用于生成时钟状态查询请求信息，第二生成模块22具体用于生成时钟状态响应消息，时钟状态响应消息包括所述本端设备的时钟状态信息、时钟状态查询请求信息。

实施例五：

如图5为本发明实施例五提供的时钟状态查询系统的结构示意图，如图5所示，该时钟状态查询系统包括至少一个第一通信设备以及至少一个第二通信设备，第一通信设备为实施例三中的通信设备1，第二通信设备为实施例四中的通信设备2。

第一通信设备生成时钟状态查询请求消息，将时钟状态查询请求消息发送至第二通信设备，第二通信设备接收第一通信设备发送的时钟状态查询请求消息，根据时钟状态查询请求消息，生成时钟状态响应消息，时钟状态响应消息包括第二通信设备的时钟状态信息，将时钟状态响应消息发送至第一通信设备，第一通信设备接收第二通信设备发送的时钟状态响应消息，时钟状态响应消息包括第二通信设备的时钟状态信息，根据时钟状态响应消息，获取第二通信设备的时钟状态信息，将时钟状态确认消息发送至第二通信设备，第二通信设备接收第一通信设备发送的时钟状态确认消息。

实施例六：

本实施例还提供一种时钟状态查询方法，第一通信设备生成时钟状态查询请求消息，将时钟状态查询请求消息发送至第二通信设备，第二通信设备接收第一通信设备发送的时钟状态查询请求消息，根据时钟状态查询请求消息，生成时钟状态响应消息，时钟状态响应消息包括第二通信设备的时钟状态信息，将时钟状态响应消息发送至第一通信设备，第一通信设备接收第二通信设备发送的时钟状态响应消息，根据时钟状态响应消息，获取第二通信设备的时钟状态信息，将时钟状态确认消息发送至第二通信设备，第二通信设备接收第一通信设备发送的时钟状态确认消息，完成时钟状态的查询。

优选地，在第一通信设备生成时钟状态查询请求消息，将时钟状态查询请求消息发送至第二通信设备之前，还包括建立第一通信设备与第二通信设备之间的通信链接。

以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (23)

1.一种时钟状态查询方法，其特征在于，包括：

生成时钟状态查询请求消息；

将所述时钟状态查询请求消息发送至对端设备；

接收所述对端设备发送的时钟状态响应消息，所述时钟状态响应消息包括所述对端设备的时钟状态信息；

根据所述时钟状态响应消息，获取所述对端设备的时钟状态信息；

将时钟状态确认消息发送至所述对端设备。

2.根据权利要求1所述的时钟状态查询方法，其特征在于，在生成时钟状态查询请求消息之前，还包括：

建立本端设备与所述对端设备之间的通信链接。

3.根据权利要求2所述的时钟状态查询方法，其特征在于，建立本端设备与所述对端设备之间的通信链接具体包括：

生成建链请求消息；

将所述建链请求消息发送至所述对端设备；

接收所述对端设备发送的建链响应消息；

根据所述建链响应消息，生成建链确认消息；

将所述建链确认消息发送至所述对端设备。

4.根据权利要求1所述的时钟状态查询方法，其特征在于，在根据所述时钟状态响应消息，获取所述对端设备的时钟状态信息之前，还包括：

验证所述时钟状态响应消息是否正确；

若正确，则进入根据所述时钟状态响应消息，获取所述对端设备的时钟状态信息的步骤。

5.根据权利要求1-4任一项所述的时钟状态查询方法，其特征在于，

所述生成时钟状态查询请求消息具体包括：

获取本端设备的时钟状态信息；

生成时钟状态查询请求消息，所述时钟状态查询请求消息包括所述本端设备的时钟状态信息；

和/或，

在所述将时钟状态确认消息发送至所述对端设备之前，还包括：

获取本端设备的时钟状态信息；

生成时钟状态确认消息，所述时钟状态确认消息包括所述本端设备的时钟状态信息。

6.一种时钟状态查询方法，其特征在于，包括：

接收对端设备发送的时钟状态查询请求消息；

根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息；

将所述时钟状态响应消息发送至所述对端设备；

接收所述对端设备发送的时钟状态确认消息。

7.根据权利要求6所述的时钟状态查询方法，其特征在于，在接收对端设备发送的时钟状态查询请求消息之前，还包括：

建立本端设备与所述对端设备之间的通信链接。

8.根据权利要求7所述的时钟状态查询方法，其特征在于，建立本端设备与所述对端设备之间的通信链接具体包括：

接收所述对端设备发送的建链请求消息；

根据所述建链请求消息，生成建链响应消息；

将所述建链响应消息发送至所述对端设备；

接收所述对端设备发送的建链确认消息。

9.根据权利要求6所述的时钟状态查询方法，其特征在于，在根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息之前，还包括：

验证所述时钟状态查询请求消息是否正确；

若正确，则进入根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息的步骤。

10.根据权利要求6-9任一项所述的时钟状态查询方法，其特征在于，根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息具体包括：

根据所述时钟状态查询请求消息，获取本端设备的时钟状态信息；

生成时钟状态查询请求信息；

生成时钟状态响应消息，所述时钟状态响应消息包括所述本端设备的时钟状态信息、时钟状态查询请求信息。

11.一种时钟状态查询方法，其特征在于，包括：

本端设备生成时钟状态查询请求消息，将所述时钟状态查询请求消息发送至对端设备；

所述对端设备接收所述本端设备发送的时钟状态查询请求消息，根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括所述对端设备的时钟状态信息，将所述时钟状态响应消息发送至所述本端设备；

所述本端设备接收所述对端设备发送的时钟状态响应消息，所述时钟状态响应消息包括所述对端设备的时钟状态信息，根据所述时钟状态响应消息，获取所述对端设备的时钟状态信息，将时钟状态确认消息发送至所述对端设备；

所述对端设备接收所述本端设备发送的时钟状态确认消息。

12.根据权利要求11所述的时钟状态查询方法，其特征在于，在本端设备生成时钟状态查询请求消息，将所述时钟状态查询请求消息发送至对端设备之前，还包括：

建立所述本端设备与所述对端设备之间的通信链接。

13.一种通信设备，其特征在于，包括：

第一生成模块，用于生成时钟状态查询请求消息；

第一发送模块，用于将所述第一生成模块生成的时钟状态查询请求消息发送至对端设备，还用于将时钟状态确认消息发送至所述对端设备；

第一接收模块，用于接收所述对端设备发送的时钟状态响应消息，所述时钟状态响应消息包括所述对端设备的时钟状态信息；

第一获取模块，用于根据所述第一接收模块接收的时钟状态响应消息，获取所述对端设备的时钟状态信息。

14.根据权利要求13所述的通信设备，其特征在于，还包括：

第一通信模块，用于建立本端设备与所述对端设备之间的通信链接。

15.根据权利要求14所述的通信设备，其特征在于，

所述第一生成模块还用于生成建链请求消息，还用于根据建链响应消息，生成建链确认消息；

所述第一发送模块还用于将所述第一生成模块生成的建链请求消息发送至所述对端设备，还用于将所述第一生成模块生成的建链确认消息发送至所述对端设备；

所述第一接收模块还用于接收所述对端设备发送的建链响应消息。

16.根据权利要求13所述的通信设备，其特征在于，还包括：

第一验证模块，用于验证所述时钟状态响应消息是否正确；

所述第一获取模块用于若所述第一验证模块验证正确，则根据所述时钟状态响应消息，获取所述对端设备的时钟状态信息。

17.根据权利要求13-16任一项所述的通信设备，其特征在于，

所述第一获取模块还用于获取本端设备的时钟状态信息；

所述第一生成模块具体用于生成时钟状态查询请求消息，所述生成时钟状态查询请求消息包括所述本端设备的时钟状态信息，还用于生成时钟状态确认消息，所述时钟状态确认消息包括所述本端设备的时钟状态信息。

18.一种通信设备，其特征在于，包括：

第二接收模块，用于接收对端设备发送的时钟状态查询请求消息，还用于接收所述对端设备发送的时钟状态确认消息；

第二生成模块，用于根据所述第二接收模块接收的时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息；

第二发送模块，用于将所述第二生成模块生成的时钟状态响应消息发送至所述对端设备。

19.根据权利要求18所述的通信设备，其特征在于，还包括：

第二通信模块，用于建立本端设备与所述对端设备之间的通信链接。

20.根据权利要求19所述的通信设备，其特征在于，

所述第二接收模块还用于接收所述对端设备发送的建链请求消息，还用于接收所述对端设备发送的建链确认消息；

所述第二生成模块还用于根据所述第二接收模块接收的建链请求消息，生成建链响应消息；

所述第二发送模块还用于将所述第二生成模块生成的建链响应消息发送至所述对端设备。

21.根据权利要求18所述的通信设备，其特征在于，还包括：

第二验证模块，用于验证所述时钟状态查询请求消息是否正确；

所述第二生成模块用于若所述第二验证模块验证正确，则根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括本端设备的时钟状态信息。

22.根据权利要求18-21任一项所述的通信设备，其特征在于，还包括：

第二获取模块，用于根据所述第二接收模块接收的时钟状态查询请求消息，获取本端设备的时钟状态信息；

所述第二生成模块还用于生成时钟状态查询请求信息；

所述第二生成模块具体用于生成时钟状态响应消息，所述时钟状态响应消息包括所述本端设备的时钟状态信息、时钟状态查询请求信息。

23.一种时钟状态查询系统，其特征在于，包括至少一个第一通信设备以及至少一个第二通信设备，所述第一通信设备为如权利要求13-17任一项所述的通信设备，所述第二通信设备为如权利要求18-22任一项所述的通信设备；

所述第一通信设备生成时钟状态查询请求消息，将所述时钟状态查询请求消息发送至第二通信设备，所述第二通信设备接收所述第一通信设备发送的时钟状态查询请求消息，根据所述时钟状态查询请求消息，生成时钟状态响应消息，所述时钟状态响应消息包括所述第二通信设备的时钟状态信息，将所述时钟状态响应消息发送至所述第一通信设备，所述第一通信设备接收所述第二通信设备发送的时钟状态响应消息，所述时钟状态响应消息包括所述第二通信设备的时钟状态信息，根据所述时钟状态响应消息，获取所述第二通信设备的时钟状态信息，将时钟状态确认消息发送至所述第二通信设备，所述第二通信设备接收所述第一通信设备发送的时钟状态确认消息。