PTP time service method and device and storage medium

By introducing a custom traceability field (TLV) into the PTP message, the stability and reliability issues of time synchronization in complex network environments are resolved, achieving transparency and traceability of high-precision time synchronization and improving the reliability of time synchronization.

CN121396375APending Publication Date: 2026-01-23SICHUAN TAIFU GROUND BEIDOU TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511328512.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-09-17
Publication Date
2026-01-23

AI Technical Summary

Technical Problem

Existing time synchronization methods struggle to maintain stability and reliability in complex network environments, and how to achieve a flexible time synchronization mechanism, especially in large-scale network structures, remains a concern for the industry.

Method used

The IEEE 1588 standard introduces a custom traceable additional field TLV into the PTP message. This field includes fields that characterize the level, precision difference, name, and link information of the timing clock source. Through the collaborative processing of the PTP server, intermediate nodes, and clients, these fields are updated level by level to achieve the transparency and traceability of the link.

Benefits of technology

It improves the reliability and transparency of time synchronization, enhances the traceability of the time synchronization link, and maintains the advantages of PTP's high-precision time synchronization.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121396375A_ABST
    Figure CN121396375A_ABST
Patent Text Reader

Abstract

The invention discloses a PTP time service method and device and a storage medium. The method comprises the following steps: adding a customized traceable additional field TLV in a PTP message conforming to the IEEE 1588 standard, wherein the TLV meets the structure of even byte alignment; generating and packaging a PTP (Precision Time Protocol) message carrying the TLV through a PTP server side; forwarding the PTP message through an intermediate node, and updating the second field, the fourth field and the fifth field step by step in the forwarding process; receiving the PTP message through a PTP client and analyzing the PTP message to obtain the TLV; and through the PTP client, based on the first field to the sixth field in the TLV, determining the credibility and the expected precision of the received time.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and particularly relates to a PTP time service method and device and a storage medium. BACKGROUND

[0002] Time synchronization technology plays an important role in key industries such as communication, power, finance and transportation. With the rapid development of distributed systems and high-precision services, network time service capability has become a basic condition to ensure stable operation of the system.

[0003] Existing time service methods mainly include a Network Time Protocol (NTP) based method and a Precision Time Protocol (PTP) based method. The NTP is widely used and suitable for scenarios with general precision requirements. The PTP has been applied in scenarios with high precision requirements such as power, industrial control and mobile communication due to its higher synchronization precision.

[0004] However, with the continuous expansion of application scenarios, the existing time service methods still face some limitations in complex network environments. For example, how to maintain the stability and credibility of time synchronization in large-scale network structures and how to implement a more flexible time synchronization mechanism in different types of links are still problems of industry concern. SUMMARY

[0005] To solve the above technical problems, the present application provides a PTP time service method, device and storage medium.

[0006] The technical solutions provided in the present application are described as follows: The first aspect of the present application provides 1, a PTP time service method, characterized in that the method comprises: adding a self-defined traceable additional field TLV in a PTP message conforming to the IEEE 1588 standard, the TLV satisfying an even digital byte alignment structure; the traceable additional field at least includes: a first field for representing the level of a time service clock source, a second field for representing the precision difference between a current clock and the time service clock source, the second field being accumulated at a link node by level, a third field for identifying the name of the time service clock source, a sixth field for respectively representing the type and the number of nodes of a link through which the time service clock source passes to a current clock node and for representing the identification information of each node in the link; generating and encapsulating a PTP message carrying the TLV through a PTP server end; forwarding the PTP message through an intermediate node and updating the second field, the fourth field and the fifth field by level in the forwarding process; receiving and parsing the PTP packet by a PTP client to obtain the TLV; determining the trust degree and expected accuracy of the received time based on the first to sixth fields in the TLV by the PTP client.

[0007] Optionally, the rule of the second field accumulated by the nodes of the link stage by stage comprises: when the link is a fiber timing link, the value of the second field is increased by 2 picoseconds on the basis of the previous node; when the link is a PTP timing link, the value of the second field is increased by 5 nanoseconds to 50 nanoseconds on the basis of the previous node; when the link is an NTP timing link, the value of the second field is increased by 10 microseconds to 1 millisecond on the basis of the previous node.

[0008] Optionally, the fourth field is used to represent the link type, and the value of the fourth field comprises: 0x01: represents a fiber timing link; 0x02: represents a PTP link; 0x03: represents an NTP link; 0x04 to 0xFF: reserved value.

[0009] Optionally, the sixth field is composed of 8 bytes of clock identifier, and when the fifth field is greater than zero, the sixth field records the clock identifiers of the nodes in the link in turn.

[0010] Optionally, the value of the first field comprises: a value of 1: represents an atomic clock group; a value of 6: represents an enhanced master reference clock or a master reference clock normally tracking a satellite; a value of 7: represents an enhanced master reference clock or a master reference clock in a satellite signal loss holding state; a value of 52: represents an enhanced master reference clock or a master reference clock in a free running state.

