Clock message sending method and related device

Abstract

The invention discloses a clock message sending method and a related device. The first clock node receives a first clock message from the second clock node, wherein the first clock message is used for the second clock node to request the first clock node to send a clock message; the first clock node sends a second clock message to the second clock node, the second clock message is used for responding to the first clock message, the second clock message comprises first indication information and second indication information, the first indication information is used for rejecting a request of the second clock node, and the second indication information is used for rejecting the request of the second clock node. The second indication information is used for indicating a reason for rejecting the second clock node. In the application, the first clock node notifies the second clock node of the reasons for rejecting the second clock node through the second indication information in the second clock message, so that the second clock node can execute the subsequent clock synchronization process according to the reasons for rejecting, thereby improving the success rate of clock synchronization.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method and related apparatus for transmitting clock messages. Background Technology

[0002] In modern communication networks, the normal operation of most telecommunications services requires that the frequency or time differences between all network devices be kept within a reasonable error level, i.e., clock synchronization.

[0003] During clock synchronization, the slave clock first sends a signaling message to the master clock, requesting clock messages from the master clock. After the master clock verifies the signaling message, it can then send the requested clock messages to the slave clock, such as synchronization messages, announcement messages, delay response messages, and peer-to-peer (P2P) delay response messages.

[0004] If the Signaling message sent by the slave clock to the master clock fails the master clock's verification, the master clock will send a verification failure notification to the slave clock, and the master clock will not continue to send clock messages to the slave clock, thus causing clock synchronization failure.

[0005] In view of this, a solution to improve the success rate of clock synchronization is urgently needed. Summary of the Invention

[0006] This application provides a method and related apparatus for sending clock messages to improve the success rate of clock synchronization.

[0007] Firstly, this application provides a method for sending a clock message. A second clock node sends a first clock message to a first clock node, which is used by the second clock node to request the first clock node to send a clock message. After receiving the first clock message, the first clock node sends a second clock message to the second clock node, which is used to respond to the first clock message. The second clock message includes first indication information and second indication information, wherein the first indication information is used to reject the second clock node's request, and the second indication information is used to indicate the reason for the second clock node's rejection.

[0008] In this embodiment, when the first clock node rejects the request of the second clock node, the first clock node notifies the second clock node of the reason for the rejection through the second indication information in the second clock message. Thus, the second clock node can perceive the reason for the rejection, allowing it to execute subsequent clock synchronization procedures based on this reason, thereby improving the success rate of clock synchronization.

[0009] Based on the first aspect, in one optional implementation, the first clock node is an upstream node of the second clock node, meaning the second clock node needs to obtain clock messages through the first clock node so that it can perform clock synchronization based on the clock messages from the first clock node. Therefore, the second clock node first sends a first clock message to the first clock node, which is used by the second clock node to request the first clock node to send clock messages.

[0010] After receiving the first clock message, the first clock node authenticates it to authorize or reject the second clock node's request. If the first clock message fails authentication, the first clock node rejects the second clock node's request; that is, the first clock node will not send the clock message requested by the first clock message to the second clock node. Then, the first clock node sends a second clock message to the second clock node in response to the first clock message. The second clock message includes first indication information and second indication information, where the first indication information is used to reject the second clock node's request, and the second indication information indicates the reason for the rejection.

[0011] Based on the first aspect, in one optional implementation, the location carried by the second indication information satisfies at least one of the following:

[0012] The second indication information is carried in the reserved field of the grant unicast transmission type length value (TLV) of the second clock message;

[0013] The second indication information is carried in the last byte of the authorized unicast transmission TLV of the second clock message;

[0014] The second indication information is carried in the extended field of the authorized unicast transmission TLV of the second clock message.

[0015] Based on the first aspect, in one optional implementation, the first clock node extends the second clock message to obtain an extended TLV. The first clock node carries the second indication information in the extended TLV of the second clock message.

[0016] Based on the first aspect, in one optional implementation, the first clock node can pre-arrange corresponding identifiers for each reason. If the first clock node rejects the request of the second clock node, the first clock node writes the identifier of the reason for the second clock node's rejection into the second indication information; that is, the second indication information includes the identifier of the reason for the second clock node's rejection. Then, after receiving the second clock message, the second clock node can determine the reason for its rejection based on the identifier in the second clock message. Thus, the first clock node does not need to fully describe the reason for the second clock node's rejection in the second clock message, simplifying the content of the second indication information and improving the transmission efficiency of the second clock message.

[0017] Based on the first aspect, in one optional implementation, the reason for the second clock node being rejected includes at least one of the following:

[0018] Reason A: The number of clock nodes requesting clock messages from the first clock node exceeds the threshold supported by the first clock node. This indicates that a large number of clock nodes are already requesting clock messages from the first clock node. At this point, the first clock node can no longer send clock messages to other clock nodes (including the second clock node), so the first clock message cannot pass the first clock node's authentication, and the first clock node rejects the request from the second clock node.

[0019] Reason B: The packet rate requested by the first clock message exceeds the packet rate threshold supported by the first clock node. The first clock message carries a packet rate field, which indicates the packet rate at which the first clock node sends clock messages to the second clock node. If the value of this packet rate field (i.e., the packet rate requested by the first clock message) exceeds the packet rate threshold supported by the first clock node, the first clock node cannot fulfill the request of the second clock node. Therefore, the first clock message fails authentication by the first clock node, and the first clock node rejects the request of the second clock node.

[0020] Reason C: The duration requested by the first clock message exceeds the duration threshold supported by the first clock node. The first clock message carries a duration field, which indicates the valid duration requested by the first clock message, also known as the aging period. If the value of this duration field (i.e., the duration requested by the first clock message) exceeds the duration threshold supported by the first clock node, the first clock node cannot fulfill the request of the second clock node, the first clock message fails authentication by the first clock node, and the first clock node rejects the request of the second clock node.

[0021] Reason D: The first clock node does not support the clock domain to which the second clock node belongs. The first clock message carries a clock domain field, which indicates the clock domain to which the second clock node belongs. If the value of this clock domain field (i.e., the clock domain to which the second clock node belongs) is not within the range of clock domains supported by the first clock node, the first clock node cannot fulfill the request of the second clock node, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the request of the second clock node.

[0022] Reason E: The clock identifier carried in the first clock message is the same as the clock identifier of the first clock node. The first clock message carries a clock ID field, which indicates the clock identifier of the second clock node. In practice, different clock nodes within the same clock domain should have different clock identifiers to distinguish them. If the value of this clock ID field (i.e., the clock identifier of the second clock node) is the same as the clock identifier of the first clock node, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the request from the second clock node.

[0023] Reason F: The clock ID carried in the first clock message is 0. The first clock message carries a clock ID field, which indicates the clock ID to which the second clock node belongs. The current 1588 protocol stipulates that the clock ID field cannot be 0. If the value of the clock ID field in the first clock message (i.e., the clock ID to which the second clock node belongs) is 0, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the second clock node's request.

[0024] Reason G: The first clock node does not support the Precision Time Protocol (PTP) version type carried in the first clock message. The first clock message carries a PTP version type field, which indicates the version type of the 1588 protocol enabled by the second clock node (e.g., 1588V2 or 1588V2.1). If the value of the PTP version type field (i.e., the version type of the 1588 protocol enabled by the second clock node) is not within the range supported by the first clock node, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the request from the second clock node.

[0025] Reason H: The sequence number of the clock message sent by the second clock node is not consecutive. Specifically, when the second clock node sends a clock message to the first clock node (including the first clock message), the clock message carries its sequence number. If the sequence number of the first clock message is not consecutive with the sequence numbers of clock messages previously sent by the second clock node, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the second clock node's request.

