A clock synchronization method and apparatus

Abstract

The application provides a clock synchronization method and device. The method is applied to a clock node and comprises the following steps: receiving a first Sync message sent by an upstream clock node; if the first Sync message carries a first timestamp, sending a first Delay_Req message to the upstream clock node; after receiving a first Delay_Resp message carrying a second timestamp sent by the upstream clock node, obtaining first timestamp information and performing a clock synchronization operation according to the first timestamp information; after the clock synchronization operation is completed, judging whether there is a downstream clock node locally; if not, ending the process; if yes, sending a second Sync message carrying a third timestamp to the downstream clock node; and if a second Delay_Req message is received within a set time length, sending a second Delay_Resp message carrying a fourth timestamp to the downstream clock node. The application can shorten the clock synchronization time.

Description

Technical Field

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

[0002] Currently, in 5G networks with architectures such as single or multiple remote radio unit hubs (rHUBs), the base band unit (BBU) and rHUB, the BBU and pico-remote radio unit (pRRU), or the rHUB and pRRU are typically interconnected using an enhanced common public radio interface (eCPRI), and clock synchronization is achieved using the standard 1588 protocol.

[0003] Because the existing clock synchronization process requires clock source selection, the entire clock synchronization process takes a long time. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this application provides a clock synchronization method and apparatus.

[0005] According to a first aspect of the embodiments of this application, a clock synchronization method is provided, the method being applied to a clock node, the method comprising:

[0006] Receives the first synchronization (Sync) message sent by the upstream clock node connected to it;

[0007] If the first Sync message carries a first timestamp, then a first delay request (Delay_Req) ​​message is sent to the upstream clock node;

[0008] After receiving the first delay response (Delay_Resp) message carrying the second timestamp sent by the upstream clock node, the first timestamp information is obtained, and clock synchronization operation is performed based on the first timestamp information;

[0009] After completing the clock synchronization operation, determine whether there is a downstream clock node connected to it locally;

[0010] If the result is negative, the process ends.

[0011] If the determination result is yes, then a second Sync message carrying a third timestamp is sent to the downstream clock node;

[0012] If a second Delay_Req message is received from the downstream clock node within a set time period, a second Delay_Resp message carrying a fourth timestamp is sent to the downstream clock node. This allows the downstream clock node to obtain the second timestamp information after receiving the second Delay_Resp message and perform clock synchronization based on the second timestamp information. After completing the clock synchronization, the downstream clock node will use itself as the clock node and perform the step of determining whether there is a downstream clock node connected to itself locally.

[0013] The clock node can be any rHUB or pRRU in the 5G network.

[0014] When the upstream clock node is a BBU in the 5G network, the first Sync message is sent by the BBU after it has completed the local clock synchronization operation according to the existing clock synchronization procedure.

[0015] The first timestamp information includes the first timestamp when the upstream clock node sends the first Sync message, the fifth timestamp when the clock node receives the first Sync message, the second timestamp when the upstream clock node sends the first Delay_Resp message, and the sixth timestamp when the clock node sends the first Delay_Req message;

[0016] The second timestamp information includes the third timestamp when the clock node sends the second Sync message, the seventh timestamp when the downstream clock node receives the second Sync message, the fourth timestamp when the downstream clock node sends the second Delay_Resp message, and the eighth timestamp when the clock node sends the second Delay_Req message.

[0017] According to a second aspect of the embodiments of this application, a clock synchronization device is provided, the device being applied to a clock node, the device comprising:

[0018] The receiving module is used to receive the first Sync message sent by the upstream clock node connected to it;

[0019] The first sending module is configured to send a first Delay_Req message to the upstream clock node if the first Sync message carries a first timestamp;

[0020] The first synchronization module is used to obtain the first timestamp information after receiving the first Delay_Resp message carrying the second timestamp sent by the upstream clock node, and to perform clock synchronization operation according to the first timestamp information.

[0021] The judgment module is used to determine whether there is a downstream clock node connected to itself locally after the synchronization module completes the clock synchronization operation.

[0022] The termination module is used to end this process when the judgment result of the judgment module is negative;

[0023] The second sending module is used to send a second Sync message carrying a third timestamp to the downstream clock node when the judgment result of the judgment module is yes.