[0011] Optionally, the determination of the trust degree and expected accuracy of the received time based on the first to sixth fields in the TLV comprises: determining the level of the timing clock source and setting the reference trust degree based on the first field; calculating the expected accuracy of the current clock relative to the timing clock source based on the second field and the accuracy difference accumulated by the nodes in the link stage by stage; confirming the name information of the timing clock source based on the third field to perform verification on the uniqueness of the timing clock source; based on the fourth field and the fifth field, identifying the link type and the link depth between the time service clock source and the current clock, thereby determining the degree of influence of the structure of the link on the degree of trustworthiness; based on the sixth field, checking the clock identification of each intermediate node in the link.

[0012] Optionally, forwarding the PTP packet through the intermediate nodes and updating the second field, the fourth field and the fifth field step by step during the forwarding process comprises: parsing the last fourth field in the TLV to obtain the link type; when the link type is the same as the time service mechanism of the current node and is a PTP link, adding 1 to the number of nodes in the corresponding fifth field; when the link type is inconsistent with the time service mechanism of the current node, adding a new fourth field in the TLV and setting it as the link type of PTP, and initializing the number of nodes to 1 in the corresponding fifth field; estimating the precision loss value caused by the current node and accumulating the precision loss value in the second field.

[0013] Optionally, the adding of the self-defined traceable additional field TLV in the PTP packet conforming to the IEEE 1588 standard comprises: defining the traceable additional field based on the TLV structure specified in the PTP protocol; setting the traceable additional field as an even byte-aligned storage format; encapsulating the traceable additional field at the end of the PTP announce packet.

[0014] The second aspect of the present application provides a PTP time service device, the device comprising: a field configuration unit configured to add a self-defined traceable additional field TLV in a PTP packet conforming to the IEEE 1588 standard, the TLV satisfying an even byte-aligned structure; the traceable additional field comprising at least: a first field for representing the level of a time service clock source, a second field for representing the precision difference between a current clock and the time service clock source, the second field being accumulated step by step at link nodes, a third field for identifying the name of the time service clock source, a sixth field for representing the type and the number of nodes of the link through which the time service clock source passes to the current clock node, and the identification information of each node in the link; a packet generation unit configured to generate and encapsulate a PTP packet carrying the TLV through a PTP server end; The message forwarding unit is configured to forward the PTP message through the intermediate node, and update the second field, the fourth field and the fifth field step by step during the forwarding process. The message analysis unit is configured to receive and analyze the PTP message through the PTP client, and obtain the TLV. The credibility determination unit is configured to determine the credibility and expected accuracy of the received time based on the first to sixth fields in the TLV through the PTP client.

[0015] The third aspect of the present application provides a PTP time service device, the device comprises: a processor, a memory, an input / output unit and a bus; The processor is connected with the memory, the input / output unit and the bus; The memory stores a program, and the processor invokes the program to execute the method of the first aspect and any optional method in the first aspect.

[0016] The fourth aspect of the present application provides a computer readable storage medium, the computer readable storage medium stores a program, and the program executes the method of the first aspect and any optional method in the first aspect when executed on a computer.

[0017] From the above technical solutions, the present application has the following beneficial effects: The present application introduces a self-defined traceable additional field in the PTP message conforming to the IEEE 1588 standard, realizes the step-by-step recording and information transmission of the time service link. Through the cooperative processing of the PTP server, the intermediate node and the PTP client, the clock source level, the link path structure and the accuracy difference information can be kept complete and visible during the transmission process, so that the client can judge the source, credibility and expected accuracy of the received time information when receiving the time information. Therefore, the present application can enhance the transparency and traceability of the time service link while maintaining the high-precision time service advantage of PTP, and improve the credibility of time synchronization. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the present application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0019] Figure 1 An embodiment flowchart of the PTP time service method provided in the present application; Figure 2 Figure 1 is a flowchart illustrating an embodiment of step S103 of the PTP time service method provided in the present application; Figure 3 Figure 2 is a structural diagram of an embodiment of the PTP time service device provided in the present application; Figure 4 Figure 3 is a structural diagram of another embodiment of the PTP time service device provided in the present application. DETAILED DESCRIPTION

[0020] It should be understood that the steps, flows or functions described in the embodiments of the present application can be performed by any of the PTP server, PTP intermediate node or PTP client, or can be completed by multiple subjects in cooperation. The specific execution subject does not constitute a limitation on the present application. Those skilled in the art can select to implement the method of the present application in a hardware device, software program or a combination of software and hardware according to the specific application scenario. The description of the embodiments in the present specification is merely for illustrating the technical solutions of the present application, and not for limiting the execution subject or the implementation manner.

[0021] The present embodiment provides a PTP (Precision Time Protocol) based time service method. The method can be performed by a time service system conforming to the IEEE 1588 standard, including a PTP server, one or more intermediate nodes and a PTP client. The implementation process of the present embodiment is described in detail below in combination with each step.