[0026] Reason I: The unicast flag field of the first clock message is not 1. The current 1588 protocol specifies that a unicast flag field value of 1 indicates that the clock message is a unicast message. In the clock message transmission method of this application embodiment, clock messages between clock nodes are transmitted in unicast form. If the unicast flag field of the first clock message is not 1, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the request from the second clock node.

[0027] Based on the first aspect, in one optional implementation, after the second clock node receives a second clock message from the first clock node, it can determine the reason for the second clock node's rejection based on the second indication information in the second clock message. The second clock node then overcomes the reasons for the rejection and executes a subsequent clock synchronization process. This subsequent clock synchronization process includes: after the first clock node receives a third clock message from the second clock node, since the third clock message overcomes the aforementioned reasons for the second clock node's rejection, the first clock node sends a fourth clock message to the second clock node. The fourth clock message indicates a request to authorize the second clock node. Then, the first clock node can send the clock message requested by the third clock message to the second clock node.

[0028] Based on the first aspect, in one optional implementation, the first clock message includes at least one of the following information:

[0029] The Announce request information, i.e., the first clock message is a Signaling message carrying Announce request information, is then used by the second clock node to request the first clock node to send a clock message (Announce message);

[0030] The notification request (Sync_request) information, that is, the first clock message is a Signaling message carrying Sync_request information. The first clock message is then used by the second clock node to request the first clock node to send a clock message (Sync message);

[0031] The delay response request (Delay_response_request) information, i.e., the first clock message is a Signaling message carrying the Delay_response_request information. It is used by the second clock node to request the first clock node to send a clock message (Delay_response message);

[0032] The P2P delay response request (Delay_response_request) information is used by the second clock node to request the first clock node to send a P2P clock message (P2P Delay_response message).

[0033] Based on the first aspect, in an optional implementation, the first clock message includes a synchronization request (Sync_request) message and a delay response request (Delay_response_request) message, which are respectively carried in different TLVs of the first clock message. The first clock message is then used by the second clock node to request the first clock node to send clock messages (Sync message and Delay_response message).

[0034] Secondly, this application provides a method for transmitting clock messages, including:

[0035] The second clock node sends a first clock message to the first clock node. The first clock message is used by the second clock node to request the first clock node to send a clock message.

[0036] The second clock node receives a second clock message from the first clock node. The second clock message is used to respond to the first clock message. The second clock message includes first indication information and second indication information. The first indication information is used to reject the request of the second clock node, and the second indication information is used to indicate the reason for the rejection of the request by the second clock node.

[0037] Based on the second aspect, in one optional implementation, the location carried by the second indication information satisfies at least one of the following:

[0038] The second indication information is carried in the reserved field of the authorized unicast transmission type length value (TLV) of the second clock message;

[0039] The second indication information is carried in the last byte of the authorized unicast transmission TLV of the second clock message;

[0040] The second indication information is carried in the extended field of the authorized unicast transmission TLV of the second clock message.

[0041] Based on the second aspect, in one alternative implementation, the second indication information includes an identifier of the cause.

[0042] Based on the second aspect, in one alternative implementation, the reasons include at least one of the following:

[0043] The number of clock nodes requesting clock messages from the first clock node exceeds the threshold supported by the first clock node;

[0044] The packet rate requested by the first clock message exceeds the packet rate threshold supported by the first clock node;

[0045] The duration requested by the first clock message exceeds the duration threshold supported by the first clock node.

[0046] The first clock node does not support the clock domain to which the second clock node belongs;

[0047] The clock identifier carried in the first clock message is the same as the clock identifier of the first clock node;

[0048] The clock flag carried in the first clock message is 0;

[0049] The first clock node does not support the PTP version type carried in the first clock message;

[0050] The sequence numbers of the clock messages sent by the second clock node are not consecutive;

[0051] The unicastFlag field of the first clock message is not 1.

[0052] Based on the second aspect, in an optional implementation, the method further includes:

[0053] The second clock node sends a third clock message to the first clock node. The third clock message is used by the second clock node to request the first clock node to send a clock message.

[0054] The second clock node receives a fourth clock message from the first clock node, which indicates a request to authorize the second clock node.

[0055] Based on the second aspect, in an optional implementation, before the second clock node sends the third clock message to the first clock node, the method further includes:

[0056] The second clock node generates a third clock message based on the second instruction information.

[0057] Based on the second aspect, in an optional implementation, the first clock message includes at least one of the following information:

[0058] Notification request information, synchronization request information, delay response request information, and P2P delay response request (Delay_response_request) information.

[0059] Based on the second aspect, in an optional implementation, the first clock message includes synchronization request information and delay response request information, which are respectively carried in different TLVs of the first clock message.

[0060] Thirdly, this application provides a first clock node, comprising:

[0061] The receiving unit is used to receive a first clock message from the second clock node, the first clock message being used by the second clock node to request the first clock node to send a clock message;

[0062] The sending unit is used to send a second clock message to the second clock node. The second clock message is used to respond to the first clock message. The second clock message includes first indication information and second indication information. The first indication information is used to reject the request of the second clock node, and the second indication information is used to indicate the reason for the rejection of the request by the second clock node.

[0063] Based on the third aspect, in an optional implementation, the location carried by the second indication information satisfies at least one of the following:

[0064] The second indication information is carried in the reserved field of the authorized unicast transmission type length value (TLV) of the second clock message;

[0065] The second indication information is carried in the last byte of the authorized unicast transmission TLV of the second clock message;

[0066] The second indication information is carried in the extended field of the authorized unicast transmission TLV of the second clock message.

[0067] Based on the third aspect, in one alternative implementation, the second indication information includes an identifier of the cause.

[0068] Based on the third aspect, in one alternative implementation, the reasons include at least one of the following:

[0069] The number of clock nodes requesting clock messages from the first clock node exceeds the threshold supported by the first clock node;

[0070] The packet rate requested by the first clock message exceeds the packet rate threshold supported by the first clock node;

[0071] The duration requested by the first clock message exceeds the duration threshold supported by the first clock node.

[0072] The first clock node does not support the clock domain to which the second clock node belongs;

[0073] The clock identifier carried in the first clock message is the same as the clock identifier of the first clock node;

[0074] The clock flag carried in the first clock message is 0;

[0075] The first clock node does not support the PTP version type carried in the first clock message;

[0076] The sequence numbers of the clock messages sent by the second clock node are not consecutive;

[0077] The unicastFlag field of the first clock message is not 1.

[0078] Based on the third aspect, in one alternative implementation,

[0079] The receiving unit is also used to receive a third clock message from the second clock node, the third clock message being used by the second clock node to request the first clock node to send a clock message;

[0080] The sending unit is also used to send a fourth clock message to the second clock node, the fourth clock message being used to indicate the request to authorize the second clock node.

[0081] Based on the third aspect, in an optional implementation, the first clock message includes at least one of the following information:

[0082] Notification request information, synchronization request information, delay response request information, and P2P delay response request (Delay_response_request) information.

[0083] Based on the third aspect, in an optional implementation, the first clock message includes synchronization request information and delay response request information, which are respectively carried in different TLVs of the first clock message.

[0084] Fourthly, this application provides a second clock node, comprising:

[0085] The transceiver unit is used to send a first clock message to the first clock node. The first clock message is used by the second clock node to request the first clock node to send a clock message.

[0086] The transceiver unit is also configured to receive a second clock message from the first clock node. The second clock message is used to respond to the first clock message. The second clock message includes first indication information and second indication information, wherein the first indication information is used to reject the request of the second clock node, and the second indication information is used to indicate the reason for the rejection of the second clock node.

[0087] Based on the fourth aspect, in an optional implementation, the location carried by the second indication information satisfies at least one of the following:

[0088] The second indication information is carried in the reserved field of the authorized unicast transmission type length value (TLV) of the second clock message;

[0089] The second indication information is carried in the last byte of the authorized unicast transmission TLV of the second clock message;

