学习提供了解决思路和方法，也为后续时钟的演进提供支 撑。此外，无论对于无线宽带技术，还是有线带宽技术，通过本技术方案，就能够互相了解、 学习彼此之间时钟获取方式、时钟状态以及时钟精度等参数，以保证终端客户在不同基站 之间切换业务不中断，为系统的运营、操作提供判定依据。例如，在移动通信领域，终端在不 同基站设备之间的切换，通过本技术方案，基站就可以判定涉及切换的两基站的时钟状态 条件是否满足用户业务成功切换的条件，降低因为时钟状态问题导致用户业务切换掉话的 概率，从而提升移动终端在不同基站设备之间的切换成功率。
【附图说明】
[0091] 图1为本发明实施例一提供的时钟状态查询方法的流程图；
[0092] 图2为本发明实施例二提供的时钟状态查询方法的流程图；
[0093] 图3为本发明实施例三提供的通信设备的结构示意图；
[0094] 图4为本发明实施例四提供的通信设备的结构示意图；
[0095] 图5为本发明实施例五提供的时钟状态查询系统的结构示意图。
【具体实施方式】
[0096] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完 整地描述，显然，所描述的实施例只是本发明中一部分实施例，而不是全部的实施例。基于 本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他 实施例，都属于本发明保护的范围。
[0097] 下面通过【具体实施方式】结合附图对本发明作进一步详细说明。
[0098] 实施例一：
[0099] 如图1为本发明一实施例提供的时钟状态查询方法的流程图，如图1所示，该时钟 状态查询方法包括：
[0100] S101 :生成时钟状态查询请求消息；
[0101] S102 :将时钟状态查询请求消息发送至对端设备；
[0102] S103 :接收对端设备发送的时钟状态响应消息，时钟状态响应消息包括对端设备 的时钟状态信息；
[0103] S104 :根据时钟状态响应消息，获取对端设备的时钟状态信息；
[0104] S105 :将时钟状态确认消息发送至对端设备。
[0105] 具体地，为了实现通信设备之间彼此相互了解时钟状态，保证了解状态的互联互 通性，克服目前通信设备之间时钟状态彼此相互封闭的弊端，对于任何一个通信设备而言， 均可以针对其所想要了解、学习的另一个通信设备，发起时钟状态的查询请求。该时钟状态 查询方法为针对发起端的查询方法，即本实施例中的本端设备为发起端，对端设备为响应 端。
[0106] 在本实施例中，为了保证在时钟状态查询过程中的安全性及可靠性，优选地，在发 起时钟状态的查询请求之前，可以先针对本端设备以及本端设备想要查询的对端设备，建 立本端设备与对端设备之间的通信链接，即建立发起端与响应端之间的通信链接，需要说 明的是，该建立通信链接的过程可理解为本端设备与对端设备进行初始化的过程，通过该 初始化的过程，为时钟状态的查询提供安全、可靠的通信链路，当然，若通信设备之间已经 建立了相应的通信链接或已经完成初始化过程，则本端设备可不进行上述过程，根据实际 需要，直接向对端设备发起时钟状态的查询请求。对于上述建立通信链接的方式，其包括但 不局限于以下方式：
[0107] 本端设备生成建链请求消息，将该建链请求消息发送至对端设备，对端设备对该 建链请求消息进行响应，本端设备接收对端设备响应后发送的建链响应消息，根据该建链 响应消息，生成建链确认消息，再将该建链确认消息发送至对端设备，用以告诉对端设备， 本端设备已接收到响应消息，即表示本端设备与对端设备之间的通信链路建立成功。需要 说明的是，通过上述建立通信链接的过程，让本端设备与对端设备彼此之间了解、学习对端 的标识信息，对于本端设备而言，该建链请求消息包括本端设备的标识信息，和/或，该建 链确认消息包括本端设备的标识信息，对端设备可以通过该建链请求消息和/或建链确认 消息了解、学习本端设备的标识信息，从而可以为之后的时钟状态查询提供必要的基础信 息，该标识信息包括但不局限于设备ID号，该设备ID号可以由用户自行定义，使其可以对 设备进行标识，例如，对于基站而言，优选地，采用基站ID号作为设备ID号。
[0108] 在上述建立通信链接的过程中，本端设备需要根据对端设备的响应结果，执行相 应的操作。具体地，如果本端设备接收到对端设备发送的建链响应消息，对该建链响应消息 进行验证，若验证为正确，即发送该建链响应消息的对端设备为本端设备想要查询时钟状 态的对端设备，根据该建链响应消息，生成建链确认消息，将该建链确认消息发送至对端设 备，用于告诉对端设备，本端设备已接收到响应消息，则表示建立通信链接成功，本次会话 成功，即初始化成功；若验证为错误，即发送该建链响应消息的对端设备不是本端设备想要 查询的对端设备，将拒绝消息发送至对端设备，则表示建立通信链接失败，本次会话结束， 即初始化失败；若本端设备接收到对端设备发送的拒绝消息，则表示建立通信链接失败，本 次会话结束，即初始化失败。针对上述建链请求消息、建链确认消息以及拒绝消息的发送形 式，可以以报文的形式在通信设备之间相互发送，当然，也可以采用其他形式。
[0109] 对于上述初始化过程而言，通信双方中的任何一方均可以发起建链请求，此处定 义发起建链请求的一方为发起端，即本端设备，响应建链请求的一方为响应端，即对端设 备，发起端在发出建链请求消息后，如果此时接收到自己所发出的建链请求消息的响应端 的建链请求消息，则发起端必须采用拒绝操作，并向响应端发送拒绝消息，针对该发起端， 需要至少设置一个定时器，优选地，可以将该定期器的时长设定为10分钟，当定时器超时 后，则需要响应对端的建链请求消息，而不应该发送拒绝消息，需要说明的是，本实施例中 的等待时间不作限制，可根据实际需要进行设定。
[0110] 为了实现上述初始化过程，本实施例提供一种初始化消息的统一格式，当然，该初 始化消息的格式并不局限于本实施例提供的格式，用户可根据实际需要，自行定义相应的 格式，该初始化消息的统一格式如表1所不。
[0111] 01234567890123456789012345678901
[0112]
[0113] 表 1
[0114] 其中，标记位：占用8bits，固定为Oxaf ;
[0115] 版本号：占用8bits,当前固定填0x01 ;
[0116] 分组长度：该字段占16bits，用于表述上述格式的长度（占用多少个字节）；
[0117] 发起端随机ID:由发起端产生的随机数，用16bits标识；
[0118] 响应端随机ID :由响应端产生的随机数，用16bits标识；
[0119] 类型：用于标识消息类型，用8bits标识，其取值如表2所示；
[0120]
[0121] 表 2
[0122] 预留：使用Oxff填写；
[0123] 校验和：报文的校验字段，用于校验消息是否正确；
[0124] 子类型：表示消息的子码类型，用8bits表示，其取值如表3所示；
[0125]
[0126]
[0127] 表 3
[0128] IP版本：占4bits，0x4表示消息发起端为IPv4地址，0x6表示消息发起端为IPv6 地址；
[0129] 设备ID号：占20bits，用于标识设备的ID，要求设备的ID号在网络中是唯一的；
[0130] IP地址：该字段填写消息发起端的源IP地址，其中，IPv4占用32bits，Ipv6占用 128bits〇
[0131] 针对上述统一格式中的随机ID的生成方法，可以由通信双方自行定义其生成随 机ID的函数，且相互之间保持独立。本实施例提供一种定义方式，该随机ID的函数的输入 参数包括设备ID号、承载报文的IP地址（源端+目的端）、协议类型、传输层端口号（如果 无，建议取全1)、差生随机数的时间（年、月、日、小时、分钟、秒），当然，用户也可根据实际 需求，自行定义。当通信双方中的任何一方接收到对端的消息后，必须验证该随机ID是否 正确，对于不正确的随机ID，任何一方均可以发送拒绝消息，从而中断本次会话。
[0132] 根据上述初始化消息的统一格式，建链请求消息的格式如表4所示：
[0133] 01234567890123456789012345678901
[0134]
[0135]
[0136] 表 4
[0137] 建链确认消息的格式如表5所示：
[0138] 01234567890123456789012345678901
[0139]
[0140] 表 5
[0141] 发起端拒绝消息的格式如表6所示：
[0142] 01234567890123456789012345678901
[0143]
[0144] 表 6
[0145] 对于建链请求消息中的发起端随机ID由发起端产生并填写，对于建链请求消息 中的响应端随机ID，发起端使用0来填写。在之后的消息交互中，通信双方仅对自己产生的 随机ID作加1处理，并保留对端的随机ID。通信双方核对本端随机ID，如果接收的消息中 的本端随机ID不为本端发送的消息的随机ID (即当前随机ID)，则丢弃该消息，并发送拒绝 消息给对端。本端的随机ID必须由本端进行修改，即针对发起端而言，其只能修改发起端 的随机ID，不得私自修改响应端的随机ID。对于拒绝消息，不需要填写响应端随机ID，但需 要填写类型、子类型、本端IP地址、设备ID号，以备发起端作验证所用。
[0146] 结合上述格式，该初始化过程中消息流的交互流程描述如下：
[0147] 情况1 :初始化成功：
[0148]
[0149] 情况2 :初始化失败：
[0150] 发走己端（Initiator) 响应端（Responder) 建链请求消息（发起端随机IDi+响应端随机0)>
[0151] <-拒绝消息（发起端随机IDi+响应端随机0)
[0152] 在本实施例中，若通信双方已建立通信链接或已完成初始化，则本端设备可向对 端设备发起时钟状态查询请求。本端设备生成时钟状态查询请求消息，将该时钟状态查询 请求消息发送至对端设备，对端设备对该时钟状态查询请求消息进行响应，本端设备接收 对端设备响应后发送的建链响应消息，该建链响应消息包络对端设备的时钟状态信息，根 据该建链响应消息，获取对端设备的时钟状态信息，将时钟状态查询确认消息发送至对端 设备，用以告诉对端设备，本端设备已接收到响应消息，并获取到对端设备的时钟状态信 息，即表示本次查询成功。
[0153] 在上述时钟状态查询的过程中，本端设备需要根据对端设备的响应结果，执行相 应的操作。具体地，本端设备接收到对端设备发送的时钟状态响应消息，对该时钟状态响应 消息进行验证，若验证为正确，即发送该时钟状态响应消息的对端设备为本端设备想要查 询时钟状态的对端设备，则根据该时钟状态响应消息，获取对端设备的时钟状态信息，并生 成时钟状态确认消息，将该时钟状态确认消息发送至对端设备，用于告诉对端设备，本端设 备已接收到响应消息，并获取到对端设备的时钟状态信息，即表示本次查询成功；若验证为 错误，即发送该时钟状态响应消息的对端设备不是本端设备想要查询的对端设备，将拒绝 消息发送至本端设备想要查询的对端设备，即表示本次查询失败；若本端设备接收到对端 设备发送的拒绝消息，则表示对端设备拒绝本端设备的时钟状态查询请求，即表示本次查 询失败。
[0154] 对于上述查询过程而言，发起端在发出时钟状态查询请求消息后，如果此时接收 到自己所发出的时钟状态查询请求消息的响应端的时钟状态查询请求消息，则发起端必须 采用拒绝操作，并向响应端发送拒绝消息，针对该发起端，需要至少设置一个定时器，优选 地，可以将该定期器的时长设定为10分钟，当定时器超时后，则需要响应对端的时钟状态 查询请求消息，而不应该发送拒绝消息，需要说明的是，本实施