[0022] Referring to Figure 1 , the present application first provides an embodiment of a PTP time service method, which includes the following steps: S101, adding a self-defined traceable additional field TLV in a PTP message conforming to the IEEE 1588 standard, the TLV satisfying an even number of byte alignment structure; the traceable additional field at least includes: a first field for representing the level of a time service clock source, a second field for representing the precision difference between the current clock and the time service clock source, the second field being accumulated step by step at the link node, a third field for identifying the name of the time service clock source, a sixth field for respectively representing the type and the number of nodes of the link through which the time service clock source passes to the current clock node and for representing the identification information of each node in the link; In the present application, a type of self-defined extended TLV (hereinafter referred to as “TLV”) is reserved and defined in the PTP message structure conforming to the IEEE 1588 standard. The TLV can include the following basic parts: Type (2 bytes): used to identify the type of the TLV as a type identification code (for example, 0x5012 can be used in the embodiment to represent a basic TLV, and 0x5013 can be used to represent a TLV containing a clock ID); Length (2 bytes): represents the total length of the TLV (including Type and Length, the value of this field is kept as an even number of bytes to meet the alignment requirements of IEEE 1588 TLV); Traceability Information (variable length): a payload area carrying traceability data, arranged in a predetermined order with several subfields.

[0023] In a specific embodiment, the structure of the custom TLV field described in the application is shown in Table 1.

[0024] Table 1: Structure of the custom TLV field;

[0025] Referring to Table 2 below, the Traceability Information subfields are organized in the following order in the embodiment (exemplary field lengths and meanings): The first field (which can be 1 byte): clock source class (Clock Class); The second field (which can be 6 bytes): accuracy, which represents the cumulative error of the current node relative to the top-level clock source, and the unit can be picoseconds (ps); The third field (which can be 8 bytes): clock source name (Clock Name), used to identify the top-level clock source (which can be no more than 8 characters); The fourth and fifth fields (which can be 1+1 bytes per group): link types and the number of nodes of that type that have appeared in the path are recorded in the form of several pairs (Node Type, 1 byte; Node Count, 1 byte); The sixth field: when it is necessary to record the identification of each level node, the clock identification of each level node is sequentially attached in the order specified by the Node Count (for example, each Clock ID is fixed at 8 bytes) to achieve complete node ID recording for the path.

[0026] To ensure compatibility with the IEEE 1588 protocol, the embodiment requires that the total length of the TLV be an even number of bytes; for implementations that do not use the sixth field, only the "type + number" statistical mode of the fourth / fifth field can be used to reduce packet overhead; for scenarios that require more detailed traceability, the sixth field can be enabled to record the identification of each level node.

[0027] For example, a certain TLV can set "Clock Class=6" "Accuracy=20ns" "Clock Name=NTSC-1" "Node type=PTP" "Node count=1", and record the identification information of the first node in the sixth field.

[0028] Table 2: Traceability Information structure table (including clock ID);

[0029] In one embodiment, the value of the fourth field includes: 0x01: indicates a fiber timing link; 0x02: indicates a PTP link; 0x03: indicates an NTP link; 0x04 to 0xFF: reserved values.

[0030] In one embodiment, the value of the first field includes: Value 1: indicates an atomic clock group; Value 6: indicates an enhanced master reference clock or master reference clock normally tracking a satellite; Value 7: indicates an enhanced master reference clock or master reference clock in a satellite signal loss holdover state; Value 52: indicates an enhanced master reference clock or master reference clock in a free running state.

[0031] Further, the sixth field consists of 8 bytes of clock identification, and when the fifth field is greater than zero, the sixth field records the clock identification of each node in the link in turn.

[0032] In one embodiment, to achieve unified management of multiple timing systems and support of traceable technology, the present application defines each field (such as Clock Class, Accuracy, etc.) involved in the TLV. Among them, Clock Class is carried or defined by the clock server, used to identify the level and attributes of the time source. To ensure unified and accurate time traceability in a traceable time link, the present application provides that only one Clock Class is allowed in a time link, which is uniquely determined by the clock source at the start of the link.

[0033] Specifically, the definition of Clock Class is shown in Table 3: Table 5: Clock Class definition table;

[0034] Through the above definition, the application can provide a unified Clock Class identification mechanism for a multi-source time service system on the basis of ensuring IEEE 1588 protocol compatibility, thereby realizing traceable time link management. In particular, through the unique Clock Class definition, conflicts between clock signals of different sources in the same link can be effectively avoided, and the accuracy and reliability of the system in the time transmission and traceability process can be improved.

[0035] S102, generating and encapsulating a PTP message carrying the TLV through a PTP server end; In this step, before generating an announce message at the server end (for example, a master clock or a boundary clock), the following operations are performed to initialize the TLV: First, a first field (clock source level) is determined and written, and the corresponding level value is set by the server according to the top-level time source (such as a national time center, ePRTC, etc.) accessed by the server; The second field (Accuracy) is initialized, and the initial value is set by the server according to the inherent accuracy of the local clock or the known deviation from the top-level clock source; the unit and the representation are consistent with the specification; The third field (Clock Name) is written, and the clock source name defined by the server is written as a string or code of no more than 8 bytes; The fourth / fifth field (Node Type / Node Count) is initialized, and the path statistics can be set to empty (Node Count is 0) at the server end or the first link type and initial node number are written according to the physical topology; If the TLV containing the Clock ID (Type=0x5013) is used, the server can also write its Clock ID at the sixth field (if applicable).