[0090] The second indication information is carried in the extended field of the authorized unicast transmission TLV of the second clock message.

[0091] Based on the fourth aspect, in one alternative implementation, the second indication information includes an identifier of the cause.

[0092] Based on the fourth aspect, in one alternative implementation, the reasons include at least one of the following:

[0093] The number of clock nodes requesting clock messages from the first clock node exceeds the threshold supported by the first clock node;

[0094] The packet rate requested by the first clock message exceeds the packet rate threshold supported by the first clock node;

[0095] The duration requested by the first clock message exceeds the duration threshold supported by the first clock node.

[0096] The first clock node does not support the clock domain to which the second clock node belongs;

[0097] The clock identifier carried in the first clock message is the same as the clock identifier of the first clock node;

[0098] The clock flag carried in the first clock message is 0;

[0099] The first clock node does not support the PTP version type carried in the first clock message;

[0100] The sequence numbers of the clock messages sent by the second clock node are not consecutive;

[0101] The unicastFlag field of the first clock message is not 1.

[0102] Based on the fourth aspect, in an optional implementation, the transceiver unit is further configured to:

[0103] Send a third clock message to the first clock node. The third clock message is used by the second clock node to request the first clock node to send a clock message.

[0104] Receive a fourth clock message from the first clock node, which indicates a request to authorize the second clock node.

[0105] Based on the fourth aspect, in an optional implementation, before the second clock node sends the third clock message to the first clock node, the method further includes:

[0106] The second clock node generates a third clock message based on the second instruction information.

[0107] Based on the fourth aspect, in an optional implementation, the first clock message includes at least one of the following information:

[0108] Notification request information, synchronization request information, delay response request information, and P2P delay response request (Delay_response_request) information.

[0109] Based on the fourth aspect, in an optional implementation, the first clock message includes synchronization request information and delay response request information, which are respectively carried in different TLVs of the first clock message.

[0110] Fifthly, embodiments of this application provide a communication device, including: a processor coupled to a memory for storing instructions, which, when executed by the processor, cause the device to implement the method described in the first aspect or any possible implementation of the first aspect.

[0111] In a sixth aspect, embodiments of this application provide a communication device, including: a processor coupled to a memory for storing instructions, which, when executed by the processor, cause the device to implement the method described in the second aspect or any possible implementation of the second aspect.

[0112] In a seventh aspect, embodiments of this application provide a computer-readable storage medium having instructions stored thereon, which, when executed, cause a computer to perform the method described in the first aspect or any possible implementation of the first aspect.

[0113] Eighthly, embodiments of this application provide a computer-readable storage medium having instructions stored thereon, which, when executed, cause a computer to perform the methods described in the second aspect or any possible implementation of the second aspect.

[0114] Ninthly, embodiments of this application provide a computer program product including computer program code, which, when run on a computer, causes the computer to perform the method described in the first aspect or any possible implementation of the first aspect.

[0115] In a tenth aspect, embodiments of this application provide a computer program product including computer program code, which, when run on a computer, causes the computer to perform the methods described in the second aspect or any possible implementation of the second aspect.

[0116] Eleventhly, embodiments of this application provide a chip, including: a processor coupled to a memory for storing instructions, wherein when the instructions are executed by the processor, the chip implements the methods described in the first aspect, the second aspect, any possible implementation of the first aspect, or any possible implementation of the second aspect.

[0117] In a twelfth aspect, embodiments of this application provide a communication system, which includes a first clock node in the first aspect or any possible implementation of the first aspect, and a second clock node in the second aspect or any possible implementation of the second aspect.

[0118] The technical effects of any of the implementation methods in aspects two through twelfth are similar to those of the implementation methods in aspect one, and will not be repeated here. Attached Figure Description

[0119] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0120] Figure 1 A schematic diagram of a possible scenario for clock synchronization;

[0121] Figure 2 This is a possible flowchart of the clock synchronization process;

[0122] Figure 3 This is a schematic diagram of a possible, non-limiting network architecture for a clock message sending method in the embodiments of this application;

[0123] Figure 4 This is a schematic diagram illustrating a scenario in which two clock nodes synchronize their clocks across a third-party network, as described in this application embodiment.

[0124] Figure 5 This is a flowchart illustrating a method for sending clock messages in an embodiment of this application.

[0125] Figure 6 This is a schematic diagram illustrating a possible method for carrying the second indication information in an embodiment of this application;

[0126] Figure 7 This is a schematic diagram illustrating another possible way of carrying the second instruction information in the embodiments of this application;

[0127] Figure 8 This is a schematic diagram illustrating another possible way of carrying the second instruction information in the embodiments of this application;

[0128] Figure 9 This is a schematic diagram illustrating another possible way of carrying the second instruction information in the embodiments of this application;

[0129] Figure 10 A schematic diagram of the structure of a first clock node provided in an embodiment of this application;

[0130] Figure 11 This is a schematic diagram of a second clock node provided in an embodiment of this application;

[0131] Figure 12 This is a schematic diagram of the logical structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0132] This application provides a method and related apparatus for sending clock messages to improve the success rate of clock synchronization.

[0133] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is only for explaining specific embodiments and is not intended to limit the embodiments of this application. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0134] In this application embodiment, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0135] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0136] The following explanations of some terms or nouns used in the embodiments of this application are also part of the invention content.

[0137] The IEEE 1588 protocol, defined by the Institute of Electrical and Electronics Engineers (IEEE), is officially called the "Precision Clock Synchronization Protocol for Networked Measurement and Control Systems," and can be abbreviated as Precision Time Protocol (PTP). Specifically, the IEEE 1588 protocol standard defines a message-based synchronization protocol that periodically sends timestamped messages to correct the time of each node in the network, thereby achieving time synchronization across the entire network.

[0138] In addition, the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) has defined a precise time synchronization protocol (e.g., G.8275.2) for some telecommunications networks based on the 1588v2 protocol, which is end-to-end 1588 time synchronization.

[0139] It should be noted that the 1588 protocol / standard involved in this application may include, but is not limited to, IEEE 1588-2008, which is the 1588v2 standard, IEEE 1588-2019, which is the 1588v2.1 standard, or other 1588 standards that will evolve in the future.

[0140] Signaling messages play a crucial role in clock synchronization. They primarily transmit Type-Length-Value (TLV) messages, and a single Signaling message can carry one or more TLV messages. These TLV messages contain critical information for clock synchronization.

[0141] Specifically, the format of a Signaling message includes multiple fields, such as a message sequence number to identify the order of messages; a control field to indicate the type of message, such as synchronization information or configuration parameters; and a message type to indicate the type of message, such as indicating that the Signaling message is of type Sync_request, synchronization request, delay response request, or P2P delay response request.

[0142] During the processing of Signaling messages, the master clock sends these messages, while the slave clock receives and parses them. Depending on the message type, the slave clock performs appropriate processing, such as time correction and configuration parameter updates. After completing these operations, the slave clock sends an acknowledgment message indicating that the message has been received. Upon receiving the acknowledgment message, the master clock terminates the communication.

[0143] The specific processing procedures, transmission protocols (such as User Datagram Protocol (UDP)), and content of Signaling messages may vary depending on different clock synchronization protocols (such as Network Time Protocol (NTP) and PTP) and specific application scenarios. Therefore, in practical applications, it is necessary to understand and process Signaling messages according to specific protocols and specifications to ensure the accuracy and stability of clock synchronization.

[0144] In summary, Signaling messages act as a bridge in the clock synchronization process, enabling communication and synchronization between master and slave clocks by transmitting key information.

[0145] Type Length Value (TLV): TLV is a widely used encoding standard in electronic communications and data storage. TLV is commonly used to transmit various types of data in computer network communications. The TLV format divides data into three parts: Type, Length, and Value, each with a fixed length.

