例中的等待时间不作限制， 可根据实际需要进行设定。
[0155] 在上述技术方案中，本端设备可以了解并学习对端设备的时钟状态信息，若对端 设备也同样想了解并学习本端设备的时钟状态信息，其可以在同一次查询过程中完成相 应的操作，本实施例可以通过以下方式使对端设备同样了解并学习本端设备的时钟状态信 息：
[0156] 方式一、在查询过程中，本端设备可以先获取本端设备的时钟状态信息，获取完成 后，生成时钟状态查询请求消息，该时钟状态查询请求消息包括本端设备的时钟状态信息， 将该时钟状态查询请求消息发送至对端设备，以便对端设备了解并学习本端设备的时钟状 态息；
[0157] 方式二、在查询过程中，本端设备接收到对端设备发送的时钟状态响应消息后，可 以获取本端设备的时钟状态信息，获取完成后，生成时钟状态确认消息，该时钟状态确认消 息包括本端设备的时钟状态信息，将该时钟状态确认消息发送至对端设备，以便对端设备 了解并学习本端设备的时钟状态信息；
[0158] 方式三、在查询过程中，本端设备可以先获取本端设备的时钟状态信息，获取完成 后，生成时钟状态查询请求消息，该时钟状态查询请求消息包括本端设备的时钟状态信息， 将该时钟状态查询请求消息发送至对端设备，本端设备接收到对端设备发送的时钟状态响 应消息后，可以获取本端设备的时钟状态信息，获取完成后，生成时钟状态确认消息，该时 钟状态确认消息包括本端设备的时钟状态信息，将该时钟状态确认消息发送至对端设备， 以便对端设备了解并学习本端设备的时钟状态信息。
[0159] 在上述技术方案中，对于时钟状态查询请求消息、时钟状态确认消息以及拒绝消 息的发送方式，一方面，可以将这些交互消息嵌入到其它协议中，例如，基站之间的X2AP信 令中、基站与核心网之间的S1AP信令中，将这些交互消息嵌入到这些协议的扩展字段进行 发送，在此种情况下，可以不用建立通信设备之间的通信链接或初始化过程，交互消息的安 全性由嵌入协议保证，对于如何在协议中嵌入交互消息，需要根据各个被嵌入协议消息的 特点灵活定义，本实施例不做具体描述；另一方面，由于该过程发生于应用层，因此，该交 互消息可以承载在UDP(User Datagram Protocol,用户数据报协议）、TCP(Transmission Control Protocol，传输控制协议）、SCTP(STREAM CONTROL TRANSMISSION PROTOCOL，流控 制传输协议）等传输层协议之上。如果通过UDP协议来承载，建议通信双方自定义UDP端 口号，为了保证安全，建议选择未被定义的端口使用；如果通过TCP协议来承载，建议通信 双方自定义TCP端口号，为了保证安全，建议选择未被定义的端口使用；如果通过SCTP协议 来承载，建议通信双方自定义如何处理承载与SCTP流的关系，具体实现方式不属于本本实 施范畴；对于LTE基站与LTE基站之间、LTE基站与EPC核心网之间，建议采用SCTP传输层 协议来承载交互报文。如果采用其它传输层协议，建议用户根据网络及需求自行定义。
[0160] 为了实现上述查询过程，本实施例提供一种查询消息的统一格式，当然，该查询消 息的格式并不局限于本实施例提供的格式，用户可根据实际需要，自行定义相应的格式，该 查询消息的统一格式如表7所7K。
[0161] 01234567890123456789012345678901
[0162]
[0163]
[0164] 表 7
[0165] 针对上述格式中的标记、版本号、分组长度、发起端随机ID、响应端随机ID、类型、 子类型以及检验和，这些字段的定义与初始化消息保持一致。
[0166] 发起端设备ID号：表示查询发起端的设备ID号，这个字段在时钟查询过程中通信 双方必须都要填写，响应端可通过初始化过程学习对端的设备ID号；
[0167] 响应端设备ID号：表示查询响应端的设备ID号，这个字段在时钟查询过程中通信 双方必须都要填写，发起端可通过初始化过程学习对端的设备ID号；
[0168] CkF :表示时钟类型、时钟子类型、时钟状态，这三个字段表示的时钟是发起端时钟 状态还是响应端时钟状态，该字段占4bits，0x1表示发起端时钟状态，0x2表示响应端时钟 状态；
[0169] OpFL :表示消息有无 Option区域，该区域表述的项目是多少，每个项目由一个 TLV (Type-length-value，类型-长度-值）表示，0x0表示无 Option区域，Oxn表示有η (1~ f)个 TLV ;
[0170] 时钟类型：占8bits，表示某一端的时钟类型，时钟类型的划分如表8所示；
[0171] Η
Η …I Η
[0172] 表 8
[0173] 时钟子类型：占8个bits，表示某一端的时钟子类型，时钟子类型的划分如表9所 示；
[0174]
I.
[0175] S j
[0176] 表 9
[0177] 时钟状态：表示发送消息端当前的时钟状态，目前暂定三种状态，0x01表示时钟 正常锁定，时钟可用；0x02表示时钟失锁，时钟可用；0x00表示时钟不可用；0x03~OxOf为 预留值；
[0178] Option区域：0ption区域由若干个TLV格式构成，每个TLV代表着不同的意义，每 个TLV均有一定的格式要求。Option区域的TLV的个数由OpFL字段定义，如果Option区 域的TLV的数量大于OpFL字段中值，响应端对于多出的TLV作丢弃处理，但必须保证消息 的校验和；如果Option区域的TLV的数量小于OpFL字段中值，响应端对该消息作丢弃处 理，可利用拒绝报文的预留字段自行定义拒绝原因，本实施例不作强制规定。
[0179] TLV :TLV属于消息的Option区域的内容，是构成该区域的组件，不同的TLV表达 的意义不相同，每个TLV的类型由类型+表述标识构成，长度字段表述的是该TLV所占用的 字节数，值区域根据不同的类型，有所区别，其格式如表10所示；
[0180] 01234567890123456789012345678901
[0181]
[0182] 表 10
[0183] 类型：具体参考时钟类型；
[0184] 表述标识：表示该TLV的具体表述的内容，单独的表述标识无法确定具体内容，需 要结合类型，各种组合描述如下：
[0185] 当类型字段值为0x01，表述标识字段只能取0x01，表示时间的精度，考虑自此系 统无参考时钟，此时系统无具体精度数值；
[0186] 当类型字段值为0x02,表述标识字段可以取0x02 (系统的搜星数）、0x03(系统的 锁星数）、〇χ〇1(系统的时钟精度，差值）；
[0187] 当类型字段值为0x03,表述标识字段可以取0x01 (系统的时钟精度，差值）、 0x4 (上级时钟的时钟源类型）；
[0188] 当类型字段值为0x04,表述标识字段可以取0x01 (系统的时钟精度，差值）；
[0189] 当类型字段值为0x05,表述标识字段可以取0x01 (系统的时钟精度，差值）、 0x05 (时钟服务器标识，一般建议取时钟服务器的IP地址表述）；
[0190] 当类型字段值为0x06,表述标识字段可以取0x01 (系统的时钟精度，差值）、 0x05 (时钟服务器标识，一般建议取时钟服务器的IP地址表述）；
[0191] 当类型字段值为0x07,表述标识字段可以取0x01 (系统的时钟精度，差值）、 0x05 (时钟服务器标识，一般建议取时钟服务器的IP地址表述）。
[0192] 长度：占16bits，表示该TLV的长度占多少字节；
[0193] 针对TLV中的值域，当表述标识为"时钟精度"时，此值域的格式如表11所示：
[0194] 01234567890123456789012345678901
[0195]
[0196] 表 11
[0197] 说明：一个TLV的字节数不大于8字节。
[0198] 时间单位表述：指示精度表述域的时间单位，如表12所示；
[0199]
[0200] 表 12
[0201] 精度表述：表述的是某一端的时间精度，该值是系统的输入时钟与输出时钟的差， 或者是具体的精度数据，具体表述为一个整数，该整数值所带的时间单位由"时间单位表 述"字段指示。
[0202] 根据上述查询消息的统一格式，时钟状态查询请求消息的格式如表13所示：
[0203] 01234567890123456789012345678901
[0204]
[0205] 表 13
[0206] 时钟状态确认消息的格式如表14所示：
[0207] 01234567890123456789012345678901
[0208]
[0209] 表 14
[0210] 结合上述格式，该查询过程中消息流的交互流程描述如下：
[0211]
[0212] 通过上述技术方案，以通信设备之间互相学习彼此的时钟状态为思想，定义彼此 之间通信的消息格式，克服目前系统中存在的弊端，满足业务对时钟的特殊要求。
[0213] 实施例二：
[0214] 如图2为本发明实施例二提供的时钟状态查询方法的流程图，如图2所示，该时钟 状态查询方法包括：
[0215] S201 :接收对端设备发送的时钟状态查询请求消息；
[0216] S202 :根据时钟状态查询请求消息，生成时钟状态响应消息，时钟状态响应消息包 括本端设备的时钟状态信息；
[0217] S203 :将时钟状态响应消息发送至对端设备；
[0218] S204 :接收对端设备发送的时钟状态确认消息。
[0219] 具体地，为了实现通信设备之间彼此相互了解时钟状态，保证了解状态的互联互 通性，克服目前通信设备之间时钟状态彼此相互封闭的弊端，针对对端设备发起的时钟状 态查询请求，本端设备需要对该时钟状态查询请求进行响应，从而完成对端设备的查询过 程。该时钟状态查询方法是针对响应端的查询方法，即本实施例中的本端设备为响应端，对 端设备为发起端。
[0220] 在本实施例中，为了保证在时钟状态查询过程中的安全性及可靠性，优选地，在响 应时钟状态的查询请求之前，可以先针对本端设备以及想要查询本端设备的对端设备，建 立本端设备与对端设备之间的通信链接，即建立发起端与响应端之间的通信链接，需要说 明的是，该建立通信链接的过程可理解为本端设备与对端设备进行初始化的过程，通过该 初始化的过程，为时钟状态的查询提供安全、可靠的通信链路，当然，若通信设备之间已经 建立了相应的通信链接或已经完成初始化过程，则本端设备可不进行上述过程，根据实际 需要，直接响应向对端设备发起的时钟状态的查询请求。对于上述建立通信链接的方式，其 包括但不局限于以下方式：
[0221] 当本端设备接收对端设备发送的建链请求消息时，根据该建链请求消息，生成建 链响应消息，将该建链响应消息发送至对端设备，之后接收对端设备发送的建链确认消息， 即表示本端设备与对端设备之间的通信链路建立成功，初始化成功，本次会话结束；当本端 设备接收到对端设备发送的建链请求消息时，可以拒绝该建链请求，将拒绝消息发送至对 端设备，则表示建立通信链接失败，初始化失败，本次会话结束。需要说明的是，通过上述建 立通信链接的过程，让本端设备与对端设备彼此之间了解、学习对端的标识信息，对于本端 设备而言，该建链响应消息包括本端设备的标识信息，对端设备可以通过该建链响应消息 了解、学习对端设备的标识信息，从而可以为之后的时钟状态查询提供必要的基础信息。针 对上述建链响应消息以及拒绝消息的发送形式，可以以报文的形式在通信设备之间相互发 送，当然，也可以采用其他形式。
[0222] 对于上述初始化过程而言，当通信双方中的任何一方发起建链请求时，此处定义 发起建链请求的一方