[0036] The Length field of the TLV (including Type and Length itself) is calculated according to the above content, and even byte alignment is ensured; if padding is required, the agreed padding bytes (processed according to the IEEE 1588 TLV padding rule) are used.

[0037] The TLV is encapsulated into the PTP message to be sent (for example, the extension area of the announce message) according to the format of the PTP message extension TLV area, and the message construction is completed; then, the server sends the message to the downstream node according to the PTP sending process.

[0038] S103, forwarding the PTP message through an intermediate node, and updating the second field, the fourth field and the fifth field step by step in the forwarding process; In this step, when receiving the PTP packet containing the TLV, if the node supports the analysis of the TLV, the integrity of the TLV is checked, and each field is analyzed. In the forwarding process, the intermediate node updates the traceability information step by step according to the link type and node attribute of the node where the intermediate node is located. Specifically, if the link type of the current node is the same as the previous record, the corresponding node number is increased by one; if not, a set of link type and number fields are added. At the same time, the intermediate node estimates the error amount introduced by itself and adds it to the second field, thereby forming the precision difference accumulated hop by hop. If the node-by-node recording mode is adopted, the intermediate node can also append the node identifier of itself to the sixth field. After the update is completed, the intermediate node recalculates the length of the TLV and forwards the packet. For old nodes that do not support the TLV, compatibility can be maintained, and the packet can be directly transmitted without affecting the PTP synchronization.

[0039] Specifically, after receiving the PTP packet carrying the TLV, the intermediate node (excluding the case of transparent clock) first detects whether the node supports the analysis of the TLV: If it supports, the TLV is subjected to a regular integrity check (checking the consistency of Type / Length and even alignment), and each field in the Traceability Information area is analyzed; If it does not support or is an old device, the TLV can be directly ignored according to the compatibility strategy (i.e., not analyzed, not updated) and the packet is forwarded, ensuring that the entire time service function is not affected.

[0040] For intermediate nodes that support analysis, the following step-by-step update steps are performed: Judge the link type: read the Node Type value recorded in the last group (or a predefined position) in the TLV, and compare it with the time service link type of the node (the node can determine its type through local configuration or device capability, such as PTP node whose type value is 0x02); Node Count update: If the last Node Type is the same as the type of the node, the value of the Node Count field is increased by one; If not, a set of Node Type / Node Count pairs is added in the Traceability Information area, the Node Type is set to the type value of the node, and the Node Count is initialized to 1; Accuracy accumulation: First, the influence increment (Δ_accuracy) of the node or the link to which the node belongs on the time accuracy is estimated and calculated, the value of Δ_accuracy can be set according to the link type and node performance or reference the description of defaultDS.clock Quality.clock Accuracy in PTP; Δ_accuracy is accumulated in the second field (Accuracy) in the TLV to reflect the growth of the accumulated error; an exemplary accumulation strategy is: about +2ps per hop for fiber links, about +5ns-50ns per hop for PTP links, and about +10μs-1ms per hop for NTP time service links.

[0041] If the TLV is of the clock ID type and uses the full path record mode, the clock identifier (fixed length, for example, 8 bytes) of the node is appended to the corresponding node sequence position; Length field update: after modifying the Traceability Information, the Length field of the TLV is recalculated and written back to ensure even byte alignment; if padding is required, padding is filled according to the protocol requirements.

[0042] After the update is completed, the intermediate node sends the updated PTP packet to the downstream node according to the conventional PTP forwarding process.

[0043] The application also provides a specific embodiment of step S103, in which step S103 describes the specific processing procedure of the intermediate node for parsing and updating the TLV as needed after receiving the PTP packet carrying the TLV. For ease of illustration, it is assumed that the Traceability Information area of the TLV contains the first field (Clock Class), the second field (Accuracy), the third field (Clock Name), several groups of fourth / fifth fields (Node Type / Node Count), and the optional sixth field (node-by-node Clock ID list) in the order.

[0044] S1031, parsing the last fourth field in the TLV to obtain the link type; After receiving the PTP packet containing the Traceability TLV, the intermediate node can first perform basic verification: identify whether the Type field of the TLV is the traceability type (for example, 0x5012 or 0x5013) defined in the embodiment; read and verify whether the Length field matches the actual payload length of the packet; check whether the Length is an even number of bytes (if not, it is considered to be a format exception and handled according to the compatible strategy). If the verification fails, the intermediate node can directly transmit the packet according to the compatible strategy (without modification), and record an abnormal log locally or report to the operation and maintenance system. If the verification passes, the following detailed processing steps are entered.

[0045] Further, the last fourth field is parsed to obtain the link type. First, the Node Type / Node Count list of the TraceabilityInformation area is located. According to the field arrangement rule of the TLV, the Node Type (1 byte) and Node Count (1 byte) pairs are read in turn from the fourth field until the end of the reading or the start position of the sixth field is encountered.