[0146] In this context, "Type" represents the data type or identifier, used to identify the data type contained in a numeric field. Type is typically an integer value used to uniquely identify the meaning of the data. Different Types correspond to different data types or information.

[0147] Length: Indicates the length of the data contained in the numeric field, in bytes. The Length field indicates the size of the numeric field and is used to inform the receiver where the numeric field is located in the data.

[0148] Value: Contains the actual data content. The size of the Value field is specified by the Length field, and it can be any type of data, such as text, binary data, structured data, etc.

[0149] The advantages of the TLV format include flexibility and scalability. Because the Type field can be used to distinguish different data types, the TLV format can be easily extended to support new data types. Furthermore, the Length field allows the receiver to accurately parse the data without relying on specific delimiters or other separators. The TLV format is commonly found in various communication protocols and data formats, including network protocols, storage formats, and configuration files. It provides a universal data encoding method that can be used to transmit and parse various types of data, making communication between different systems more flexible and reliable.

[0150] Next, we will introduce the possible application scenarios involved in the embodiments of this application.

[0151] In modern communication networks, the normal operation of most telecommunications services requires that the frequency or time differences between all network devices be kept within a reasonable error level, i.e., clock synchronization.

[0152] 1588 Adaptive Time Recovery (ATR) further enhances 1588v2. In the standard 1588v2 clock synchronization method, all network elements (NEs) are required to support the 1588v2 protocol hop-by-hop. However, with 1588v2 ATR technology, clock nodes can synchronize across network devices that do not support the 1588v2 protocol. For an example, please refer to [link to example]. Figure 1 , Figure 1 This is a schematic diagram of a possible scenario for clock synchronization. Figure 1 In the example 1588ATR scenario, the clock node that serves as the master clock (e.g.) Figure 1 The clock message of the Master shown can cross... Figure 1 The third-party network shown (crossing network devices that do not support the 1588v2 protocol) is transparently transmitted to the clock node acting as a slave clock (e.g., Figure 1 As shown in the diagram (Slave), the Slave retrieves the timestamp from the 1588V2 message and recovers the clock, achieving clock synchronization between clock nodes. Then, it further transmits the clock message to downstream clock nodes (e.g., Figure 1 As shown in NE1, NE2, NE3, and NE4), this enables wireless access devices (e.g., Figure 1 Base stations 1, 2, 3, and 4 (among others) can receive clock messages and achieve clock synchronization based on these clock messages.

[0153] Please see Figure 2 , Figure 2 This is a possible flowchart illustrating the clock synchronization process. For example... Figure 2 As shown, in the clock synchronization process, firstly, the clock node acting as the slave clock (such as...) Figure 1 The Slave shown first sends a signal to the clock node that acts as the master clock (e.g., ...). Figure 1The master clock sends a signaling message to the slave clock, which requests clock messages from the master clock. After the master clock verifies the signaling message, it can send the requested clock messages, such as synchronization messages, announcement messages, delay response messages, and peer-to-peer (P2P) delay response messages, to the slave clock.

[0154] by Figure 2Taking an example where the Signaling message includes an Announce_request message, the Slave sends a Signaling message carrying the Announce_request information to the Master, requesting the Master to send an Announce message to the Slave. Specifically, this Announce_request information carries the content of the request via the TLV, such as the requested message type, packet rate, and duration. The Duration indicates how long a request is valid; the Master only sends the requested message (such as an Announce) to the Slave within the validity period. After the validity period expires, the Master will stop sending the requested message to the Slave unless the Slave re-initiates the request. Upon receiving the Signaling message (carrying the Announce_request information), the Master authenticates it and then sends a Signaling message carrying the Announce_grant information to the Slave. The Announce_grant message is used to inform the Slave whether the aforementioned Announce_request message has been agreed to or rejected. If the aforementioned Signaling message (carrying the Announce_request message) has been agreed to by the Master, then the Duration field in the Signaling message (carrying the Announce_grant message) sent by the Master to the Slave will have a value greater than 0, indicating that the aforementioned Signaling message (carrying the Announce_request message) has been agreed to, and the Master will send the Announce message requested by the Announce_request message to the Slave. If the aforementioned Signaling message (carrying the Announce_request message) has been rejected by the Master, then the Duration field in the Signaling message (carrying the Announce_grant message) sent by the Master to the Slave will have a value equal to 0, indicating that the aforementioned Signaling message (carrying the Announce_request message) has been rejected, and then the Master will not send the Announce message requested by the Announce_request message to the Slave.

[0155] If the Signaling message sent by the slave clock to the master clock fails the master clock's verification, the master clock will send a verification failure notification to the slave clock, and the master clock will not continue to send clock messages to the slave clock, thus causing clock synchronization failure.

[0156] In view of this, embodiments of this application provide a method and related apparatus for sending clock messages to improve the success rate of clock synchronization. For ease of understanding, firstly, a possible, non-limiting network architecture for the clock message sending method in this application embodiment is described. Please refer to... Figure 3 , Figure 3 This is a schematic diagram of a possible, non-limiting network architecture for a clock message transmission method in an embodiment of this application. Figure 3 In the example scenario, the network architecture includes at least one 1588 server (such as...). Figure 3 The 1588 server 1 and 1588 server 2 shown), and at least one network device (such as Figure 3 NE1, NE2, NE3, NE4, NE5 and NE6 shown) and at least one wireless access device (such as Figure 3 (Base stations 1, 2, 3, and 4 are shown). During clock synchronization, the clock message sent by the 1588 server can reach the wireless access device through transmission via at least one network device. This enables the high-precision clock of the 1588 server to be transmitted to the terminal wireless access device, meeting the high-precision time service requirements of the wireless access device. In this embodiment, the clock node can be the aforementioned 1588 server, network device, and / or wireless access device.

[0157] Optionally, in practical applications, Figure 3 The network devices in the network architecture shown may include network devices in the core layer network, network devices in the aggregation layer network, and / or network devices in the access layer network.

[0158] The clock message sending method provided in this application is applicable to clock synchronization processes between any two clock nodes. For example... Figure 4 As shown, in practical applications, if two clock nodes (e.g.) Figure 4If there is a third-party network (i.e., a network device that does not support the 1588 protocol or does not support clock synchronization) between the first clock node and the second clock node shown, then the two clock nodes can use adaptive clock recovery (ACR) or adaptive time recovery (ATR) to transmit the clock messages in this application embodiment (such as the first clock message, second clock message, third clock message and fourth clock message in this application embodiment) through the third-party network to the other clock node.

[0159] It should be understood that the 1588 protocol / standard involved in the embodiments of this application may include, but is not limited to, the 1588v1 standard, the 1588v2 standard, the 1588v2.1 standard, or other 1588 standards that will evolve in the future. Therefore, the clock message transmission method provided in the embodiments of this application can be applied to... Figure 1 The network architecture shown includes third-party networks (i.e., network devices that do not support the 1588 protocol or clock synchronization), or it can also be applied to networks such as... Figure 3 The network architecture shown does not include third-party networks; specific details are not specified here.

[0160] Next, the method for sending clock messages provided in the embodiments of this application will be described.

[0161] Please see Figure 5 , Figure 5 This is a flowchart illustrating a method for sending clock messages in an embodiment of this application. The method for sending clock messages in this embodiment uses a clock node as the executing entity to illustrate the method, but this application does not limit the executing entity in this interactive illustration, nor does it limit the specific hardware or software form of the clock node. For example, Figure 5 The clock node can be a chip, chip system, or processor used to support the implementation of the method; alternatively, the clock node can also be a logic node, logic module, or software used to implement all or part of the clock node's functions. Optionally, the first clock node is... Figure 3 The example network architecture includes a 1588 server (e.g.) Figure 3 The second clock node is shown as either 1588 service 1 or 1588 server 2, or a functional module within the 1588 server. Figure 3 The network devices in the example network architecture (e.g.) Figure 3 The N1 or NE2 shown, or a functional module in the network device; optionally, the first clock node is... Figure 3 Network devices in the network architecture shown (e.g.) Figure 3The second clock node is either NE1 or NE2 as shown, or a functional module in the network device, while the second clock node is a downstream network device of the first clock node (e.g., a NE1 or NE2). Figure 3 The NE3 or NE4 shown, or a functional module in the downstream network device; optionally, the first clock node is... Figure 3 Network devices in the network architecture shown (e.g.) Figure 3 The second clock node is the wireless access device of the first clock node (e.g., NE5 or NE6 shown) or a functional module in the network device. Figure 3 The base station 1, base station 2, base station 3, or base station 4 shown, or a functional module in the wireless access device. Figure 5 As shown, the clock message sending method in the embodiments of this application includes, but is not limited to, steps 101 to 102.

[0162] 101. The second clock node sends the first clock message to the first clock node.

[0163] In the clock message transmission method illustrated in the embodiments of this application, the first clock node is an upstream node of the second clock node, meaning the second clock node needs to obtain clock messages through the first clock node so that it can perform clock synchronization based on the clock messages from the first clock node. Therefore, the second clock node first sends a first clock message to the first clock node, which is used by the second clock node to request the first clock node to send clock messages.

[0164] The clock message sending method provided in this application is applicable to the clock message sending process between a master clock and a slave clock. In practical applications, clock nodes within the same clock domain synchronize their clocks according to a certain master-slave relationship. It should be understood that the master-slave relationship between clock nodes is relative. The clock node that needs to synchronize its clock is called the slave clock, while the clock node that publishes its clock is called the master clock. In practical applications, a clock node may simultaneously synchronize its clock from an upstream clock node (in which case this clock node is the slave clock) and then publish its clock to a downstream clock node (in which case this clock node is the master clock).

[0165] In practical applications, a clock node is a communication entity that performs specific clock synchronization functions for sending and receiving signals. Optionally, this communication entity can be a Building Integrated Timing Supply (BITS) system, a router, a switch, or a base station, etc., without specific limitations here. It should be understood that "clock node" is only a general term for devices performing clock synchronization functions, and does not specifically refer to any one or more devices. In practical applications, devices performing clock synchronization functions may not be called "clock nodes," but may be referred to by other names (e.g., "clock device" or "network device"), without specific limitations here. This application embodiment only uses "clock node" as an example for illustration.

[0166] Optionally, in practical applications, the first clock message is a signaling message. Signaling messages are used to transmit control information, status information, or other management information between clock nodes to facilitate the establishment, maintenance, and termination of communication between them. For example, the first clock message (signaling message) sent by the second clock node to the first clock node carries key information needed to request a clock message from the second clock node, such as: Sequence ID field, Message Type field, Duration Field, Clock Domain field, Clock Identifier field, Unicast Flag field, Packet Rate field, and PTP Version Type field. In summary, clock synchronization is a crucial means of ensuring time consistency between clock nodes, and the signaling message is the specific carrier for initiating a clock synchronization request from the clock to the master clock during the clock synchronization process. It should be understood that the fields carried in the first clock message described above are merely illustrative; in practical applications, the first clock message may also carry other fields, which are not limited here.

[0167] In one possible implementation, the first clock message includes at least one of the following information:

[0168] Notification request information, such as Figure 2 The example Announce_request message, i.e., the first clock message, is a Signaling message carrying Announce_request information. Therefore, the first clock message is used by the second clock node to request the first clock node to send a clock message (Announce message).

[0169] Synchronize request information, such as Figure 2The example notification request (Sync_request) information, i.e., the first clock message is a Signaling message carrying Sync_request information, is then used by the second clock node to request the first clock node to send a clock message (Sync message).

[0170] The delay response request (Delay_response_request) information, that is, the first clock message is a Signaling message carrying the Delay_response_request information. Then, the first clock message is used by the second clock node to request the first clock node to send a clock message (Delay_response message);

[0171] The P2P delay response request (Delay_response_request) information, i.e., the first clock message is a Signaling message carrying P2PDelay_response_request information, is then used by the second clock node to request the first clock node to send a P2P clock message (P2P Delay_response message).

[0172] In one possible implementation, the first clock message includes a synchronization request (Sync_request) and a delay response request (Delay_response_request) message, which are respectively carried in different TLVs of the first clock message. The first clock message is then used by the second clock node to request the first clock node to send clock messages (Sync message and Delay_response message).

[0173] In one possible implementation, the first clock message includes one of the following: a notification request (Sync_request) message, a synchronization request (Sync_request) message, a delay response request (Delay_response_request) message, or a P2P delay response request (Delay_response_request) message.

[0174] 102. The first clock node sends a second clock message to the second clock node.

[0175] After receiving the first clock message, the first clock node authenticates it to authorize or reject the second clock node's request. If the first clock message fails authentication, the first clock node rejects the second clock node's request; that is, the first clock node will not send the clock message requested by the first clock message to the second clock node. Then, the first clock node sends a second clock message to the second clock node in response to the first clock message. The second clock message includes first indication information and second indication information, where the first indication information is used to reject the second clock node's request, and the second indication information indicates the reason for the rejection.

[0176] In this embodiment, when the first clock node rejects the request of the second clock node, the first clock node notifies the second clock node of the reason for the rejection through the second indication information in the second clock message. Thus, the second clock node can perceive the reason for the rejection, allowing it to execute subsequent clock synchronization procedures based on this reason, thereby improving the success rate of clock synchronization.

[0177] In practical applications, the first clock node can choose to authorize or reject the second clock node's request based on information carried in the first clock message (such as the aforementioned message sequence number field, message type field, duration field, clock domain field, clock identifier field, unicast flag field, packet rate field, or 1588 protocol version type field). In one possible implementation, the reason for the second clock node to be rejected includes at least one of the following:

[0178] Reason A: The number of clock nodes requesting clock messages from the first clock node exceeds the threshold supported by the first clock node. This indicates that a large number of clock nodes are already requesting clock messages from the first clock node. At this point, the first clock node can no longer send clock messages to other clock nodes (including the second clock node), so the first clock message cannot pass the first clock node's authentication, and the first clock node rejects the request from the second clock node.

[0179] Reason B: The packet rate requested by the first clock message exceeds the packet rate threshold supported by the first clock node. The first clock message carries a packet rate field, which indicates the packet rate at which the first clock node sends clock messages to the second clock node. If the value of this packet rate field (i.e., the packet rate requested by the first clock message) exceeds the packet rate threshold supported by the first clock node, the first clock node cannot fulfill the request of the second clock node. Therefore, the first clock message fails authentication by the first clock node, and the first clock node rejects the request of the second clock node.

[0180] Reason C: The duration requested by the first clock message exceeds the duration threshold supported by the first clock node. The first clock message carries a duration field, which indicates the valid duration requested by the first clock message, also known as the aging period. If the value of this duration field (i.e., the duration requested by the first clock message) exceeds the duration threshold supported by the first clock node, the first clock node cannot fulfill the request of the second clock node, the first clock message fails authentication by the first clock node, and the first clock node rejects the request of the second clock node.

[0181] Reason D: The first clock node does not support the clock domain to which the second clock node belongs. The first clock message carries a clock domain field, which indicates the clock domain to which the second clock node belongs. If the value of this clock domain field (i.e., the clock domain to which the second clock node belongs) is not within the range of clock domains supported by the first clock node, the first clock node cannot fulfill the request of the second clock node, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the request of the second clock node.

[0182] Reason E: The clock identifier carried in the first clock message is the same as the clock identifier of the first clock node. The first clock message carries a clock ID field, which indicates the clock identifier of the second clock node. In practice, different clock nodes within the same clock domain should have different clock identifiers to distinguish them. If the value of this clock ID field (i.e., the clock identifier of the second clock node) is the same as the clock identifier of the first clock node, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the request from the second clock node.

[0183] Reason F: The clock ID carried in the first clock message is 0. The first clock message carries a clock ID field, which indicates the clock ID to which the second clock node belongs. The current 1588 protocol stipulates that the clock ID field cannot be 0. If the value of the clock ID field in the first clock message (i.e., the clock ID to which the second clock node belongs) is 0, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the second clock node's request.

[0184] Reason G: The first clock node does not support the PTP version type carried in the first clock message. The first clock message carries a PTP version type field, which indicates the version type of the 1588 protocol enabled by the second clock node (e.g., 1588V2 or 1588V2.1). If the value of the PTP version type field (i.e., the version type of the 1588 protocol enabled by the second clock node) is not within the range supported by the first clock node, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the request from the second clock node.

[0185] Reason H: The sequence number of the clock message sent by the second clock node is not consecutive. Specifically, when the second clock node sends a clock message to the first clock node (including the first clock message), the clock message carries its sequence number. If the sequence number of the first clock message is not consecutive with the sequence numbers of clock messages previously sent by the second clock node, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the second clock node's request.

[0186] Reason I: The unicast flag field of the first clock message is not 1. The current 1588 protocol specifies that a unicast flag field value of 1 indicates that the clock message is a unicast message. In the clock message transmission method of this application embodiment, clock messages between clock nodes are transmitted in unicast form. If the unicast flag field of the first clock message is not 1, the first clock message cannot be authenticated by the first clock node, and the first clock node rejects the request from the second clock node.

[0187] It should be understood that the reasons for the second clock node being rejected described above are merely illustrative. In actual applications, the first clock node may also reject the second clock node's request for other reasons, which are not limited here.

[0188] In one possible implementation, the second clock message is a Signaling message that carries a grant unicast transmission (grant_unicast_transmission) type length value (TLV), which includes a duration field. The first clock message can indicate that the first clock node has rejected the second clock node's request by setting the duration field in the second clock message's grant_unicast_transmission TLV to 0.

[0189] In one possible implementation, the location carried by the second indication information satisfies at least one of the following:

[0190] The second indication information is carried in a reserved field of the grant_unicast_transmission TLV of the second clock message. See also Figure 6 , Figure 6 This is a schematic diagram illustrating one possible method for carrying the second indication information in an embodiment of this application. For example... Figure 6 As shown, the second instruction information can be carried in Figure 6 At least one of the two reserved fields shown;

[0191] The second indication information is carried in the last byte of the grant unicast transmission TLV of the second clock message. See also... Figure 7 , Figure 7 This is a schematic diagram illustrating another possible method for carrying the second indication information in an embodiment of this application. For example... Figure 7 As shown, the second instruction information can be carried in Figure 7 The last byte in the grant_unicast_transmission TLV shown;

[0192] The second indication information is carried in the extended field of the grant_unicast_transmission TLV of the second clock message. See also... Figure 8 , Figure 8 This is a schematic diagram illustrating another possible method for carrying the second indication information in an embodiment of this application. For example... Figure 8 As shown, the first clock node extends the grant_unicast_transmission TLV, and the second indication information can be carried in... Figure 8 The extended fields shown.

[0193] In one possible implementation, the first clock node extends the second clock message to obtain an extended TLV, such as an Operation, Administration, and Maintenance (OAM) TLV. See also... Figure 9 , Figure 9 This is a schematic diagram illustrating another possible method for carrying the second indication information in an embodiment of this application. For example... Figure 9As shown, this extended TLV is the next TLV after the grant_unicast_transmission TLV in the second clock message. Then, the first clock node carries the second indication information in the extended TLV of the second clock message.

[0194] In practical applications, there may be multiple reasons why the second clock node is rejected. In this case, the first clock node may carry the reason for the rejection in the reserved field of the `grant_unicast_transmission TLV` of the second clock message; alternatively, the first clock node may carry the reason in the last byte of the `grant_unicast_transmission TLV` of the second clock message; alternatively, the first clock node may carry the reason in the extended field of the `grant_unicast_transmission TLV` of the second clock message; alternatively, the first clock node may carry the reason in the extended TLV of the second clock message; or alternatively, the extended TLV, the reserved field, the last byte, and / or the extended field in the `grant_unicast_transmission TLV` may each be used to carry some of the reasons for the rejection. In other words, multiple reasons for the rejection of the second clock node may be carried in one or more of the extended TLV, the reserved field, the last byte, and the extended field in the `grant_unicast_transmission TLV`, and the specific reasons are not limited here.

[0195] In one possible implementation, the first clock node can pre-assign corresponding identifiers for each reason (e.g., reasons A to I mentioned above). If the first clock node rejects the request of the second clock node, it writes the identifier of the reason for the rejection into the second indication information; that is, the second indication information includes the identifier of the reason for the rejection. Upon receiving the second clock message, the second clock node can determine the reason for the rejection corresponding to the identifier in the second clock message. Therefore, the first clock node does not need to fully describe the reason for the rejection in the second clock message, simplifying the content of the second indication information and improving the transmission efficiency of the second clock message.

[0196] For example, in practical applications, each bit in the field carrying the second indication information can be designated as an indication bit (marker bit) for a reason. When the value of the bit is 1, it indicates that the reason corresponding to the bit has been triggered, and the reason corresponding to the bit is one of the reasons that caused the second clock node to be rejected; when the value of the bit is 0, it indicates that the reason corresponding to the bit has not been triggered, and the reason that caused the second clock node to be rejected does not include the reason corresponding to the bit. Taking the above reasons A to I as an example, each corresponds to 9 bits, and the field carrying the second indication information can include these 9 bits. Assuming that after the first clock node receives the first clock message, it rejects the request of the second clock message based on reasons A, B, C, and F, then the values ​​of the above 9 bits are 111001000 respectively.

[0197] Optional, in Figure 5 Based on steps 101 and 102 described in the embodiments, the clock message sending method provided in this application embodiment may further include steps 103 and 104.

[0198] 103. The second clock node sends a third clock message to the first clock node.

[0199] After receiving the second clock message from the first clock node, the second clock node can determine the reason for the rejection based on the second indication information in the second clock message. Optionally, the user can take corresponding measures to address different reasons based on the indication information in the second clock message. Then, the second clock node sends a third clock message, which is used by the second clock node to request the first clock node to send a clock message. This third clock message overcomes the reasons that caused the second clock node to be rejected, allowing the subsequent clock synchronization process to continue, thereby improving the success rate of clock synchronization.

[0200] In one possible implementation, the second clock node automatically determines a solution to the reason for the rejection, as indicated by the second indication information in the second clock message, and then generates a third clock message that overcomes the reason. The second clock node then sends this third clock message to the first clock node, which is used by the second clock node to request the first clock node to send a clock message.

[0201] For example, based on the above reasons A to I, the embodiments of this application provide corresponding solutions A to I:

[0202] Solution A: Replace the master clock of the second clock node, and renegotiate with the new master clock. Alternatively, temporarily suspend negotiation for the second clock node.

[0203] Solution B: Modify the packet transmission rate requirement of the second clock node, and then renegotiate;

[0204] Solution C: Modify the duration requirement of the second clock node and then renegotiate;

[0205] Solution D: Modify the clock domain (domain value) of the second clock node, and then renegotiate;

[0206] Solution E: Modify the clock identifiers of the first clock node and the second clock node to be inconsistent, and then renegotiate;

[0207] Solution F: Modify the clock identifier of the second clock node and then renegotiate;

[0208] Solution G: Modify the PTP version type enabled by the second clock node, and then renegotiate;

[0209] Solution H: Renegotiate;

[0210] Solution I: Modify the value of the unicast flag field in the clock message of the second clock node to 1, and then renegotiate.

[0211] 104. The first clock node sends a fourth clock message to the second clock node.

[0212] After receiving the third clock message from the second clock node, the first clock node, having overcome the reasons that led to the second clock node's rejection, sends a fourth clock message to the second clock node. This fourth clock message indicates the authorization request for the second clock node. The first clock node can then send the clock message requested by the third clock message to the second clock node.

[0213] Accordingly, embodiments of this application also provide related apparatus for implementing the above-described solutions. For details, please refer to... Figure 10 , Figure 10 This is a schematic diagram of a first clock node provided in an embodiment of this application. Figure 10 The first clock node can be a chip, chip system, or processor used to support the implementation of the method by the first clock node; alternatively, the first clock node can also be a logic node, logic module, or software used to implement all or part of the functions of the first clock node. For example... Figure 10 As shown, the first clock node includes:

[0214] The receiving unit 201 is used to receive a first clock message from the second clock node, wherein the first clock message is used by the second clock node to request the first clock node to send a clock message;

[0215] The sending unit 202 is used to send a second clock message to the second clock node. The second clock message is used to respond to the first clock message. The second clock message includes first indication information and second indication information. The first indication information is used to reject the request of the second clock node, and the second indication information is used to indicate the reason for the rejection of the request by the second clock node.

[0216] In one possible design, the location carrying the second indication information satisfies at least one of the following:

[0217] The second indication information is carried in the reserved field of the authorized unicast transmission type length value (TLV) of the second clock message;

[0218] The second indication information is carried in the last byte of the authorized unicast transmission TLV of the second clock message;

[0219] The second indication information is carried in the extended field of the authorized unicast transmission TLV of the second clock message.

[0220] In one possible design, the second instruction information includes an identifier of the reason.

[0221] In one possible design, the reasons include at least one of the following:

[0222] The number of clock nodes requesting clock messages from the first clock node exceeds the threshold supported by the first clock node;

[0223] The packet rate requested by the first clock message exceeds the packet rate threshold supported by the first clock node;

[0224] The duration requested by the first clock message exceeds the duration threshold supported by the first clock node.

[0225] The first clock node does not support the clock domain to which the second clock node belongs;

[0226] The clock identifier carried in the first clock message is the same as the clock identifier of the first clock node;

[0227] The clock flag carried in the first clock message is 0;

[0228] The first clock node does not support the PTP version type carried in the first clock message;

[0229] The sequence numbers of the clock messages sent by the first clock node are not consecutive;

[0230] The unicastFlag field of the first clock message is not 1.

[0231] In one possible design, the receiving unit 201 is also used to receive a third clock message from the second clock node, the third clock message being used by the second clock node to request the first clock node to send a clock message.

[0232] The sending unit 202 is also configured to send a fourth clock message to the second clock node, the fourth clock message being used to indicate a request to authorize the second clock node.

[0233] In one possible design, the first clock message includes at least one of the following information:

[0234] Notification request information, synchronization request information, delay response request information, and point-to-point delay response request information.

[0235] In one possible design, the first clock message includes synchronization request information and delay response request information, which are respectively carried in different TLVs of the first clock message.

[0236] It should be noted that the information interaction and execution process between the modules / units in the first clock node are different from those in this application. Figure 5 The corresponding method embodiments are based on the same concept, and the details can be found in the descriptions of the method embodiments shown above in this application, which will not be repeated here.

[0237] Please see Figure 11 , Figure 11 This is a schematic diagram of a second clock node provided in an embodiment of this application. Figure 11 The second clock node can be a chip, chip system, or processor used to support the implementation of the method by the second clock node; alternatively, the second clock node can also be a logic node, logic module, or software used to implement all or part of the functions of the second clock node. For example... Figure 11 As shown, the second clock node includes:

[0238] The transceiver unit 301 is used to send a first clock message to the first clock node. The first clock message is used by the second clock node to request the first clock node to send a clock message.

[0239] The transceiver unit 301 is also configured to receive a second clock message from the first clock node. The second clock message is used to respond to the first clock message. The second clock message includes first indication information and second indication information, wherein the first indication information is used to reject the request of the second clock node, and the second indication information is used to indicate the reason for the second clock node being rejected.

[0240] In one possible design, the location carrying the second indication information satisfies at least one of the following:

[0241] The second indication information is carried in the reserved field of the authorized unicast transmission type length value (TLV) of the second clock message;

[0242] The second indication information is carried in the last byte of the authorized unicast transmission TLV of the second clock message;

[0243] The second indication information is carried in the extended field of the authorized unicast transmission TLV of the second clock message.

[0244] In one possible design, the second instruction information includes an identifier of the reason.

[0245] In one possible design, the reasons include at least one of the following:

[0246] The number of clock nodes requesting clock messages from the first clock node exceeds the threshold supported by the first clock node;

[0247] The packet rate requested by the first clock message exceeds the packet rate threshold supported by the first clock node;

[0248] The duration requested by the first clock message exceeds the duration threshold supported by the first clock node.

[0249] The first clock node does not support the clock domain to which the second clock node belongs;

[0250] The clock identifier carried in the first clock message is the same as the clock identifier of the first clock node;

[0251] The clock flag carried in the first clock message is 0;

[0252] The first clock node does not support the version type carried in the first clock message;

[0253] The sequence numbers of the first clock message are not consecutive;

[0254] The unicastFlag field of the first clock message is not 1.

[0255] In one possible design, the transceiver unit is also used for:

[0256] Send a third clock message to the first clock node. The third clock message is used by the second clock node to request the first clock node to send a clock message.

[0257] Receive a fourth clock message from the first clock node, which indicates a request to authorize the second clock node.

[0258] In one possible design, the second clock node also includes:

[0259] The processing unit 302 is used to generate a third clock message based on the second instruction information.

[0260] In one possible design, the first clock message includes at least one of the following information:

[0261] Notification request information, synchronization request information, and delay response request information.

[0262] In one possible design, the first clock message includes synchronization request information and delay response request information, which are respectively carried in different TLVs of the first clock message.

[0263] It should be noted that the information interaction and execution process between the modules / units in the second clock node are different from those in this application. Figure 5 The corresponding method embodiments are based on the same concept, and the details can be found in the descriptions of the method embodiments shown above in this application, which will not be repeated here.

[0264] Please see Figure 12 , Figure 12 This is a schematic diagram of the logical structure of a communication device 40 provided in an embodiment of this application. Figure 12 The communication equipment 40 in the middle can be deployed Figure 10 The first clock node described in the corresponding embodiment is used to implement Figure 5 The function implemented by the first clock node in the corresponding embodiment, or the communication device 40 may be deployed with Figure 11 The second clock node described in the corresponding embodiment is used to implement Figure 5 The second clock node in the corresponding embodiment performs the function. The communication device 40 includes: a memory 401, a processor 402, a communication interface 403, and a bus 404. The memory 401, processor 402, and communication interface 403 are interconnected via the bus 404.

[0265] The memory 401 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 401 may store a program. When the program stored in the memory 401 is executed by the processor 402, the processor 402 and the communication interface 403 are used to execute steps 101-104 of the above-described clock message sending method embodiment.

[0266] Processor 402 may be a central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), graphics processing unit (GPU), digital signal processing (DSP), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, or any combination thereof, used to execute related programs to implement one or more steps in steps 101-104 of the clock message transmission method embodiment in this application. The steps of the data processing method disclosed in conjunction with the embodiments of this application can be executed by a compiler and an executor, wherein the compiler and executor can be executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 401. Processor 402 reads the information in memory 401 and, in conjunction with its hardware, executes one or more steps in steps 101-104 of the clock message sending method embodiment in this application.

[0267] The communication interface 403 uses transceiver devices, such as, but not limited to, transceivers, to enable communication between the communication device 40 and other devices or communication networks.

[0268] Bus 404 enables the transmission of information between various components of computer device 40 (e.g., memory 401, processor 402, and communication interface 403). Bus 404 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0269] It should be noted that the information interaction and execution process between the modules / units in the communication device are different from those in this application. Figure 5 The corresponding method embodiments are based on the same concept, and the details can be found in the descriptions of the method embodiments shown above in this application, which will not be repeated here.