[0024] The first processing module is configured to send a second Delay_Resp message carrying a fourth timestamp to the downstream clock node if it receives a second Delay_Req message sent by the downstream clock node within a set time period, so that the downstream clock node can obtain the second timestamp information after receiving the second Delay_Resp message, and perform clock synchronization operation according to the second timestamp information. After completing the clock synchronization operation, the downstream clock node will use itself as the clock node and perform the step of determining whether there is a downstream clock node connected to itself locally.

[0025] The clock node can be any rHUB or any pRRU in the 5G network.

[0026] When the upstream clock node is the baseband processing unit (BBU) in the 5G network, the first Sync message is sent by the BBU after it has completed the local clock synchronization operation according to the existing clock synchronization procedure.

[0027] The first timestamp information includes the first timestamp when the upstream clock node sends the first Sync message, the fifth timestamp when the clock node receives the first Sync message, the second timestamp when the upstream clock node sends the first Delay_Resp message, and the sixth timestamp when the clock node sends the first Delay_Req message;

[0028] The second timestamp information includes the third timestamp when the clock node sends the second Sync message, the seventh timestamp when the downstream clock node receives the second Sync message, the fourth timestamp when the downstream clock node sends the second Delay_Resp message, and the eighth timestamp when the clock node sends the second Delay_Req message.

[0029] The technical solutions provided by the embodiments of this application may include the following beneficial effects:

[0030] In this embodiment of the application, after completing its own clock synchronization operation, the rHUB or pRRU in the 5G network can directly send a Sync message to the corresponding downstream clock node without having to perform source selection operation with the downstream clock node. This can save clock synchronization time.

[0031] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0032] The accompanying drawings, which are incorporated in and form part of this application, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0033] Figure 1 A flowchart illustrating a clock synchronization method provided in an embodiment of this application;

[0034] Figure 2 A schematic diagram illustrating the format of the first Sync message provided in an embodiment of this application;

[0035] Figure 3A A schematic diagram of the architecture of a 5G network provided in an embodiment of this application;

[0036] Figure 3B for Figure 3A The diagram shows the interaction between clock nodes in the network to achieve clock synchronization.

[0037] Figure 4 This is a schematic diagram of a clock synchronization device provided in an embodiment of this application. Detailed Implementation

[0038] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0039] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0040] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if” or “suppose” as used herein may be interpreted as “when…” or “when…”.

[0041] The embodiments of this application will now be described in detail.

[0042] This application provides a clock synchronization method, which is applied to a clock node, which can be any rHUB or any pRRU in a 5G network, such as... Figure 1 As shown, the method may include the following steps:

[0043] S11. Receive the first Sync message sent by the upstream clock node connected to itself.

[0044] In this step, when the upstream clock node is the BBU in the aforementioned 5G network, the first Sync message is sent by the BBU after completing its local clock synchronization operation according to the existing clock synchronization procedure. The specific implementation process is existing technology and will not be detailed here.

[0045] S12. If the first Sync message carries a first timestamp, then send the first Delay_Req message to the upstream clock node.

[0046] S13. After receiving the first delay response Delay_Resp message carrying the second timestamp sent by the upstream clock node, obtain the first timestamp information and perform clock synchronization operation based on the first timestamp information.

[0047] In this step, the first timestamp information includes the first timestamp when the upstream clock node sends the first Sync message, the fifth timestamp when the clock node receives the first Sync message, the second timestamp when the upstream clock node sends the first Delay_Resp message, and the sixth timestamp when the clock node sends the first Delay_Req message.

[0048] S14. After completing the clock synchronization operation, determine whether there is a downstream clock node connected to itself locally; if the result is no, execute step S15; if the result is yes, execute step S16.

[0049] S15. End this process.

[0050] S16. Send a second Sync message carrying a third timestamp to the downstream clock node;

[0051] S17. If a second Delay_Req message is received from a downstream clock node within a set time period, a second Delay_Resp message carrying a fourth timestamp is sent to the downstream clock node so that the downstream clock node can obtain the second timestamp information after receiving the second Delay_Resp message and perform clock synchronization operation based on the second timestamp information. After completing the clock synchronization operation, the downstream clock node will take itself as a clock node and execute the step of determining whether there is a downstream clock node connected to itself locally.

[0052] In this step, the second timestamp information includes the third timestamp when the clock node sends the second Sync message, the seventh timestamp when the downstream clock node receives the second Sync message, the fourth timestamp when the downstream clock node sends the second Delay_Resp message, and the eighth timestamp when the clock node sends the second Delay_Req message.