[0046] If the list is not empty, the last read Node Type value is taken as the "current recorded link type" (denoted as last_node_type). If the list is empty, it is considered that no link type has been recorded in the path (last_node_type = empty).

[0047] If the Node Type / Node Count list is [0x01, 0x02], [0x02, 0x03], then last_node_type = 0x02 (indicating that the last recorded is a PTP link, and the number of nodes of this type is 3).

[0048] S1032, when the link type is the same as the time service mechanism of the current node and is a PTP link, the number of nodes in the corresponding fifth field is increased by 1. When last_node_type is the same as the time service mechanism of the current node and is PTP, the corresponding Node Count is increased by 1; if last_node_type is consistent with the type of the current node and is equal to the PTP type (for example, last_node_type == 0x02 and the current node is a PTP node), the Node Count corresponding to the entry is increased by 1: Node Count_new = Node Count_old + 1.

[0049] When the Node Count field is 1 byte, if NodeCount_old has reached the maximum value of the field (255), any of the following processing strategies can be adopted: Saturate NodeCount to the maximum value (255) and log an overflow alarm locally or in the network management system; Alternatively, a new set of NodeType / NodeCount entries of the same type can be added to the TLV to continue counting (the implementer can provide the preferred strategy and alternative strategies in the specification).

[0050] For example, if the last entry is Node Type=0x02, Node Count=3, and this node is a PTP, then update it to NodeCount=4.

[0051] S1033. When the link type is inconsistent with the timing mechanism of the current node, a fourth field is added to the TLV and set to the link type of PTP, and the number of nodes is initialized to 1 in the corresponding fifth field. When last_node_type is inconsistent with the current node's time synchronization mechanism, add a new record with Node Type PTP and initialize the number of nodes to 1; Specifically, first determine if last_node_type is different from the current node type or if the list is empty. If they are different, construct a new Node Type / Node Count pair and append it to the end of the Node list: append(NodeType=current node type, Node Count=1). For example, appending [0x02, 0x01] indicates that the current node is the first hop of this type.

[0052] If the TLV used is a complete path record mode including Clock ID (e.g., Type=0x5013), when adding a new NodeType / NodeCount pair, insert the corresponding number of ClockID placeholders in the sixth field according to the value of NodeCount and write the ClockID (e.g., an 8-byte identifier) ​​of this node. If the node-by-node ID mode is not used, only the fourth / fifth fields are updated.

[0053] When appending, maintain the consistent order of fields (for example, the sequence of NodeType / NodeCount pairs can be placed immediately after the third field, and the sixth field, if present, can be placed immediately after the Node list).

[0054] For example, if the current last_node_type is 0x01 (fiber optic) and this node is PTP (0x02), then [0x02, 0x01] will be appended to the end of the Node list. If the TLV contains a Clock ID, then the Clock ID of this node (e.g., 0xAA1122BB3344CC55) will be appended to the sixth field.

[0055] S1034, estimate the precision loss value caused by the current node, and accumulate the precision loss value in the second field.

[0056] In this step, first determine the precision loss increment of the current node or the link in the current segment. The precision loss increment can be obtained in one of the following ways or a combination thereof: According to the preset link type accumulation strategy table, for example, about +2ps per hop for optical fiber, about +5ns~50ns per hop for PTP, and about +10us~1ms per hop for NTP; According to the actual performance index of the current node (such as hardware timestamp precision, queuing delay statistics, known device delay parameters, etc.), dynamically estimate; Combine historical statistical data or device performance parameters issued by the network management to make more accurate estimation.

[0057] If the second field is expressed in picoseconds (ps), the precision loss increment needs to be converted to ps before accumulation.

[0058] If the accumulation result exceeds the representation range of the second field or the maximum value that can be stored by the field length, it should be handled according to the preset strategy, for example, set Accuracy to the maximum representable value and record the overflow alarm locally or on the network management, or use the network management to adjust the field representation method (as an optional improvement).

[0059] After updating the Node list and Accuracy, the intermediate node recalculates the Length field value of the TLV and ensures that Length is an even number of bytes. If it is an odd number of bytes, a padding byte (such as 0x00) is added at the end of the TLV to meet the alignment requirement.

[0060] In summary, the update operation of the intermediate node on the TLV in this embodiment is performed in the order of "analysis→determination→update node count and / or add new node record→estimate and accumulate precision→rewrite Length and alignment→recalculate necessary check and forward". A practical example is given for further explanation: A PTP message initially sent by a PTP server has Node Type List=[0x01,0x02] (2 hops of optical fiber) and Accuracy=2000ps; when a PTP intermediate node receives and identifies it as a PTP link, it updates the NodeType List to [0x01,0x03] according to the operation of S1032, and increases the Accuracy by the precision loss increment of the current node (for example, +20000ps, i.e. 20ns), and writes it back and forwards; the receiving end can obtain the updated traceability information reflecting the real structure of the link and the cumulative precision when parsing.