[0270] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computer device, it causes the at least one computer device to perform the aforementioned actions. Figure 5 The method described in the illustrated embodiment.

[0271] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform the aforementioned operations. Figure 5 The method described in the illustrated embodiment.

[0272] The communication device provided in this application embodiment can specifically be a chip, which includes a processing unit and a communication unit. The processing unit can be, for example, a processor, and the communication unit can be, for example, an input / output interface, pins, or circuits. The processing unit can execute computer execution instructions stored in the storage unit to cause the chip to perform the aforementioned operations. Figure 5 The method described in the illustrated embodiment. Optionally, the storage unit is a storage unit within the chip, such as a register, cache, etc. The storage unit can also be a storage unit located outside the chip within the wireless access device, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, random access memory (RAM), etc.

[0273] This application also provides a communication system, which includes the features described above. Figure 5 The first clock node described in the illustrated embodiment, and as described above Figure 5 The second clock node described in the illustrated embodiment.

[0274] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0275] Through the above description of the embodiments, those skilled in the art can clearly understand that the embodiments of this application can be implemented by means of software plus necessary general-purpose hardware, or by special-purpose hardware including dedicated integrated circuits, dedicated CPUs, dedicated memory, dedicated components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can be diverse, such as analog circuits, digital circuits, or dedicated circuits. However, for the embodiments of this application, software program implementation is more often a better implementation method. Based on this understanding, the technical solution of the embodiments of this application, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0276] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0277] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0278] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between different embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