[0053] Furthermore, in this embodiment of the application, when the upstream node is a BBU, the aforementioned clock node may also perform the following operations:

[0054] After receiving the first Sync message sent by the upstream clock node, if the first Sync message does not carry the first timestamp, wait to receive the Follow_Up message sent by the upstream clock node;

[0055] Upon receiving a Follow_Up message carrying the ninth timestamp from the upstream clock node, send a third Delay_Req message to the upstream clock node;

[0056] When the clock node receives the third Delay_Resp message carrying the tenth timestamp from the upstream clock node, it performs clock synchronization operations based on the eleventh and tenth timestamps when it receives the Follow_Up message carrying the ninth timestamp and the twelfth timestamp when it receives the third Delay_Resp message.

[0057] In other words, in the scenario where the upstream node is a BBU, after the clock node receives the first Sync message sent by the upstream node, if the first Sync message carries a first timestamp, it means that the upstream node is configured with a single-step mode delayed request-response mechanism (also known as a request-response mechanism); if the first Sync message does not carry a first timestamp, it means that the upstream node is configured with a two-step mode delayed request-response mechanism.

[0058] Specifically, in step S13 above, the clock node can obtain the first timestamp information in the following way:

[0059] The central processing unit (CPU) in the clock node is invoked to obtain the first timestamp from the payload data of the first Sync message;

[0060] The CPU is invoked to obtain the fifth timestamp from the tail information located after the payload data of the first Sync message, where the tail information is added by the clock node when it receives the first Sync message;

[0061] The CPU is invoked to retrieve the second timestamp from the payload data of the first Delay_Resp message; and

[0062] The CPU is invoked to obtain the sixth timestamp from the tail information located after the payload data of the first Delay_Resp message. Here, the tail information is added by the clock node when it receives the first Delay_Resp message.

[0063] In one example, the fifth timestamp could be located in the timestamp field of the tail information following the payload data of the first Sync message (e.g., ...). Figure 2 (As shown). The Tail information may also include a Type field and a Sequence ID field to characterize the PTP message.

[0064] Here, the Type field and the SequenceID field can each occupy 16 bytes (bits), and the TimeStamp field can occupy 96 bits.

[0065] The sixth timestamp can also be located in the TimeStamp field of the Tail information after the payload data of the first Delay_Resp message. The specific format is similar to the fifth timestamp, and will not be described in detail here.

[0066] It should be noted that, in this embodiment of the application, the second timestamp information can be obtained for the downstream clock node in the following way:

[0067] The CPU in the upstream clock node is invoked to obtain the third timestamp from the payload data of the second Sync message;

[0068] The CPU is invoked to obtain the seventh timestamp from the tail information located after the payload data of the second Sync message, where the tail information is added by the downstream clock node when it receives the second Sync message;

[0069] The CPU is invoked to retrieve the fourth timestamp from the payload data of the second Delay_Resp message; and

[0070] The CPU is invoked to retrieve the eighth timestamp from the tail information following the payload data of the second Delay_Resp message. This tail information is added by the downstream clock node when it receives the second Delay_Resp message.

[0071] Furthermore, in this embodiment of the application, in order to ensure clock synchronization, the aforementioned clock node may also perform the following operations:

[0072] After sending the second Sync message to the downstream clock node, if the second Delay_Req message sent by the downstream clock node is not received within the set time period, the step of sending the second Sync message carrying the third timestamp to the downstream clock node connected to itself is repeated until the second Delay_Req message sent by the downstream clock node is received.

[0073] The clock synchronization method described above will be explained in detail below with reference to specific embodiments.

[0074] like Figure 3A As shown, assume a 5G network includes BBU1, rHUB1, rHUB2, and pRRU1. Of course, this network also includes... Figure 3A Other network devices not shown.

[0075] Assuming BBU1 is configured with a single-step delayed request-response mechanism, and BBU1 has completed its local clock synchronization operation according to the existing clock synchronization process, BBU1 will next send a Sync message 1 carrying t1 to the downstream clock node it is connected to (i.e., rHUB1). Figure 3B (As shown). Here, t1 is the timestamp when BBU1 sends Sync message 1.