[0061] S104, receiving and parsing the PTP packet by the PTP client to obtain the TLV; After the PTP client receives the PTP packet containing the TLV, first, the Type and Length are parsed according to the TLV specification, and the even alignment and validity of the Length are verified; The first field to the third field (ClockClass, Accuracy, ClockName) are read and interpreted in turn; then a plurality of groups of Node Type / Node Count pairs are read in an iterative manner; when the sixth field (node-by-node identification record) exists, a corresponding number of ClockID entries are read according to the value of each group of Node Count and are assigned to a corresponding semantic position; The parsed results are subjected to basic consistency checking, for example: the Clock Name length conforms to the agreement (≤8 bytes), the cumulative Accuracy value is within the expected value range, the TLV length matches the actual field length, etc.; if parsing errors or inconsistencies are found, the parsing can be marked as a failure or an exception alarm can be issued according to a preset strategy; After parsing, the client can temporarily store the structured traceability information in a local data structure, and report the information to a network management system or display it on a local visual interface as needed; the information can be used for operation and management strategies.

[0062] S105, determining the trust degree and expected accuracy of the received time based on the first field to the sixth field in the TLV by the PTP client.

[0063] The PTP client performs a process of trustworthiness and accuracy evaluation based on the first field to the sixth field in the parsed TLV, and in a specific implementation manner, the manner includes: Based on the first field, the level of the time source clock is determined and the reference trustworthiness is set; Based on the second field, the expected accuracy of the current clock relative to the time source clock is calculated in combination with the accuracy difference accumulated by the nodes in the link; Based on the third field, the name information of the time source clock is confirmed to perform verification on the uniqueness of the time source clock; Based on the fourth field and the fifth field, the link type and the link depth between the time source clock and the current clock are identified, so as to determine the influence degree of the structure of the link on the trust degree; Based on the sixth field, the clock identification of each intermediate node in the link is verified.

[0064] Specifically, after receiving the PTP packet containing the traceable TLV, the PTP client parses and processes each field in the TLV in turn to finally determine the credibility and expected accuracy of the received time. Specifically, the following steps are included: Firstly, based on the first field, the PTP client can determine the level information of the time service clock source (i.e. ClockClass). Different clock source levels correspond to different time reference credibility, for example, the highest level of credibility corresponds to atomic clocks such as cesium clocks and hydrogen clocks, and the lower level of credibility corresponds to the master reference clock in the free running state. After parsing the first field, the PTP client can use it as a reference value for calculating the link credibility.

[0065] Based on the second field, the PTP client calculates the expected accuracy of the current clock relative to the time service clock source in combination with the accuracy difference accumulated at each level in the link. For example, each node in the link introduces a small transmission error or processing delay, and the second field records the cumulative result of the accuracy difference. The PTP client can use the expected accuracy as a correction index for the time service quality based on the reference credibility, thereby obtaining a more realistic clock accuracy evaluation.

[0066] Based on the third field, the PTP client can confirm the name information of the time service clock source. Since there may be multiple clock sources in a complex multi-time service system, the PTP client can verify the uniqueness of the time service clock source by comparing the name information carried in the third field, thereby avoiding time service deviation caused by incorrect clock source identification.

[0067] Based on the fourth and fifth fields, the PTP client can identify the link type and link depth between the time service clock source and the current clock node. The fourth field is used to indicate the link type (such as PTP link, GNSS link, etc.), and the fifth field is used to indicate the link depth (i.e. the number of nodes passed through). The PTP client can judge the influence of the time link structure on the overall credibility based on the reliability of the link type and the complexity of the link depth.

[0068] Based on the sixth field, the PTP client can verify the clock identification of each intermediate node in the link. For example, the PTP client can compare the identification information of each intermediate node to confirm whether there are unauthorized or untrusted nodes in the link, thereby further improving the security and credibility of the link.

[0069] Based on the above evaluation, the client makes a decision according to the internal strategy, an exemplary decision includes: When the Clock Class, Accuracy and path structure all meet the local configured trust and accuracy threshold, the client accepts the time and performs local time adjustment; When at least one evaluation does not meet the local threshold (e.g. cumulative error exceeds the upper limit, or there are too many low-accuracy links in the path), the client rejects synchronization based on the time source, or marks the time source as an alternative and reduces the priority; When the resolution result shows that the traceability information is inconsistent with the local network management registration information or is abnormal (e.g. ClockName is unknown, Clock ID does not match, etc.), the client reports to the network management system and triggers an alarm.

[0070] In addition, considering the existence of old devices (not supporting TLV) in the present application, the old devices can ignore unknown TLV fields according to the IEEE1588 compatibility principle when receiving the TLV, without affecting the master clock synchronization process, thereby ensuring that the application can be deployed in a mixed device network.

[0071] As for the TLV length and performance, according to the maximum TLV length limit of IEEE1588, the Length field of the TLV can be up to 65535 bytes; in common deployment (only type + quantity statistical mode is used) the TLV length is very limited, even in the complete path recording mode using node ID (e.g. recording hundreds to thousands of nodes) is also within an acceptable range; the impact of TLV size on device processing delay and bandwidth should be evaluated and compromised when deploying.