Claims

1. A method for sending a clock message, characterized in that, include: The first clock node receives a first clock message from the second clock node, the first clock message being used by the second clock node to request the first clock node to send a clock message; The first clock node sends a second clock message to the second clock node. The second clock message is used to respond to the first clock message. The second clock message includes first indication information and second indication information. The first indication information is used to reject the request of the second clock node, and the second indication information is used to indicate the reason for the rejection of the request by the second clock node.

2. The method according to claim 1, characterized in that, The location carried by the second indication information satisfies at least one of the following: The second indication information is carried in the reserved field of the authorized unicast transmission type length value (TLV) of the second clock message; The second indication information is carried in the last byte of the authorized unicast transmission TLV of the second clock message; The second indication information is carried in the extended field of the authorized unicast transmission TLV of the second clock message.

3. The method according to claim 1 or 2, characterized in that, The second indication information includes an identifier of the cause.

4. The method according to any one of claims 1 to 3, characterized in that, The reasons include at least one of the following: The number of clock nodes requesting clock messages from the first clock node exceeds the threshold supported by the first clock node. The packet rate requested by the first clock message exceeds the packet rate threshold supported by the first clock node; The duration requested by the first clock message exceeds the duration threshold supported by the first clock node; The first clock node does not support the clock domain to which the second clock node belongs; The clock identifier carried in the first clock message is the same as the clock identifier of the first clock node; The clock flag carried in the first clock message is 0; The first clock node does not support the Precision Time Protocol (PTP) version type carried in the first clock message; The sequence numbers of the clock messages sent by the second clock node are not consecutive; The unicast flag field of the first clock message has a value that is not 1.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The first clock node receives a third clock message from the second clock node, the third clock message being used by the second clock node to request the first clock node to send a clock message; The first clock node sends a fourth clock message to the second clock node, the fourth clock message being used to indicate a request to authorize the second clock node.