[0076] rHUB1 receives the Sync message 1 sent by BBU1, appends tail information including t2 to the payload data of the Sync message 1, and sends a Delay_Req message 1 (e.g., ...) to BBU1. Figure 3B As shown in the figure, record the timestamp (denoted as t3) when the Delay_Req message 1 is sent. Here, t2 is the timestamp when rHUB1 receives the Sync message 1 sent by BBU1.

[0077] After receiving the Delay_Req message 1 sent by rHUB1, BBU1 sends a Delay_Resp message 1 carrying t4 to rHUB1 (e.g., Figure 3B (As shown). Here, t4 is the timestamp when BBU1 sends Delay_Resp message 1.

[0078] rHUB1 receives the Delay_Resp message 1 sent by BBU1, appends tail information including t3 to the payload data of the Delay_Resp message 1, and calls CPU1 in rHUB1 to obtain t1 from the payload data of the Sync message 1; calls CPU1 to obtain t2 from the tail information following the payload data of the Sync message 1; calls CPU1 to obtain t4 from the payload data of the Delay_Resp message 1; and calls CPU1 to obtain t3 from the tail information following the payload data of the Delay_Resp message 1. Finally, rHUB1 calls CPU1 to perform clock synchronization operation based on these four timestamps (i.e., t1, t2, t3, and t4). The specific operation process is existing technology and will not be described in detail here.

[0079] After completing the clock synchronization operation, rHUB1 checks if there is a downstream clock node connected to it. Since rHUB1 is connected to rHUB2, the result is yes. At this time, rHUB1 will send a Sync message 2 carrying t11 to the downstream clock node (i.e., rHUB2). Figure 3B (As shown). Here, t11 is the timestamp when rHUB1 sends Sync message 2.

[0080] rHUB2 receives the Sync message 2 sent by rHUB1, appends tail information including t22 to the payload data of the Sync message 2, and sends a Delay_Req message 2 (e.g., ...) to rHUB1. Figure 3B As shown in the figure, record the timestamp (denoted as t33) when sending the Delay_Req message 2. Here, t22 is the timestamp when rHUB2 receives the Sync message 2 sent by rHUB1.

[0081] After receiving the Delay_Req message 2 sent by rHUB2 within the set time period, rHUB1 sends a Delay_Resp message 2 carrying t44 (e.g., Figure 3B (As shown). Here, t44 is the timestamp when rHUB1 sends Delay_Resp message 2.

[0082] rHUB2 receives the Delay_Resp message 2 sent by rHUB1, appends tail information including t33 ​​to the payload data of the Delay_Resp message 2, and calls CPU2 in rHUB2 to obtain t11 from the payload data of the Sync message 2; calls CPU2 to obtain t22 from the tail information located after the payload data of the Sync message 2; calls CPU2 to obtain t44 from the payload data of the Delay_Resp message 2; and calls CPU2 to obtain t33 from the tail information located after the payload data of the Delay_Resp message 2. Finally, rHUB2 calls CPU2 to perform clock synchronization operation based on these four timestamps (i.e., t11, t22, t33, and t44). The specific operation process is existing technology and will not be described in detail here.

[0083] After completing the clock synchronization operation, rHUB2 checks if there is a downstream clock node connected to it locally. Since rHUB2 is connected to pRRU1, the result is yes. At this time, rHUB2 will send a Sync message 3 carrying t111 to the downstream clock node (i.e., pRRU1). Figure 3B (As shown). Here, t111 is the timestamp when rHUB2 sends Sync message 3.

[0084] pRRU1 receives the Sync message 3 sent by rHUB2, appends tail information including t222 to the payload data of the Sync message 3, and sends a Delay_Req message 3 (e.g., ...) to rHUB2. Figure 3B As shown in the figure, record the timestamp (denoted as t333) when the Delay_Req message 3 is sent. Here, t222 is the timestamp when pRRU1 receives the Sync message 3 sent by rHUB2.

[0085] After receiving the Delay_Req message 3 sent by pRRU1 within the set time period, rHUB2 sends a Delay_Resp message 3 carrying t444 to pRRU1 (e.g., Figure 3B (As shown). Here, t444 is the timestamp when rHUB2 sends the Delay_Resp message 3.

[0086] pRRU1 receives the Delay_Resp message 3 sent by rHUB2, appends tail information including t333 to the payload data of the Delay_Resp message 3, and calls CPU3 in pRRU1 to obtain t111 from the payload data of the Sync message 3; calls CPU3 to obtain t222 from the tail information following the payload data of the Sync message 3; calls CPU3 to obtain t444 from the payload data of the Delay_Resp message 3; and calls CPU3 to obtain t333 from the tail information following the payload data of the Delay_Resp message 3. Finally, pRRU1 calls CPU3 to perform clock synchronization operation based on these four timestamps (i.e., t111, t222, t333, and t444). The specific operation process is existing technology and will not be described in detail here.

[0087] After completing the clock synchronization operation, pRRU1 determines whether there is a downstream clock node connected to it locally. Since pRRU1 has no downstream clock node, the result is no, and the process ends.

[0088] As can be seen from the above technical solutions, in the embodiments of this application, for the rHUB or pRRU in the 5G network, after completing its own clock synchronization operation, it can directly send a Sync message to the corresponding downstream clock node without having to perform source selection operation with the downstream clock node. In this way, clock synchronization time can be saved.

[0089] Based on the same inventive concept, this application also provides a clock synchronization device, which is applied to a clock node, and its structural schematic diagram is shown below. Figure 4 As shown, it specifically includes:

[0090] Receiver module 41 is used to receive the first synchronization message sent by the upstream clock node connected to itself;

[0091] The first sending module 42 is used to send a first delay request Delay_Req message to the upstream clock node if the first Sync message carries a first timestamp;

[0092] The first synchronization module 43 is used to obtain the first timestamp information and perform clock synchronization operation based on the first timestamp information after receiving the first delay response Delay_Resp message carrying the second timestamp sent by the upstream clock node.

[0093] The judgment module 44 is used to determine whether there is a downstream clock node connected to itself locally after the synchronization module completes the clock synchronization operation.

[0094] End module 45 is used to end this process when the judgment result of the judgment module 44 is negative;

[0095] The second sending module 46 is used to send a second Sync message carrying a third timestamp to the downstream clock node when the judgment result of the judgment module 44 is yes.

[0096] The first processing module 47 is configured to send a second Delay_Resp message carrying a fourth timestamp to the downstream clock node if it receives a second Delay_Req message sent by the downstream clock node within a set time period, so that the downstream clock node can obtain the second timestamp information after receiving the second Delay_Resp message, and perform clock synchronization operation according to the second timestamp information. After completing the clock synchronization operation, the downstream clock node will use itself as the clock node and perform the step of determining whether there is a downstream clock node connected to itself locally.

[0097] The clock node is any remote radio unit hub (rHUB) or any small remote radio unit (pRRU) in the 5G network.

[0098] When the upstream clock node is the baseband processing unit (BBU) in the 5G network, the first Sync message is sent by the BBU after it has completed the local clock synchronization operation according to the existing clock synchronization procedure.

[0099] The first timestamp information includes the first timestamp when the upstream clock node sends the first Sync message, the fifth timestamp when the clock node receives the first Sync message, the second timestamp when the upstream clock node sends the first Delay_Resp message, and the sixth timestamp when the clock node sends the first Delay_Req message;

[0100] The second timestamp information includes the third timestamp when the clock node sends the second Sync message, the seventh timestamp when the downstream clock node receives the second Sync message, the fourth timestamp when the downstream clock node sends the second Delay_Resp message, and the eighth timestamp when the clock node sends the second Delay_Req message.

[0101] Preferably, when the upstream node is the BBU, the device further includes:

[0102] Waiting module ( Figure 4(not shown in the image), is used to wait to receive a Follow_Up message from the upstream clock node after receiving the first Sync message sent by the upstream clock node if the first Sync message does not carry the first timestamp;

[0103] Second processing module ( Figure 4 (not shown in the image), used to send a third Delay_Req message to the upstream clock node when a Follow_Up message carrying a ninth timestamp is received from the upstream clock node;

[0104] Second synchronization module ( Figure 4 (not shown in the image) is used to perform clock synchronization operations when receiving a third Delay_Resp message carrying a tenth timestamp from the upstream clock node, based on the ninth timestamp, the eleventh timestamp when the clock node receives the Follow_Up message carrying the ninth timestamp, the tenth timestamp, and the twelfth timestamp when receiving the third Delay_Resp message.

[0105] Preferably, the first synchronization module 43 is specifically used for:

[0106] The CPU in the clock node is invoked to obtain the first timestamp from the payload data of the first Sync message;

[0107] The CPU is invoked to obtain the fifth timestamp from the tail information located after the payload data of the first Sync message, wherein the tail information is added by the clock node when it receives the first Sync message;

[0108] The CPU is invoked to obtain the second timestamp from the payload data of the first Delay_Resp message; and

[0109] The CPU is invoked to obtain the sixth timestamp from the tail information located after the payload data of the first Delay_Resp message, wherein the tail information is added by the clock node when it receives the first Delay_Resp message.

[0110] Preferably, the first processing module 47 is further configured to:

[0111] After the second sending module sends the second Sync message to the downstream clock node, if the second Delay_Req message sent by the downstream clock node is not received within the set time period, the second sending module is triggered to execute the step of sending the second Sync message carrying the third timestamp to the downstream clock node connected to itself, until the first processing module receives the second Delay_Req message sent by the downstream clock node.

[0112] As can be seen from the above technical solutions, in the embodiments of this application, for the rHUB or pRRU in the 5G network, after completing its own clock synchronization operation, it can directly send a Sync message to the corresponding downstream clock node without having to perform source selection operation with the downstream clock node. In this way, clock synchronization time can be saved.

[0113] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method of clock synchronization, characterized by, The method is applied to a clock node, and the method comprises: receiving a first synchronization (Sync) packet sent by an upstream clock node connected to the clock node; if a first timestamp is carried in the first Sync packet, sending a first delay request (Delay_Req) packet to the upstream clock node; after receiving a first delay response (Delay_Resp) packet sent by the upstream clock node and carrying a second timestamp, obtaining first timestamp information and performing a clock synchronization operation according to the first timestamp information; after the clock synchronization operation is completed, determining whether there is a downstream clock node connected to the clock node locally; if the determination result is no, ending the process; if the determination result is yes, sending a second Sync packet carrying a third timestamp to the downstream clock node; if a second Delay_Req packet sent by the downstream clock node is received within a set time length, sending a second Delay_Resp packet carrying a fourth timestamp to the downstream clock node, so that the downstream clock node, after receiving the second Delay_Resp packet, obtains second timestamp information and performs a clock synchronization operation according to the second timestamp information, and after the clock synchronization operation is completed, takes the clock node as the clock node and executes the step of determining whether there is a downstream clock node connected to the clock node locally; wherein the clock node is any remote radio unit hub (rHUB) or any pico remote radio unit (pRRU) in a 5G network; when the upstream clock node is a baseband processing unit (BBU) in the 5G network, the first Sync packet is sent by the BBU after completing a local clock synchronization operation according to an existing clock synchronization process; the first timestamp information comprises the first timestamp when the upstream clock node sends the first Sync packet, a fifth timestamp when the clock node receives the first Sync packet, the second timestamp when the upstream clock node sends the first Delay_Resp packet, and a sixth timestamp when the clock node sends the first Delay_Req packet; the second timestamp information comprises the third timestamp when the clock node sends the second Sync packet, a seventh timestamp when the downstream clock node receives the second Sync packet, the fourth timestamp when the downstream clock node sends the second Delay_Resp packet, and an eighth timestamp when the clock node sends the second Delay_Req packet.

2. The method of claim 1, wherein, when the upstream clock node is the BBU, the method further comprises: after receiving the first Sync packet sent by the upstream clock node, if the first timestamp is not carried in the first Sync packet, waiting to receive a Follow_Up packet sent by the upstream clock node; sending a third Delay_Req message to the upstream clock node upon receiving the Follow_Up message carrying the ninth timestamp sent by the upstream clock node; performing clock synchronization operation according to the ninth timestamp, an eleventh timestamp at which the clock node receives the Follow_Up message carrying the ninth timestamp, the tenth timestamp and a twelfth timestamp at which the third Delay_Resp message is received upon receiving the third Delay_Resp message carrying the tenth timestamp sent by the upstream clock node.

3. The method of claim 1, wherein, obtaining first timestamp information, specifically comprising: calling a CPU in the clock node to obtain the first timestamp from the payload data of the first Sync message; calling the CPU to obtain the fifth timestamp from tail information located behind the payload data of the first Sync message, wherein the tail information is added by the clock node upon receiving the first Sync message; calling the CPU to obtain the second timestamp from the payload data of the first Delay_Resp message; and calling the CPU to obtain the sixth timestamp from tail information located behind the payload data of the first Delay_Resp message, wherein the tail information is added by the clock node upon receiving the first Delay_Resp message.

4. The method of claim 1, wherein, The method further comprises: after sending the second Sync message to the downstream clock node, if the second Delay_Req message sent by the downstream clock node is not received within the set time length, re-executing the step of sending the second Sync message carrying the third timestamp to the downstream clock node connected to itself until the second Delay_Req message sent by the downstream clock node is received.

5. A clock synchronization apparatus characterized by comprising: The device is applied to a clock node, and the device comprises: a receiving module configured to receive a first synchronization Sync message sent by an upstream clock node connected to itself; a first sending module configured to send a first delay request Delay_Req message to the upstream clock node if the first Sync message carries a first timestamp; a first synchronization module configured to obtain first timestamp information after receiving a first delay response Delay_Resp message carrying a second timestamp sent by the upstream clock node, and perform clock synchronization operation according to the first timestamp information; a judging module configured to judge whether there is a downstream clock node connected to itself locally after the synchronization module completes the clock synchronization operation; an ending module configured to end the current process when the judgment result of the judging module is no; a second sending module configured to send a second Sync message carrying a third timestamp to the downstream clock node when the judgment result of the judging module is yes; The first processing module is configured to, if the second Delay_Req packet sent by the downstream clock node is received within a set time length, send a second Delay_Resp packet carrying a fourth timestamp to the downstream clock node, so that the downstream clock node acquires second timestamp information after receiving the second Delay_Resp packet, performs a clock synchronization operation according to the second timestamp information, and after the clock synchronization operation is completed, regards itself as the clock node and performs the step of judging whether there is a downstream clock node connected to itself. The clock node is any radio remote unit hub (rHUB) or any small radio remote unit (pRRU) in a 5G network. When the upstream clock node is a baseband processing unit (BBU) in the 5G network, the first Sync packet is sent by the BBU after completing a local clock synchronization operation according to an existing clock synchronization process. The first timestamp information includes the first timestamp when the upstream clock node sends the first Sync packet, a fifth timestamp when the clock node receives the first Sync packet, the second timestamp when the upstream clock node sends the first Delay_Resp packet, and a sixth timestamp when the clock node sends the first Delay_Req packet. The second timestamp information includes the third timestamp when the clock node sends the second Sync packet, a seventh timestamp when the downstream clock node receives the second Sync packet, the fourth timestamp when the downstream clock node sends the second Delay_Resp packet, and an eighth timestamp when the clock node sends the second Delay_Req packet.

6. The apparatus of claim 5, wherein, When the upstream clock node is the BBU, the device further includes: The waiting module is configured to, after receiving the first Sync packet sent by the upstream clock node, if the first Sync packet does not carry the first timestamp, wait to receive a Follow_Up packet sent by the upstream clock node. The second processing module is configured to, when receiving the Follow_Up packet carrying an ninth timestamp sent by the upstream clock node, send a third Delay_Req packet to the upstream clock node. The second synchronization module is configured to, when receiving a third Delay_Resp packet carrying a tenth timestamp sent by the upstream clock node, perform a clock synchronization operation according to the ninth timestamp, an eleventh timestamp when the clock node receives the Follow_Up packet carrying the ninth timestamp, the tenth timestamp, and a twelfth timestamp when the third Delay_Resp packet is received.

7. The apparatus of claim 5, wherein, The first synchronization module is specifically configured to: invoke a CPU in the clock node to acquire the first timestamp from payload data of the first Sync packet; calling the CPU to obtain the fifth timestamp from tail information behind payload data of the first Sync packet, wherein the tail information is added by the clock node when receiving the first Sync packet; calling the CPU to obtain the second timestamp from payload data of the first Delay_Resp packet; and calling the CPU to obtain the sixth timestamp from tail information behind payload data of the first Delay_Resp packet, wherein the tail information is added by the clock node when receiving the first Delay_Resp packet.

8. The apparatus of claim 5, wherein, The first processing module is further configured to: after the second sending module sends the second Sync packet to the downstream clock node, if the second Delay_Req packet sent by the downstream clock node is not received within the set time length, triggering the second sending module to perform the step of sending the second Sync packet carrying a third timestamp to the downstream clock node connected with itself until the first processing module receives the second Delay_Req packet sent by the downstream clock node.

Images