[0072] The embodiment does not perform link-level encryption or signature on the TLV by default, in order to avoid negative impact on PTP real-time performance and accuracy; in scenarios with security requirements, integrated security mechanisms (such as ICV) specified in IEEE1588 standard or means such as IPSec at a higher layer (e.g. IP layer) can be used to enhance data integrity and tamper-proofing capability, and specific solutions can be disclosed as optional in the description embodiment.

[0073] The foregoing embodiments have described the PTP time service method provided in the present application in detail, and the following embodiments of the device provided in the present application are described in detail.

[0074] Referring to Figure 3 The present application provides an embodiment of a PTP time service device, which comprises: The field configuration unit 301 is configured to add a self-defined traceable additional field TLV in a PTP message conforming to the IEEE 1588 standard, the TLV satisfying an even number of byte alignment structure; the traceable additional field at least includes: a first field for representing a level of a time service clock source, a second field for representing an accuracy difference between a current clock and the time service clock source, the second field being accumulated at a link node by level, a third field for identifying a name of the time service clock source, a sixth field for respectively representing a type and a node number of a link through which the time service clock source passes to a current clock node and for representing identification information of each node in the link; The message generation unit 302 is configured to generate and encapsulate the PTP message carrying the TLV through a PTP server end; The message forwarding unit 303 is configured to forward the PTP message through an intermediate node and update the second field, the fourth field and the fifth field by level in the forwarding process; The message analysis unit 304 is configured to receive and analyze the PTP message through a PTP client to obtain the TLV; The credibility determination unit 305 is configured to determine a credibility degree and an expected accuracy of a received time based on the first field to the sixth field in the TLV through the PTP client.

[0075] Optionally, the rule that the second field is accumulated at the link node by level includes: When the link is a fiber time service link, a value of the second field is increased by 2 picoseconds on the basis of a previous node; When the link is a PTP time service link, the value of the second field is increased by 5 nanoseconds to 50 nanoseconds on the basis of the previous node; When the link is an NTP time service link, the value of the second field is increased by 10 microseconds to 1 millisecond on the basis of the previous node.

[0076] Optionally, the fourth field is used for representing a link type, and a value of the fourth field includes: 0x01: representing a fiber time service link; 0x02: representing a PTP link; 0x03: representing an NTP link; 0x04 to 0xFF: reserved values.

[0077] Optionally, the sixth field is composed of 8 bytes of clock identification, and when the fifth field is greater than zero, the sixth field records clock identifications of nodes in the link in turn.

[0078] Optionally, a value of the first field includes: Value 1: indicates an atomic clock group; Value 6: indicates an enhanced master reference clock or master reference clock normally tracking a satellite; Value 7: indicates an enhanced master reference clock or master reference clock in a satellite signal loss holdover state; Value 52: indicates an enhanced master reference clock or master reference clock in a free running state.

[0079] Optionally, the credibility determining unit 305 is specifically configured to: determine the level of the time service clock source and set a reference credibility based on the first field; calculate an expected accuracy of the current clock relative to the time service clock source based on the second field and the accuracy difference accumulated level by level by the nodes in the link; confirm the name information of the time service clock source based on the third field to perform verification on the uniqueness of the time service clock source; identify the link type and link depth between the time service clock source and the current clock based on the fourth field and the fifth field, and determine the influence degree of the structure of the link on the credibility degree; verify the clock identification of each intermediate node in the link based on the sixth field.

[0080] Optionally, the message forwarding unit 303 is specifically configured to: parse the last fourth field in the TLV to obtain a link type; when the link type is the same as the time service mechanism of the current node and is a PTP link, add 1 to the number of nodes in the corresponding fifth field; when the link type is inconsistent with the time service mechanism of the current node, add a fourth field to the TLV and set the link type to PTP, and initialize the number of nodes to 1 in the corresponding fifth field; estimate the accuracy loss value caused by the current node and accumulate the accuracy loss value in the second field.

[0081] Optionally, the field configuring unit 301 is specifically configured to: define a traceability additional field based on the TLV structure specified in the PTP protocol; set the traceability additional field to an even byte-aligned storage format; encapsulate the traceability additional field at the end of the PTP announce message.

[0082] Please refer to Figure 4 The application further provides a PTP time service device, comprising: The processor 401, the memory 402, the input and output unit 403, and the bus 404 are connected. The processor 401 is connected with the memory 402, the input and output unit 403, and the bus 404. The memory 402 stores a program, and the processor 401 invokes the program to execute any of the above methods.

[0083] The application also relates to a computer readable storage medium, which stores a program, and when the program runs on a computer, the computer executes any of the above methods.

[0084] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the above-described system, device and unit can refer to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0085] In the several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented by other ways. For example, the device embodiments described above are only schematic, and for the convenience of description, the division of the units is only a logical function division, and there can be another division way in actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection between the units can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0086] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. According to actual needs, part or all of the units can be selected to achieve the purpose of the embodiment scheme.

[0087] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0088] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

Claims