6. The method according to any one of claims 1 to 5, characterized in that, The first clock message includes at least one of the following information: Notification request information, synchronization request information, delay response request information, and point-to-point delay response request information.

7. The method according to claim 6, characterized in that, The first clock message includes the synchronization request information and the delay response request information, which are respectively carried in different TLVs of the first clock message.

8. A method for sending a clock message, characterized in that, include: The second clock node sends a first clock message to the first clock node. The first clock message is used by the second clock node to request the first clock node to send a clock message. The second clock node receives a second clock message from the first clock node. The second clock message is used to respond to the first clock message. The second clock message includes first indication information and second indication information, wherein the first indication information is used to reject the request of the second clock node, and the second indication information is used to indicate the reason for the rejection of the request by the second clock node.

9. The method according to claim 8, characterized in that, The location carried by the second indication information satisfies at least one of the following: The second indication information is carried in the reserved field of the authorized unicast transmission type length value (TLV) of the second clock message; The second indication information is carried in the last byte of the authorized unicast transmission TLV of the second clock message; The second indication information is carried in the extended field of the authorized unicast transmission TLV of the second clock message.

10. The method according to claim 8 or 9, characterized in that, The second indication information includes an identifier of the cause.

11. The method according to any one of claims 8 to 10, characterized in that, The reasons include at least one of the following: The number of clock nodes requesting clock messages from the first clock node exceeds the threshold supported by the first clock node. The packet rate requested by the first clock message exceeds the packet rate threshold supported by the first clock node; The duration requested by the first clock message exceeds the duration threshold supported by the first clock node; The first clock node does not support the clock domain to which the second clock node belongs; The clock identifier carried in the first clock message is the same as the clock identifier of the first clock node; The clock flag carried in the first clock message is 0; The first clock node does not support the Precision Time Protocol (PTP) version type carried in the first clock message; The sequence numbers of the clock messages sent by the second clock node are not consecutive; The unicast flag field of the first clock message has a value that is not 1.

12. The method according to any one of claims 8 to 11, characterized in that, The method further includes: The second clock node sends a third clock message to the first clock node, the third clock message being used by the second clock node to request the first clock node to send a clock message; The second clock node receives a fourth clock message from the first clock node, the fourth clock message being used to indicate a request to authorize the second clock node.

13. The method according to claim 12, characterized in that, Before the second clock node sends the third clock message to the first clock node, the method further includes: The second clock node generates a third clock message based on the second indication information.

14. The method according to any one of claims 8 to 13, characterized in that, The first clock message includes at least one of the following information: Notification request information, synchronization request information, delay response request information, and point-to-point delay response request information.

15. The method according to claim 14, characterized in that, The first clock message includes the synchronization request information and the delay response request information, which are respectively carried in different TLVs of the first clock message.

16. A first clock node, characterized in that, The first clock node includes: The receiving unit is configured to perform the sending step in the method according to any one of claims 1 to 7; A transmitting unit is used to perform the receiving step in the method according to any one of claims 1 to 7.

17. A second clock node, characterized in that, The second clock node includes: A transceiver unit is used to perform the sending step or the receiving step in the method of any one of claims 8 to 15; A processing unit is configured to perform steps other than the sending and receiving steps in the method according to any one of claims 8 to 15.

18. A communication device, characterized in that, Includes a processor, which is coupled to memory. The memory is used to store instructions; The processor is configured to execute instructions in the memory, causing the communication device to perform the method as described in any one of claims 1 to 7, or to cause the communication device to perform the method as described in any one of claims 8 to 15.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7, or implements the method as described in any one of claims 8 to 15.

20. A computer program product, characterized in that, The computer program product stores computer-readable instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 7, or implement the method as described in any one of claims 8 to 15.

21. A chip, characterized in that, The chip includes a processor coupled to a memory. The memory is used to store instructions; The processor is configured to execute instructions in the memory such that the chip performs the method as described in any one of claims 1 to 7, or such that the chip performs the method as described in any one of claims 8 to 15.

22. A communication system, characterized in that, The communication system includes the first clock node as described in claim 16 and the second clock node as described in claim 17.

Images