1. A PTP time transfer method, characterized by, The method comprises: adding a custom traceable additional field TLV in a PTP message conforming to the IEEE 1588 standard, the TLV satisfying an even byte alignment structure; the traceable additional field comprising at least: a first field for representing a level of a time service clock source, a second field for representing an accuracy difference between a current clock and the time service clock source, the second field being accumulated step by step at a link node, a third field for identifying a name of the time service clock source, a sixth field for respectively representing a type and a node number of a link through which the time service clock source passes to a current clock node and for representing identification information of each node in the link; generating and encapsulating, by a PTP server, a PTP message carrying the TLV; forwarding, by an intermediate node, the PTP message and updating the second field, the fourth field and the fifth field step by step in the forwarding process; receiving and analyzing, by a PTP client, the PTP message to obtain the TLV; determining, by the PTP client, a trust degree and an expected accuracy of a received time based on the first field to the sixth field in the TLV.

2. The PTP time transfer method as claimed in claim 1, wherein, The rule that the second field is accumulated step by step at a link node comprises: when the link is a fiber time service link, the value of the second field is increased by 2 picoseconds on the basis of a previous node; when the link is a PTP time service link, the value of the second field is increased by 5 nanoseconds to 50 nanoseconds on the basis of a previous node; when the link is an NTP time service link, the value of the second field is increased by 10 microseconds to 1 millisecond on the basis of a previous node.

3. The PTP time transfer method as recited in claim 1, wherein, The fourth field is used for representing a link type, and the value of the fourth field comprises: 0x01: representing a fiber time service link; 0x02: representing a PTP link; 0x03: representing an NTP link; 0x04 to 0xFF: reserved values.

4. The PTP time transfer method as recited in claim 1, wherein, The sixth field is composed of 8 bytes of clock identification, and when the fifth field is greater than zero, the sixth field records clock identifications of nodes in the link in turn.

5. The PTP time transfer method as recited in claim 1, wherein, The value of the first field comprises: a value of 1: representing an atomic clock group; a value of 6: representing an enhanced master reference clock or a master reference clock normally tracking a satellite; a value of 7: representing an enhanced master reference clock or a master reference clock in a satellite signal loss holding state; a value of 52: representing an enhanced master reference clock or a master reference clock in a free running state.

6. The PTP time transfer method as recited in claim 1, wherein, The determination of a trust degree and an expected accuracy of a received time based on the first field to the sixth field in the TLV comprises: based on the first field, determining a level of the time service clock source and setting a reference trust degree; based on the second field, calculating an expected accuracy of a current clock relative to the time service clock source in combination with accuracy differences accumulated step by step at nodes in the link; based on the third field, confirming name information of the time service clock source to perform verification on uniqueness of the time service clock source; identifying a link type and a link depth between the time service clock source and the current clock based on the fourth field and the fifth field, so as to determine an influence degree of a structure of the link on a trust degree; verifying a clock identification of each intermediate node in the link based on the sixth field.

7. The PTP time transfer method as recited in claim 1, wherein, forwarding the PTP message through an intermediate node, and updating the second field, the fourth field and the fifth field step by step in the forwarding process, comprising: parsing a last fourth field in the TLV to obtain a link type; when the link type is the same as a time service mechanism of a current node and is a PTP link, adding 1 to a node number in a corresponding fifth field; when the link type is not the same as the time service mechanism of the current node, adding a new fourth field in the TLV and setting the link type as PTP, and initializing the node number as 1 in the corresponding fifth field; estimating a precision loss value caused by the current node, and accumulating the precision loss value in the second field.

8. The PTP time transfer method as recited in claim 1, wherein, the PTP message complying with the IEEE 1588 standard, comprising: defining a traceable additional field based on a TLV structure specified by the PTP protocol; setting the traceable additional field as an even byte alignment storage format; encapsulating the traceable additional field at the end of a PTP announce message.

9. A PTP time serving device, characterized by the apparatus, comprising: a field configuration unit configured to add a self-defined traceable additional field TLV in a PTP message complying with the IEEE 1588 standard, the TLV satisfying an even byte alignment structure; the traceable additional field comprising at least a first field for representing a level of a time service clock source, a second field for representing a precision difference between a current clock and the time service clock source, the second field being accumulated step by step at a link node, a third field for representing a name of the time service clock source, a sixth field for representing identification information of each node in a link through which the time service clock source passes to the current clock node, and a fifth field for representing a type and a node number of the link; a message generation unit configured to generate and encapsulate a PTP message carrying the TLV through a PTP server end; a message forwarding unit configured to forward the PTP message through an intermediate node, and update the second field, the fourth field and the fifth field step by step in the forwarding process; a message parsing unit configured to receive and parse the PTP message through a PTP client end to obtain the TLV; a trust degree determination unit configured to determine a trust degree and an expected precision of a received time through the PTP client end based on the first field to the sixth field in the TLV.

10. A PTP time serving device, characterized by the apparatus, comprising: a processor, a memory, an input output unit and a bus; the processor is connected with the memory, the input output unit and the bus; the memory stores a program, and the processor invokes the program to execute the method in any one of claims 1 to 8.

11. A computer readable storage medium, characterized in that, The computer readable storage medium has a program saved thereon, and the program performs the method according to any one of claims 1 to 8 when executed on a computer.