Efficient and precise time synchronization method and system

Abstract

This invention provides a time synchronization method that reduces the number of PTP message transmissions. [Solution] In a messaging process in which a coordinator transmits a Sync message to one or more followers, the followers transmit a Delay_Req message to the coordinator in response, and the coordinator, upon receiving this, transmits a Delay_Resp message to the followers, the delay and offset are determined and time synchronization is performed based on these. However, in this invention, even if multiple followers are linked, the number of PTP message transmissions is reduced by broadcasting the coordinator's Sync message and / or Delay_Resp message at once. Another aspect of this invention is that the transmission bandwidth occupied by PTP messages is reduced by performing PTP messaging using symbols that are much shorter than the length of each conventional PTP message.

Description

[Technical Field]

[0001] This invention relates to a method and system for synchronizing time between a coordinator and a follower on a network. [Background technology]

[0002] Precise time synchronization between collaborating devices is essential in diverse fields such as broadcasting, communications, power grids, automation systems, and financial trading systems, and methods include GPS, IRIG-B, NTP, IEEE 802.1AS, and PTP (IEEE 1588).

[0003] Among these, PTP is widely used as a method to support accurate and secure time synchronization for devices on computer networks, especially Ethernet networks. It works by exchanging Sync, Follow_Up, Delay_Req, and Delay_Resp messages between master and slave devices on the network, calculating the time difference (offset) between the master and slave devices, and thereby achieving time synchronization between each device.

[0004] While the PTP method does not burden the network when there are only a few devices to synchronize, in cases where dozens to hundreds of devices must synchronize their time on a single network, such as in a vehicle network, a large number of time synchronization messages are generated, leading to a problem of consuming a large amount of bandwidth necessary for the actual data transmission between devices. The bandwidth occupied by time synchronization messages increases as the number of devices performing time synchronization using PTP in the network increases. Taking vehicle networks as an example, the increasing degree of automotive electrification means that the number of devices included in the network is increasing, and the effective bandwidth is becoming increasingly smaller due to PTP messages.

[0005] As an example, in the case of 10BASE-T1S, which has emerged as an alternative to in-vehicle networks, the transmission bandwidth is 10 Mb / s, which is a very high data transmission rate compared to existing in-vehicle networks. However, it can be affected by PTP messages, and in a network structure where multiple terminals share the bus using a multi-drop method, if a large number of control messages such as PTP messages are generated, the actual data transmission rate can drop sharply. [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] To solve the aforementioned problems, the present invention aims to provide a time synchronization method and system that can minimize the reduction in effective bandwidth caused by time synchronization in existing PTP methods.

[0007] Furthermore, the aim is to provide a time synchronization method and system with even higher accuracy compared to the conventional PTP method. [Means for solving the problem]

[0008] One aspect of the present invention discloses a method and system for improving the efficiency of PTP messaging by reducing the number of PTP message transmissions compared to the conventional PTP method. When a coordinator and one or more followers are connected on a network, in order to synchronize the followers in time with the coordinator's clock, the coordinator transmits a Sync message to one or more followers, the followers transmit a Delay_Req message to the coordinator in response, and the coordinator, upon receiving this, transmits a Delay_Resp message to the followers, thereby determining the delay and offset through a messaging process and performing time synchronization based on these. However, in the present invention, even when multiple followers are connected, the number of PTP message transmissions is reduced by broadcasting the coordinator's Sync message and / or Delay_Resp message at once.

[0009] Another aspect of the present invention reduces the transmission bandwidth occupied by PTP messages by performing PTP messaging using symbols that are much shorter than the length of each conventional PTP message.

[0010] In yet another aspect of the present invention, the user can flexibly edit and configure symbols that have been coded and converted from data. Most network standards have fixed control symbols defined by block coding such as 4B5B, 5B6B, and 8B10B, but the present invention provides a method and system that allows the user to freely edit and configure the block coding scheme. [Effects of the Invention]

[0011] According to the present invention, time synchronization between devices on a network connecting two or more devices can be efficiently performed, minimizing the consumption of transmission bandwidth on the network and increasing the data transmission rate.

[0012] By using symbols much shorter than those in conventional PTP messages to perform offset calculations for time synchronization, more precise time synchronization is possible.

[0013] The objectives and effects of the present invention are not limited to those mentioned above, and other effects not mentioned can be clearly understood by those skilled in the art from the following description. [Brief explanation of the drawing]

[0014] [Figure 1] This is a diagram illustrating the conventional PTP procedure. [Figure 2] This is a diagram illustrating the PTP messaging procedure in an Ethernet switch-based network according to a preferred embodiment 1 of the present invention. [Figure 3] This diagram illustrates the flow of the traditional PTP procedure on a network where one coordinator and multiple followers are connected. [Figure 4]This diagram illustrates the flow of the PTP procedure according to preferred embodiment 2 of the present invention on a network in which one coordinator and multiple followers are connected. [Figure 5] This diagram illustrates the flow of a modified PTP procedure, as shown in the example in Figure 4, on a network where one coordinator and multiple followers are connected. [Figure 6] This is a diagram illustrating the format of the conventional Delay_Resp message. [Figure 7] This is a diagram illustrating the Delay_Resp message format according to the present invention. [Figure 8] Figure 5 is a diagram illustrating the exceptional circumstances of Example 2. [Figure 9] This diagram illustrates the Delay_Resp message format that takes into account the exception handling shown in Figure 8, according to the present invention. [Figure 10] Figure 9 is a diagram illustrating a partially modified Delay_Resp message format. [Figure 11] This is a diagram illustrating the PTP messaging procedure according to Embodiment 3 of the present invention, in which the master and coordinator are the same person. [Figure 12] This is a diagram illustrating the PTP messaging procedure according to Embodiment 3 of the present invention, in which the master and coordinator are different. [Figure 13] This is a diagram illustrating the configuration of the PTP coordinator according to the present invention. [Figure 14] This is a diagram illustrating the configuration of the PTP follower according to the present invention. [Figure 15] This is a block diagram illustrating the variable block coding configuration according to the present invention. [Figure 16A] This is a block diagram illustrating the composite variable block coding configuration according to the present invention. [Figure 16B]This is a block diagram illustrating the composite variable block coding configuration according to the present invention. [Modes for carrying out the invention]

[0015] The advantages and features of the present invention, and how to achieve them, will become clearer with reference to the embodiments described below in detail with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and can be embodied in a variety of different forms, although these embodiments are provided to complete the disclosure of the present invention and to fully inform a person ordinary in the art to which the present invention belongs of the scope of the invention, and the present invention is defined only by the scope of the claims.

[0016] The terms used herein are for illustrative purposes only and are not intended to limit the invention. In this specification, singular nouns include plural nouns unless otherwise specified. The terms “comprises” and / or “comprising” used in this specification do not exclude the existence or addition of one or more other components in addition to the components mentioned. The same reference numerals throughout this specification refer to the same components, and “and / or” include each of the components mentioned and all combinations of one or more of them. Although terms such as “first,” “second,” etc., are used to describe a variety of components, these components are not limited by these terms. These terms are simply used to distinguish one component from another. Therefore, the first component mentioned below may, of course, be the second component within the technical concept of the invention.

[0017] Unless otherwise defined, all terms used herein (including technical and scientific terms) should be used in a sense that can be commonly understood by a person of ordinary skill in the art to which this invention pertains. Furthermore, terms defined in commonly used dictionaries should not be interpreted in a manner deviating from their dictionary meaning unless explicitly defined otherwise. In this description, the same number refers to substantially the same element, and under these rules, many drawings may be used for explanation, with omissions made of information that would be obvious to a person skilled in the art or that would be repeated.

[0018] On the other hand, the network master and the master in the PTP procedure may be the same device or different devices. To avoid confusion, in the following, the master in the PTP procedure will be referred to as the coordinator, and other devices collaborating in the PTP procedure will be referred to as followers.

[0019] A technical feature of one embodiment of the present invention is that, in performing time synchronization between devices on a network, it reduces the number of conventional PTP messages or the length of the messages to improve the data transmission efficiency of the network.

[0020] In this case, there are various possible embodiments, and the representative types of preferred embodiments according to the present invention are summarized below.

[0021] 1. An efficient time synchronization method and system in a point-to-point connection structure (e.g., star topology) connected by Ethernet switches.

[0022] 2. An efficient time synchronization method and system for a coordinator and one or more followers on a multi-drop network.

[0023] 3. An efficient time synchronization method and system for standard networks such as 10BASE-T1S or 10BASE-T1L.

[0024] 4. A method and apparatus for converting or editing a symbol table so that PTP messages can be represented by 5-bit or 10-bit symbols instead of long network frames (for example, the minimum length of an Ethernet frame is 64 bytes = 512 bits).

[0025] After briefly describing existing PTP methods with reference to the attached drawings, the technical concept of the present invention and the various configurations that can be derived within this scope will be specifically explained through preferred embodiments of the present invention.

[0026] Figure 1 is a diagram illustrating the time synchronization protocol and offset calculation method between a coordinator and follower using the conventional PTP method as defined in the IEEE standard.

[0027] As illustrated, (1) the coordinator transmits a Sync message to the follower at time t1. The Sync message reaches the follower at time t2 after a transmission delay over the network. At this time, the follower confirms that it received the Sync message at time t2. (2) The coordinator transmits a Follow_up message to the follower to provide the exact transmission time t1 of the Sync message, and the follower can know t1 through this. (3) At time t3, the follower transmits a Delay_Req message to the coordinator, which is a request to measure the transmission delay. (4) In response to the Delay_Req message, the coordinator sends a Delay_Resp message to the follower, which includes the time t4 when it received the Delay_Req message.

[0028] After going through the aforementioned series of procedures, the follower can know all the times (t1, t2, t3, and t4), and can know the delay (transmission delay) and offset (time difference between the coordinator clock and the follower clock) through equation (1) below.

[0029]

number

[0030]

[0031]

number

[0032]

[0033] In other words, in the PTP method, the transmission delay and offset are calculated by the follower, and the follower, having grasped the offset which is the time difference between the coordinator clock (the clock of the coordinator device) and its own follower clock, synchronizes with the coordinator clock based on this.

[0034] However, when using the conventional PTP method with Ethernet, each message uses an Ethernet frame (UPD packet) of at least 64 bytes (512 bits), so if there are many slave devices to synchronize, a considerable amount of network transmission bandwidth loss can occur.

[0035] Therefore, the present invention presents a configuration that increases the data transmission rate by shortening the length of the PTP message.

[0036] Furthermore, in existing PTP standards, the coordinator transmits a Follow_up message to the follower to provide the exact transmission time t1 of the Sync message. However, if t1 is provided to the follower by another message (for example, if the Sync message includes t1 or the Delay_Resp message includes t1 and provides it to the follower), then PTP can be implemented with three messages without using the Follow-up message. Therefore, in the embodiment of the present invention, PTP is implemented using three messages: a Sync message, a Delay_Req message, and a Delay_Resp message.

[0037] <Example 1>

[0038] Example 1 is an embodiment of PTP in a point-to-point connected network. This embodiment can be adopted, for example, in a star topology network where Ethernet switches are connected one-to-one with each terminal (Network terminal).

[0039] As mentioned earlier, instead of using Follow-up messages, the Delay_Resp message includes not only t4 but also t1 information to reduce the number of messages used for PTP time synchronization.

[0040] In addition, the amount of PTP messages can be significantly reduced by using short-length symbols such as 5-bit or 10-bit symbols instead of long messages like Ethernet frames (for example, Ethernet frames are at least 64 bytes) in PTP messages.

[0041] To enhance understanding, a basic explanation of the symbols used in this invention will be given first, followed by a description of the PTP sequence in Example 1.

[0042] Communication systems such as Ethernet and FDDI primarily use 4B5B block coding. That is, 4-bit information is encoded into 5 bits and transmitted over the transmission line.

[0043] The basic reason for block coding is to prevent three or more consecutive "0"s (zeros) from appearing in the transmission signal. If consecutive "0"s are transmitted without a transition to "1", the receiving end will receive an unclear signal. In this way, 4-bit data is converted into a 5-bit code and output to the transmission line. An example of 4B5B conversion is shown in Table 1 below.

[0044] [Table 1]

[0045] As illustrated in the code groups in Table 1, appropriately arranging 1s and 0s is advantageous for maintaining clock synchronization. Using only a portion of the 5-bit code as a valid code makes it easier to detect or prevent data transmission errors. Furthermore, even if the signal is illegally intercepted on the transmission line, the true value of the transmitted data cannot be determined without knowing the conversion rules, thus offering security advantages. In other words, it is possible to maintain the DC balance and quality of the transmitted signal and improve the reliability of data transmission.

[0046] In communication systems such as 10BASE-T1S and 10BASE-T1L, all or part of the 5-bit conversion code is used as specific control codes ( / N / : symbol for beacon signal; / J / : Sync symbol for Commit or the first preamble byte of the Ethernet frame; / H / : Sync symbol for the second preamble byte of the Ethernet frame as a Start-of-Stream Delimiter; / T / : End-of-Stream Delimiter, etc.) as shown in Table 2 below, and these are referred to as symbols.

[0047] In this invention, specific values ​​within a 5-bit code are used as some of the PTP messages (Sync messages and / or Delay_Req messages), and are referred to as symbols in this specification. These will be explained in more detail in relation to Example 4, which will be described later.

[0048] The PTP sequence of Example 1 will be described in detail below.

[0049] As illustrated in Figure 2, the coordinator sends a Sync message to the follower at time t1, relative to its own clock. At this time, the Sync message is one of a predetermined 5-bit symbol and does not include time information such as t1.

[0050] A follower that receives a Sync message stores the time t2, which is the time the Sync message was received, based on its own clock.

[0051] The follower then sends Delay_Req to the coordinator at t3, which is the transmission time based on its own clock. Delay_Req is one of the predetermined 5-bit symbols.

[0052] A follower who receives a Sync message and sends a Delay_Req can access and save the t2 and t3 information.

[0053] Upon receiving Delay_Req, the coordinator saves the reception time t4 relative to its own clock.

[0054] Subsequently, the coordinator sends a Delay_Resp message containing t1 and t4 to the follower. Since the time information t1 and t4 must be transmitted, it is preferable for the Delay_Resp message to use an Ethernet frame.

[0055] A follower that receives Delay_Resp can know all the time information, t2 and t3, which are based on its own clock, and t1 and t4, which are based on the coordinator's clock. Using equations (1) and (2), it can calculate the offset and perform time synchronization to match the coordinator's clock.

[0056] In Example 1, the transmission amount required for a conventional PTP message was 64 bytes × 4 = 2,048 bits, but in Example 1, only 5 bits × 2 + 64 bytes × 1 = 522 bits are required. In other words, time synchronization can be achieved using only 25.5% of the transmission amount of a conventional PTP message.

[0057] On the other hand, while the examples above assumed a 1:1 relationship between coordinators and followers, the aforementioned method can be extended and applied to 1:N cases, such as a star topology where multiple followers are connected around an Ethernet switch.

[0058] As the number of participating followers increases, the savings in message transmission volume through PTP message transmission over the network become even greater.

[0059] <Example 2>

[0060] Example 2 reduces PTP messages to improve transmission efficiency and may be particularly effective when one coordinator and multiple followers are connected on the network using a multidrop method.

[0061] First, referring to Figure 3, we will explain the inefficiencies of the conventional PTP method when used in a multi-drop network with multiple followers.

[0062] As illustrated in Figure 3, when three coordinators and their followers (Follow a, Follow b, Follow c) perform time synchronization, even if only three PTP messages are used, the PTP coordinator must send the Sync message three times, and each follower (Follow a, Follow b, Follow c) must send a Delay Req message and receive a Delay_Resp from the PTP coordinator. This results in a total of nine message transmissions (3 messages x 3 followers), occupying at least 4,608 bits (512 bits x 9) of transmission bandwidth. Furthermore, since time synchronization must be performed periodically, it may affect the actual data transmission in a 10 Mbps bandwidth.

[0063] Therefore, in Example 2, we focus on the fact that PTP time synchronization can be performed if the follower can confirm the aforementioned time information (t1, t2, t3, and t4). We present a method to minimize network transmission bandwidth loss by providing a technique that allows the follower to confirm the aforementioned time information (t1, t2, t3, and t4) even if the number of PTP messages is reduced.

[0064] Example 2 has three sub-examples, illustrating a case where a coordinator and three PTP followers participate in the network. Example 2 uses Ethernet frames and other frames for sending and receiving actual data instead of symbols in PTP messages, thereby reducing the number of PTP messages and improving the efficiency of actual data transmission.

[0065] <Example 2-1>

[0066] The core concept of Example 2-1 is that the coordinator broadcasts Sync messages to reduce the number of Sync messages, as illustrated in Figure 4.

[0067] For example, in various multi-drop local networks such as 10BASE-T1S, 10BASE-T1L, and Zigbee, the network master broadcasts beacons to schedule transmission.

[0068] In this way, by having the PTP coordinator broadcast the Sync message and having each follower receive it, the number of Sync messages can be reduced from three to one. In Example 2-1, each PTP message is transmitted using an Ethernet frame instead of a symbol, and includes time information (t1, t4, etc.).

[0069] When comparing the number of messages in a 10BASE-T1S environment (where a total of 8 terminals share one bus), conventionally, Sync, Delay_Req, and Delay_Resp must be exchanged with 7 Follows, resulting in 21 messages being sent and received. However, the improved message efficiency of the first embodiment broadcasts one Sync message to all followers, resulting in a total of 15 messages: Sync (1) + Delay_Req (7) + Delay_Resp (7).

[0070] It is possible to achieve time synchronization with only 71.43% of the transmission bandwidth occupied by the conventional method for time synchronization.

[0071] <Example 2-2>

[0072] Example 2-2 is a method of also broadcasting the Delay_Resp message to reduce the number of Delay_Resp messages.

[0073] As shown in FIG. 5, the specific protocol is as follows.

[0074] 1) The coordinator sends a Sync message at time t1. The Sync message may include transmission time information (t1).

[0075] 2) The transmission by the coordinator is broadcast to all followers (Follower a, Follower b, Follower c) in the network, and after respective transmission delays according to the distances of the terminals, each time (t

[0076] , b , c , a , b , a , , c , , a , b , c , b 2, t b 2, t c 2) is received. At this point, each follower (Follower a, Follower b, Follower c) can confirm the transmission time information (t1) included in the Sync message and each reception time information (t a 2, t b 2, or t c 2) and save it.

[0076] 3) Each follower (Follower a, Follower b, Follower c) that has received the Sync message sends a Delay_Req message at its respective time (t a 3, t b 3, or t c 3). Each follower (Follower a, Follower b, Follower c) uses the respective times (t a 3, t b 3, or tc 3) We can learn this and save it.

[0077] 4) Each follower (Follower a, Follower b, Follower c) sends a Delay_Req message, and each time (t) is sent after the respective transmission delay due to distance. a 4, t b 4, t c 4) It reaches the coordinator at time (t a 4, t b 4, t c 4) Confirm this and save it.

[0078] As mentioned earlier, all nodes connected to the network, including the coordinator, know the transmission order of each node in advance. Therefore, the coordinator can determine which follower sent which Delay_Req message based on the order in which the Delay_Req messages are received.

[0079] After completing the procedures described in 1) to 4) above, the coordinator records the time the Sync message was sent (t1) and the time the three Delay_Req messages were received (t a 4, t b 4, t c 4) Knowing the time the Sync message was sent (t1) and the time they themselves received the Sync message (t) included in the Sync message, each follower knows this, and each follower knows the time the Sync message was sent (t1) and the time they received the Sync message (t a 2, t b 2, or t c 2) and each time they sent the Delay_Req message (t a 3, t b 3, or t c I know 3).

[0080] Therefore, each follower receives the Sync message from the coordinator at the time (t1) and the Delay_Req message at the time (t1). a 4, t b 4, t c Upon receiving (4), the offset and delay can be calculated using the PTP method.

[0081] Therefore, 5) when the coordinator receives a Delay_Req message from each follower (Follower a, Follower b, Follower c), it receives the time information (t a 4, t b 4 and t c Broadcast a single Delay_Resp message containing 4).

[0082] 6) Each follower that receives the Delay_Resp message broadcast from the coordinator will receive the time information (t a 4, t b 4, t c 4) From this, the offset, which is the difference between its own clock and the master clock, and the delay, which is the transmission delay, can be calculated, and time synchronization can be performed using the coordinator clock as the reference.

[0083] However, to use a method like that in Example 2-2, improvements are needed to allow multiple time information to be input into the Delay_Resp message. As shown in Figure 6, the conventional Delay_Resp message format sends a 1:1 response to each follower's Delay_Req message, and therefore does not take into account the transmission of reception time information for multiple Delay Req messages together.

[0084] The coordinator adds Delay_Resp message with Delay_Req message-specific reception time information (t a 4, t b 4, t c 4) In order to transmit including this, first, the time information (t) of when each Delay_Req message was received must be included. a 4, t b 4, t c4) must be saved. One of many possible methods is for the coordinator, upon receiving a Delay_Req, to ​​read and save the timestamp of the Delay_Req message, which is stored in, for example, an IEEE 1588 PHY Transceiver. The coordinator then manages and stores the Delay_Req reception time information for each follower in a way that allows for individual differentiation.

[0085] In a multidrop network, the transmission order of participating terminals is often predetermined, so in one embodiment, it is assumed that the transmission order of each node, including the coordinator and multiple followers, is predetermined.

[0086] In one embodiment, it is assumed that all network nodes know the transmission order of each follower in advance, such as follower a → follower b → follower c. In such a case, all nodes know which follower or coordinator is the transmitting entity at a particular point in time. Therefore, even if each Delay_Req message does not have an identifier for the transmitting entity (follower), the coordinator can determine which follower sent the Delay_Req message based on the arrival order of the Delay_Req messages.

[0087] When Delay_Req is received from all followers, the coordinator sends Delay_Resp the reception time information for all Delay_Req (t a 4, t b 4 and t c 4) Insert and broadcast.

[0088] On the other hand, each follower (Follower a, Follower b, Follower c) receives the time information (t) contained in the Delay_Resp message. a 4, t b 4, t c4) It must be possible to distinguish which of these is the reception time of the Delay_Req that it sent. Therefore, the coordinator must include the reception time (t) of each Delay_Req message in the Delay_Resp message. a 4, t b 4, t c 4) When broadcasting, include each reception time (t a 4, t b 4, t c 4) Save and transmit the data in the predetermined transmission order for each follower.

[0089] Figure 6 illustrates the conventional Delay_Resp message format, and Figure 7 illustrates the Delay_Resp message format according to the present invention. Figure 7 shows the reception time (t) of the Delay_Req message to the coordinator in the transmission order of each follower. a 4, t b 4, t c 4) is shown to be included.

[0090] Each follower that receives a Delay_Resp message in the format shown in Figure 7 can check the time the coordinator received the Delay_Req message it sent, based on its own transmission order.

[0091] As a modified example, each follower can transmit a Delay_Req message containing its identifier. In such a case, the coordinator can determine the transmission order of the followers or distinguish which follower transmitted the message by checking the identifier. The coordinator stores the identifier of the follower that sent the Delay_Req message along with the timestamp it stores, and broadcasts the Delay_Resp message containing both the reception time and identifier of each Delay_Req message.

[0092] Each follower that receives a broadcasted Delay_Resp message will use the included identifier to determine the time (t) when it received the Delay_Req message it transmitted. a 4, t b 4, or t c 4) can be confirmed.

[0093] In Example 2-2, the PTP coordinator does not need to send a separate Sync message and Delay_Resp message for each follower, thus saving bandwidth on Sync and Delay_Resp message transmission.

[0094] Taking a 10BASE-T1S environment (where a total of 8 terminals share one bus) as an example, when comparing the number of PTP messages in the conventional method and Example 2-2, the conventional method requires exchanging Sync messages, Delay_Req messages, and Delay_Resp messages with 7 Followers, resulting in 21 messages being sent and received. However, in the improved Example 2-2, one Sync message and one Delay_Req message are broadcast to all Followers, so the total number of messages becomes Sync (1) + Delay_Req (7) + Delay_Resp (1) = 9.

[0095] The configuration of Example 2-2 allows time synchronization using only 38.1% of the transmission bandwidth occupied by PTP messages for time synchronization in the conventional method.

[0096] <Example 2-3>

[0097] Figure 8 is a diagram illustrating the exceptional situation in Example 2.

[0098] The coordinator must receive Delay_Req messages from all followers, but it cannot wait indefinitely, so it is configured to wait for Delay_Req messages for a predetermined period of time. Therefore, if no Delay_Req message arrives within the predetermined period, this is considered an exceptional situation, and a handling procedure is required. In this case, the reception time information (t4) of the Delay_req message from the relevant follower must be excluded in the Delay_Resp message, but as can be seen in Figure 6, the conventional Delay_Resp message format sends a 1:1 response to each Delay_Req message from each follower, so this consideration is not taken into account.

[0099] As shown in Figure 7, the Delay_Resp message in the second embodiment of the present invention contains the reception time information of Delay_Req sent by multiple followers. Therefore, a method is needed to identify the owner of receiveTimestamp(t4) (the follower who sent the Delay_Req message). Embodiments 2-3 are embodiments relating to such exception handling.

[0100] Two approaches are possible. First, an identifier for the follower who sent the Delay_req message (i.e., the owner of receiveTimestamp) can be added to the Delay_Resp message. In this case, if follower b, as in Figure 8, was unable to send the Delay_Req message, or if follower b sent the Delay_Req message but the coordinator could not receive it, the time information for follower b can be omitted from the Delay_Resp message (see Figure 9).

[0101] Secondly, there is a method of indicating followers in a predetermined fixed order. That is, if the transmission order of all nodes or all followers on the network is predetermined, the arrival time information (t4) of the Delay_Req message is included in the Delay_Resp message according to that order. However, if the exceptional situation in Figure 8 occurs, a Delay_Resp message with meaningless values ​​(e.g., zero padding) is broadcast for followers that are presumed not to have sent a Delay_Req message (follower b in Figure 8) (see Figure 10).

[0102] In this case, follower b, which is presumed to have experienced a problem, cannot obtain t4 time information even if it receives a Delay_Resp message, and therefore cannot perform delay and offset calculations, thus preventing time synchronization. However, followers a and c, which receive the broadcasted Delay_Resp message, will calculate the delay and offset to synchronize their time.

[0103] In other words, through the exception handling method of Example 2-3, even if some followers on the network are in a failure state, the overall time synchronization of the network can be performed without affecting the time synchronization of other followers.

[0104] <Example 3>

[0105] Example 3 is a method that can most efficiently implement PTP messaging in a multidrop network with one coordinator and multiple followers. This method not only reduces the number of PTP messages but also significantly reduces the amount of data transmitted for PTP messaging by using 5-bit or 10-bit symbols instead of long frames like Ethernet frames.

[0106] Hereinafter, an embodiment 3 in accordance with the technical concept of the present invention will be described with reference to Figures 11 and 12. For the sake of understanding and ease of explanation, the example will be mainly described in relation to a 10BASE-T1S network, but it is of course possible to apply the invention to other networks with some modifications and changes within the scope of the technical concept of the present invention.

[0107] On the other hand, a 10BASE-T1S network can have up to eight terminals participating, and one master device coordinates the communication of the other devices. The master device periodically sends beacon signals, similar to Zigbee, to adjust the communication time between devices in the network and prevent data collisions. However, the network master and the PTP procedure master may be the same device or different devices. To avoid confusion, when explaining the PTP procedure, the device that sends the Sync message will be referred to as the PTP coordinator, and the other devices will be referred to as followers, as in the explanations of Examples 1 and 2. However, the names of the PTP messages in Example 3 will be distinguished from Examples 1 and 2, such as PTP-Sync, PTP-Req, and PTP-Resp.

[0108] The basic idea behind Example 3 is to avoid transmitting PTP messages through Ethernet UDP packets of at least 64 bytes, and instead utilize DME block coding symbols consisting of 5 bits.

[0109] The symbol table for the 10BASE-T1S standard is shown in Table 1 below.

[0110] [Table 2]

[0111] Each symbol consists of 5 bits and is transmitted for 400 ns, but it can be distinguished from the actual data by consisting of 5 bits that do not appear in the actual data. The description of each symbol is as follows:

[0112] / I / : A symbol transmitted in the idle state. The PCS hierarchy continuously transmits the Silence Code ( / I / ). When this symbol is received, in the case of multidrop, the lower PMA transmitter sets the PMD output to a high impedance state to deactivate its own transmission function. In the case of point-to-point, the PMA outputs a 0V level signal.

[0113] / N / : Used for beacon signals and transmitted by node 0. One beacon signal consists of 5 / N / symbols and is transmitted between 2 usec.

[0114] / J / : A Sync symbol for the first preamble byte of a Commit or Ethernet frame.

[0115] / H / is a Start-of-Stream Delimiter (SSD) used as a Sync symbol for the second preamble byte of an Ethernet frame.

[0116] / T / stands for End-of-Stream Delimiter (ESD) and is used as the first symbol to indicate the end of an Ethernet frame. It is also used during heartbeat signal transmission.

[0117] / R / : End-of-Stream Delimiter OK (ESDOK) is used as the second symbol to indicate the end of an Ethernet frame. It is also used as the ESDBRS symbol to indicate the end of a unit frame within a burst during burst transmission.

[0118] / K / : End-of-Stream Delimiter Error (ESDERR) is used as the second symbol to indicate the end of an Ethernet frame, corresponding to the TXERR signal.

[0119] / S / : This is for ESD Jabber symbols. If the PCS function unit continues transmission work (2 msec) exceeding the maximum transmission time during the transmission process, it will determine that a failure has occurred in its own transmission unit, stop transmission, and then notify the receiver that there is a problem with this frame by sending an ESD / ESDJAB symbol.

[0120] The parts highlighted in yellow in the 5B Code column of the symbol table are codes that have not yet been defined as symbols that perform a specific function and are therefore reserved.

[0121] In Example 3, two of these reserved regions are used as PTP-Sync and PTP-Req. In the example in Table 2, code 01100 is used as the PTP-Sync symbol and code 00101 is used as PTP-Req.

[0122] By doing so, the length of each PTP message can be significantly reduced, and therefore the transmission bandwidth occupied by PTP messaging for network time synchronization can be reduced.

[0123] In addition to the above, this invention presents a method that can reduce the number of PTP messages transmitted, thereby reducing the bandwidth occupied by PTP messaging.

[0124] With reference to Figure 11, Embodiment 3-1 of the present invention will be described. Figure 11 illustrates a case where the 10BASE-T1S master and PTP coordinator are the same and there are three followers.

[0125] The specific protocol is as follows:

[0126] 1) The coordinator sends a PTP-Sync message at time t1. In Example 3-1 of Figure 11, the 10BASE-T1S master and the PTP coordinator are the same, so the beacon signal itself can be used as the PTP-Sync message. Alternatively, a symbol defined as the PTP-Sync message can be sent immediately after the beacon is transmitted.

[0127] 2) The coordinator's transmission is broadcast to all followers in the network (Follower a, Follower b, Follower c), and after the respective transmission delay due to the distance of the terminals, at each time (t a 2, t b 2, t c 2) It is received. At this point, the coordinator tells each follower (Follower a, Follower b, Follower c) the time (t) each time a PTP-Sync message arrives for them. a 2, t b 2, or t c 2) Confirm this and save it.

[0128] 3) Each follower (Follower a, Follower b, Follower c) that receives a PTP-Sync message will receive a message at their respective time (t a 3, t b 3, or t c 3) Send a PTP-Req message. Each follower (Follower a, Follower b, Follower c) will record the time (t) at which they sent their PTP-Req message. a 3, t b 3, or t c 3) We can learn this and save it.

[0129] In 10BASE-T1S, since all nodes know the transmission order of participating nodes, even if no identifier for identifying the transmitted follower is added to the PTP-Req message, the coordinator can distinguish which follower sent the PTP-Req message based on the arrival order of the PTP-Req message.

[0130] 4) The PTP-Req messages sent by each follower (Follower a, Follower b, Follower c) reach the coordinator at each time (t a 4, t b 4, t<9>00000754) after respective transmission delays due to distance. The coordinator can confirm the time (t a 4, t b 4, t c 4) and save it.

[0131] After the procedures of 1) to 4) above, the coordinator knows the PTP-Sync message transmission time (t1) and the times (t a 4, t b 4, t c 4) when receiving the three PTP-Req messages, and each follower knows the times (t a 2, t b 2, or t c 2) when they receive the PTP-Sync message and the times (t a 3, t b 3, or t c 3) when they send the PTP-Req message.

[0132] Therefore, when each follower receives the PTP-Sync message transmission time (t1) and the PTP-Req message reception times (t a 4, t b 4, t c 4) from the coordinator, it can calculate the offset and delay by the PTP method.

[0133] Therefore, when the coordinator receives PTP-Req messages from each follower (Follower a, Follower b, Follower c), it broadcasts a PTP-Resp message (Ethernet frame) containing time information (t1, t a 4, t b 4, t c 4) immediately after the next beacon signal is transmitted.

[0134] 6) When each follower receives a PTP-Resp message containing time information (t1, t a 4, t b 4, t c 4), it can calculate the offset, which is the difference between its own clock and the master clock, and the delay, which is the transmission delay, and perform time synchronization.

[0135] When performing time synchronization through the above procedure, it has the following advantages compared to the conventional PTP method.

[0136] The PTP coordinator is a 10BASE-T1S master that periodically transmits beacons. This beacon signal can be used as a PTP-Sync message, or a PTP-Sync message can be transmitted immediately after the beacon signal is transmitted. In either case, the offset calculation for time synchronization can be completed within two beacon cycles.

[0137] In a 10BASE-T1S environment where up to 8 terminals share a single bus, significant bandwidth savings are possible compared to existing methods, and more precise time synchronization can be achieved.

[0138] Among PTP messages, the message that uses an Ethernet frame contains only the PTP-Resp message with time information (t1, t a 4, t b 4, t c 4), so it has an excellent bandwidth-saving effect.

[0139] The bandwidth usage is compared to existing PTP messaging methods as follows:

[0140] Existing PTP schemes require at least three Ethernet frames. When a PTP coordinator and one follower exchange PTP messages, applying the minimum Ethernet frame length (64 bytes), the data length of three Ethernet frames is 1,536 bits (64 x 8 x 3). For a 10BASE-T1S network with up to eight devices (one PTP coordinator and seven followers) connected to the same bus and synchronized, 10,752 bits are required. Header data, such as the frame preamble, is subtracted from this length.

[0141] In the method according to Embodiment 3 of the present invention, the information necessary for time synchronization calculation is (t1, t a 4, t b 4, t c 4) is transmitted via PTP-Resp messages. Unlike existing methods, only one Ethernet frame is required.

[0142] When up to eight devices (one PTP coordinator and seven followers) that can participate in the same bus on a 10BASE-T1S network are linked and synchronized for time, only one PTP message (PTE-Resp) is an Ethernet frame (64 bytes = 512 bits). In addition, one PTP-Sync message and up to seven PTP-Req messages, each consisting of a 5-bit symbol, are required, so adding these 40 bits brings the total required bandwidth to 552 bits. Therefore, time synchronization can be achieved by consuming only 5.13% of the existing bandwidth.

[0143] Figure 12 is a diagram illustrating the PTP messaging sequence of Embodiment 3-2 according to the present invention. In contrast to Embodiment 3-1 in Figure 11, where the 10BASE-T1S master and the PTP coordinator are the same, Embodiment 3-2 is where the 10BASE-T1S master and the PTP coordinator are different, and is identical to the procedure described in the first embodiment except that the PTP coordinator does not use beacons as PTP-Sync.

[0144] In other words, immediately after the master transmits a beacon, the coordinator transmits a symbol defined by PTP-Sync, and in the next beacon cycle, it transmits time information (t1, t4) via a PTP-Resp message so that each follower (Follower a, Follower b, Follower c) can check the time information (t1, t2, t3, t4) and calculate the offset.

[0145] Even in Example 3-2, where the PTP coordinator and the 10BASE-T1S master are different, the offset calculation for time synchronization can be completed in two cycles. However, while in Example 3-1 the PTP coordinator transmitted all PTP requests to all followers in one cycle, in Example 3-2, where the PTP coordinator and the 10BASE-T1S master are different, it may take two cycles for all followers to transmit the PTP requests. Nevertheless, since PTP messaging can be completed within two cycles, the effect of reducing transmission bandwidth is substantially the same.

[0146] The configuration and operation of the PTP coordinator and follower will be described below with reference to Figures 13 and 14.

[0147] Figure 13 is an internal diagram of the PTP coordinator 100. For ease of explanation and to enhance understanding, only the components used for time synchronization are shown, and other components not related to the technical essence of the present invention are not shown.

[0148] The coordinator includes a clock 110, a control unit 120 that performs the aforementioned PTP messaging, and a transmitting / receiving unit 130 that sends and receives PTP messages with one or more followers 200_1...200_n according to the instructions of the control unit 120.

[0149] Coordinator 100's clock 110 acts as the master clock on the network.

[0150] The control unit 120 carries out the procedures performed by the coordinator 100 in the procedures 1) to 6) described above.

[0151] In other words, the control unit 120 of the coordinator 100 controls the transmitting / receiving unit 130 to send a PTP-Sync message at time t1. This is done by using a beacon as a PTP-Sync message or by sending a symbol defined as a PTP-Sync message immediately after sending a beacon.

[0152] Subsequently, each follower 200_1...200_n that received the PTP-Sync message will receive their respective timestamps (t a 3, t b 3, t c 3) When the PTP-Req message (5-bit symbol) sent to is received through the transmitting / receiving unit 130, the reception time (t) of each PTP-Req message is recorded. a 4, t b 4, t c 4) Check this and save it.

[0153] When a PTP-Req message is received from all followers 200_1...200_n in the network, time information (t1, t) is sent immediately after the next beacon signal is transmitted. a 4, t b 4, t c Broadcast a PTP-Resp message (Ethernet frame) that includes 4).

[0154] Figure 14 is an internal diagram of the PTP follower 200. For ease of explanation and to enhance understanding, only the components used for time synchronization are shown, and other components not related to the technical essence of the present invention are not shown.

[0155] The follower 200 includes a clock 210, a control unit 220 that performs the aforementioned PTP messaging, and a transmitting / receiving unit 230 that sends and receives PTP messages with the coordinator 100 according to the instructions of the control unit 220.

[0156] The clock 210 of the follower 200 provides a reference point for the operation of the components within each follower 200.

[0157] The control unit 220 of the follower 200 carries out the procedures that the follower 200 performs in the procedures 1) to 6) described above.

[0158] In other words, when a PTP_Sync message (beacon signal or 5-bit symbol) broadcast to all followers 200_1...200_n in the network is received through the transmitting / receiving unit 230, the reception time (t a 2, t b 2, or t c 2) Check and save.

[0159] Then, at each time (t a 3, t b 3, or t c 3) The transmitting / receiving unit 230 is instructed to send a PTP-Req message (5-bit symbol) to the coordinator, and the transmission time (t a 3, t b 3, or t c 3) Save.

[0160] Through the above process, the control unit 220 determines the time (t) at which the PTP-Sync message was received. a 2, t b 2, or t c 2) the time when they themselves sent the PTP-Req message (t a 3, t b3, or t c 3) Check and save.

[0161] Subsequently, the time (t1) when Coordinator 100 sends PTP_Sync and the time (t) when Coordinator 100 receives PTP_Req messages sent by followers 200_1...200_n in the network. a 4, t b 4, and t c The PTP-Resp message (Ethernet frame) containing 4) is received via the transceiver 230.

[0162] Each follower's control unit 220 receives the time information it has stored (t a 2, t b 2, or t c 2) and time information (t a 3, t b 3, or t c 3) and time information (t1, t) included in the PTP-Resp message a 4, t b 4, t c Based on 4), the offset, which is the difference between its own clock 210 and the master clock 110, and the delay, which is the transmission delay, can be calculated, and time synchronization can be performed.

[0163] On the other hand, in the above description, the coordinator 100 and follower 200 were described based on Example 3. However, it will be obvious to those of the ordinary art that the coordinator 100 and follower 200 according to the present invention can be configured to perform the methods carried out in Examples 1 and 2.

[0164] In other words, although a detailed explanation will be omitted to avoid redundancy, it is obvious that the coordinator 100 and follower 200 disclosed in Figures 13 and 14 can perform the method of Example 1 and the method of Example 2.

[0165] <Example 4>

[0166] This embodiment describes coding schemes (such as 4B5B, 8B10B, etc.) for performing PTP messaging using variable-length symbols (e.g., 5-bit or 10-bit symbols) instead of network frames.

[0167] As in Example 3, if a 5-bit symbol standard is predetermined, such as in 10BASE-T1S, it would suffice to use only a portion of the symbols reserved in that standard as PTP messages. However, in order to actually use 5-bit or 10-bit symbols as PTP messages in a point-to-point configuration via an Ethernet switch or in various other topologies, the block coding method in Example 4 is necessary.

[0168] In networking, it is common to pre-define and use control symbols, such as in 10BASE-T1S. While this has the advantage of establishing a common standard and improving compatibility among multiple network entities, it often fails to fully realize the benefits that can be realized in diverse applications and also has vulnerabilities from a security standpoint.

[0169] For example, in PTP messaging for time synchronization, to maximize transmission bandwidth efficiency, it is more efficient to use symbols with a length of a few bits, rather than long network frames (for example, the minimum length of an Ethernet frame is 64 bytes), to perform PTP messaging. In cases where a 5-bit symbol standard and its use are predetermined and a symbol table is defined, such as in 10BASE-T1S, it is sufficient to use only a portion of the symbols reserved by the standard as PTP messages.

[0170] By the way, using fixed symbols that cannot be changed is difficult when configuring point-to-point communication via Ethernet switches, or when using 5-bit or 10-bit symbols as PTP messages in various other topologies, or for various other applications.

[0171] Furthermore, when using standardized fixed symbols in networks requiring strong security, there is a problem in that signal analysis becomes easier.

[0172] Therefore, there is a need for a variable block coding method and apparatus that allows users to easily edit and configure network symbols.

[0173] In other words, conventional Ethernet 4B5B (or 8B10B) used a fixed symbol table. For more flexible system development, it is necessary to allow users to edit and configure this symbol table.

[0174] According to Example 4, by making it possible to edit the symbols used in B5B (8B10B), a more flexible and secure communication system can be created.

[0175] Because a fixed table can be edited, security is enhanced as users can only communicate with nodes that know the exact table by modifying it.

[0176] By editing the symbols in this table in different digital signal environments, depending on the cable installation environment and system status, slightly better performance can be achieved.

[0177] As mentioned earlier, the reason for using block coding (bit transmission encoding) such as 4B5B, 5B6B, and 8B10B is to eliminate the DC component of the digital signal, reduce power consumption, and facilitate signal reconstruction.

[0178] In relation to Example 4, the inventors of the present invention focused on the fact that conventionally, symbol tables are fixed for each network standard. Changing this symbol table would yield benefits. The greatest benefit would be enhanced security. Having multiple such symbol tables and using a strategy to change these symbol tables would allow for communication security. This is because systems without this symbol table information cannot communicate.

[0179] Of course, if the part that processes the symbols is developed as an analog chip, it may be difficult to change this part, but if these symbols are used in a digital circuit, editing is quite possible.

[0180] Furthermore, if certain bit patterns exhibit different characteristics depending on the environment in which the cable is installed, modifying this symbol conversion table can provide a more high-performance communication environment.

[0181] For example, in the 4B5B block coding table, 0000b (binary) is transmitted as 11110b (binary). Table 2, mentioned above, is the 4B5B conversion table used in 10BASE-T1S. The parts highlighted in fluorescent color are unused bit patterns.

[0182] In Example 4, 01100b or 00110b may be used instead of 11110b. Furthermore, the bit patterns between data can be varied and used like a cipher table. While the beacon signal uses a 01000b bit pattern, a 10000b bit pattern may also be used.

[0183] However, currently, all Ethernet transceiver chips are fixed in a way that prevents such conversion information from being altered, due to standard requirements. Of course, such commitments are very important from a compatibility standpoint. However, in certain environments, security can be even more important than compatibility.

[0184] Figure 15 is a block diagram of the inside of a PHY chip using 4B5B according to the present invention. The 4B5B encoder and 4B5B decoder are the same as conventional configurations in that they are internal chip circuits that perform the function of converting 4-bit data to 5-bit symbols and 5-bit symbols to 4-bit data, but the difference is that the symbol conversion table in the diagram of Figure 15 is variable.

[0185] The core of Example 4 is to enable this circuit to perform the conversion function by referring to conversion information from a variable 4B5B encoding conversion table (see double solid line).

[0186] The variable 4B5B encoding conversion table in Example 4 can be verified and modified by the user via software using the MDIO interface. For example, in addition to the data channel of the MII interface, there is an MDIO interface for checking registers and memory information inside the PHY chip, and this variable encoding conversion table can be accessed and modified through this interface (see thick dotted line).

[0187] On the other hand, not only 4B5B but also block coding such as 8B10B can be encoded and decoded using the same variable table.

[0188] Figure 16 shows an example of 8B10B block coding. In this case, the code must be divided into 5B6B and 3B4B, so the 8B10B conversion table must contain all of these two tables.

[0189] In addition to 8B10B block coding, various other bit-based data-symbol block codings are possible, such as 6B8B and 10B12B.

[0190] As shown in FIG. 16, a method for performing variable-length block coding in a network transceiver using two or more conversion tables includes a correspondence relationship between A-bit data and B-bit symbols (A and B are natural numbers greater than or equal to 1, A < B), and arranging an editable first variable-length conversion table; arranging an editable second variable-length conversion table including a correspondence relationship between C-bit data and D-bit symbols (C and D are natural numbers greater than or equal to 1, C < D); editing the first and second variable-length conversion tables by accessing them through a management interface; combining the first variable-length symbol table and the second variable-length conversion table to form a third variable-length conversion table; and block-coding A + C-bit data into C + D-bit symbols by referring to the third variable-length conversion table.

[0191] For example, a 5B6B conversion table and a 3B4B conversion table can be combined to form an 8B10B conversion table, and 8-bit data can be block-coded into 10-bit symbols by referring to the 8B10B conversion table.

[0192] A network transceiver for performing such variable-length block coding includes a first variable-length conversion table that maps A-bit data and B-bit symbols (A and B are natural numbers greater than or equal to 1, A < B) in a 1:1 mapping, a second variable-length conversion table that maps C-bit data and D-bit symbols (C and D are natural numbers greater than or equal to 1, C < D) in a 1:1 mapping, a management interface that allows the first and second variable-length conversion tables to be accessed for editing and setting, a third variable-length conversion table formed by combining the first and second variable-length conversion tables, and an encoder that converts data into symbols by referring to the third variable-length conversion table.

[0193] The network transceiver may further include a transmitter that transmits the output of the encoder, a receiver that receives a signal including symbols from the network, and a decoder that converts the received symbols into data by referring to the third variable-length conversion table.

[0194] Thus, if symbol conversion coding can be performed flexibly as in Examples 1 to 3, it is possible to improve the efficiency of PTP messaging while performing PTP messaging with custom symbols without being bound by existing communication standards.

[0195] Furthermore, as in Example 3, even when a specific standard is assumed, it is possible to use other bit symbols (for example, 6-bit, 10-bit symbols, or symbols with more bits via 5B6B, 8B10B conversion) instead of only using the reserved symbols.

[0196] In this case, PTP messaging can offer significant flexibility and efficiency.

[0197] For example, in Examples 1-3, each follower (Follower a, Follower b, Follower c) receives time information (t) that the coordinator sends in conjunction with a single Delay_Resp message. a 4, t b 4, t c 4) It is necessary to distinguish which of these is the coordinator reception time information for the Delay_Req that you sent.

[0198] Furthermore, the coordinator must distinguish which follower sent each Delay_Req message. If the coordinator can distinguish which follower sent each PTP-Req message, the time information (t a 4, t b 4, t c 4) can be configured precisely, and then each follower can see the reception time of each PTP-Req message they sent (t a 4, t b 4, t c 4) can be broadcast with information that clearly distinguishes it from the others.

[0199] To achieve this, as described above in relation to Examples 1-3, each follower on the network must transmit in a predetermined order, and all nodes on the network must know this transmission order, or Delay_Req message and time information (t a 4, t b 4, t c Each of the items in 4) must contain or be concatenated with a follower identifier.

[0200] By adopting the variable coding method of Example 4, the follower identifier can be included in a symbol with a very small number of bits.

[0201] For example, a follower identifier can be sent together with the PTP-Req message (5-bit symbol). Since 10BASE-T1S can connect up to 8 devices, a 3-bit identifier can be used to distinguish each follower. In networks with more nodes connected, it is possible to add enough bits (4 bits, 5 bits, etc.) to identify all connected followers and configure the system to identify the follower that transmitted the Delay_Req message.

[0202] If identifiers were to be included in the Delay_Req message in the usual way in Examples 1-3, it would be necessary to use a normal network frame (for example, an Ethernet frame of at least 64 bytes), which would significantly reduce the efficiency of the PTP messaging proposed by this invention. However, by combining it with Example 4, flexible and efficient PTP messaging is possible with just a few bits.

[0203] In other words, through the configuration of Example 4, the embodiments of Examples 1 to 3 described above can be universally applied to a variety of networks.

[0204] It must be clearly understood that, while several embodiments of this specification focus on the application of variable block coding in PTP-based efficient time synchronization for the sake of understanding, the uses and target audiences of the variable block coding method and apparatus according to the present invention are not limited thereto, and a wide range of applications and uses are possible.

[0205] The specific configurations relating to each aspect of the present invention described above will be summarized below.

[0206] As one embodiment, a method for performing time synchronization within a network in which a coordinator and a plurality of followers are linked based on a PTP scheme is disclosed, the method comprising the steps of: the coordinator broadcasting a single Sync message; the plurality of followers who receive the Sync message save the Sync message reception time (t2); the coordinator, having received Req messages from each of the plurality of followers, sends a Resp message to each of the plurality of followers, including the transmission time (t1) of the Sync message and the reception time (t4) of each Req message; each of the plurality of followers who have received the transmission time (t1) of the Sync message and the reception time (t4) of the Req messages calculates a time offset with the coordinator; and the plurality of followers synchronize their time with the coordinator based on the time offset.

[0207] Through some configuration modifications, a method can be used to perform time synchronization within a network where a coordinator and a plurality of followers are linked based on a PTP scheme, the method comprising the steps of: the coordinator broadcasting a Sync message; the plurality of followers who receive the Sync message save the Sync message reception time (t2); the coordinator, having received Req messages from each of the plurality of followers, broadcasts a single Resp message including the transmission time (t1) of the Sync message and the reception time (t4) of each Req message; the plurality of followers who have received the transmission time (t1) of the Sync message and the reception time (t4) of the Req messages calculate a time offset with the coordinator; and the plurality of followers synchronize their time with the coordinator based on the time offset.

[0208] The step of broadcasting the Sync message may include the step of saving the transmission time (t1) of the Sync message.

[0209] The step of sending the Req message may include a step of saving the Req message transmission time (t3).

[0210] The step of broadcasting the Resp message may include the steps of saving one or more times (t4) when the coordinator receives the Req message, including the time (t1) and the one or more times (t4) in an Ethernet frame, and broadcasting the Ethernet frame as a Resp message.

[0211] Alternatively, the step of broadcasting the Resp message may include the steps of generating a Resp message containing a plurality of identifiers and the reception time of a Req message, pairing the identifier of each of the plurality of followers with the reception time of a Req message sent by each follower, and broadcasting the Resp message.

[0212] If a Req message is not received from some of the aforementioned followers for a predetermined period of time or longer, a Delay-Resp message is generated, excluding the Req arrival time (t3) information for those followers.

[0213] The step of broadcasting the Resp message may include the steps of: determining an order for each follower in advance, arranging the reception times of the Req messages sent by each follower according to that order, and generating a Resp message; and broadcasting the Resp message.

[0214] In the step of generating the Resp message, if a Req message is not received from some of the followers among the multiple followers for a predetermined period of time or longer, a Delay-Resp message can be generated by zero-padding the portion corresponding to the order of the some followers.

[0215] A time synchronization system is disclosed for performing PTP-based time synchronization over a network, comprising a clock that performs a master clock function on the network, a control unit that performs PTP messaging using symbols, a PTP coordinator including a transmit / receive unit that sends and receives PTP messages with one or more followers at the direction of the control unit, a clock that provides an operating reference point for internal components, a control unit that performs PTP messaging using symbols, and a PTP follower including a transmit / receive unit that sends and receives PTP messages with the coordinator at the direction of the control unit.

[0216] As one embodiment, a method is disclosed for performing time synchronization within a network where a coordinator and a follower are connected point-to-point based on a PTP scheme, the method comprising the steps of: the coordinator transmitting a symbol instead of a network frame as a Sync message; the follower receiving the Sync message saving the Sync message reception time (t2); the follower transmitting a symbol different from the symbol as a Request message; the coordinator receiving the Req message transmitting a network frame including the transmission time of the Sync message (t1) and the reception times (t4) of a plurality of Req messages as a Resp message; the follower receiving the transmission time of the Sync message (t1) and the reception times (t4) of the Req messages calculating a time offset with the coordinator; and the follower synchronizing time with the coordinator based on the time offset.

[0217] The step of transmitting the Sync message may include a step of broadcasting a symbol that has been previously defined as a Sync message.

[0218] The step of sending the aforementioned Req message may include the step of sending a symbol that has been previously defined as a Req message.

[0219] The step of sending the Req message may include a step of saving the Req message sending time (t3).

[0220] The step of transmitting the Sync message may include the step of saving the transmission time (t1) of the Sync message.

[0221] The step of transmitting the Resp message may include the step of saving the time (t4) when the coordinator receives the Req message, the step of including the time (t1) and the time (t4) in an Ethernet frame, and the step of transmitting the Ethernet frame as a Resp message.

[0222] In one embodiment, a PTP coordinator is disclosed that performs time synchronization of a PTP infrastructure on an Ethernet network, and includes a clock that performs a master clock function on the network, a control unit that controls the transmission of Sync messages using symbols and the transmission of Resp messages in Ethernet frames, and a transceiver that transmits the Sync messages and Resp messages to a follower and receives Req messages transmitted by the follower according to the instructions of the control unit.

[0223] The aforementioned symbol may be a symbol converted using at least one block coding scheme from 4B5B and 8B10B.

[0224] A PTP follower is disclosed for performing PTP-based time synchronization on an Ethernet network, which includes a clock that provides an operating reference time for internal components, a control unit that performs PTP messaging using symbols, and a transmit / receive unit that sends and receives PTP messages to and from a coordinator at the direction of the control unit.

[0225] When the control unit receives the Sync message through the transmitting / receiving unit, it confirms and saves the reception time (t2), sends a Req message composed of the symbols and saves its transmission time (t3), and when it receives the transmission time (t1) of the Sync message and the time (t4) when the Req message arrived at the coordinator from the coordinator, it calculates an offset with the coordinator based on the times (t1), (t2), (t3), and (t4), and performs time synchronization with the coordinator based on the offset.

[0226] As an example, a method for performing variable block coding in a network transceiver, the method comprising: arranging an editable variable transform table in the transceiver; accessing the variable transform table through a management interface; editing a data-symbol correspondence of the variable transform table; and performing block coding on data transmitted by an encoder of the network transceiver by referring to the variable transform table. A variable block coding method is disclosed.

[0227] Access to the variable transform table can be achieved through an MDIO interface.

[0228] The step of editing the data-symbol correspondence of the variable transform table may include mapping such that different B-bit symbols respectively correspond to one or more A-bit data in a 1:1 manner (A and B are natural numbers greater than or equal to 1, and A < B).

[0229] As an example, a network transceiver for performing variable block coding includes: a variable transform table mapping a correspondence between data and symbols; a management interface enabling access to the variable transform table for editing and setting; an encoder converting data to symbols by referring to the variable transform table; a transmitter transmitting an output of the encoder; a receiver receiving a signal including symbols from a network; and a decoder converting the received symbols to data by referring to the variable transform table. A network transceiver is disclosed.

[0230] The management interface may be an MDIO interface defined by the IEEE 802.3 standard.

[0231] As an example, a method for performing variable block coding in a network transceiver, including a correspondence relationship between A-bit data and B-bit symbols (A and B are natural numbers greater than or equal to 1, A < B), and arranging an editable first variable transformation table; arranging an editable second variable transformation table including a correspondence relationship between C-bit data and D-bit symbols (C and D are natural numbers greater than or equal to 1, C < D); editing the first and second variable transformation tables by accessing them through a management interface; combining the first variable symbol table and the second variable transformation table to form a third variable transformation table; and performing block coding on A + C-bit data into C + D-bit symbols by referring to the third variable transformation table. A variable block coding method is disclosed.

[0232] The step of forming the third variable transformation table is to combine a 5B6B transformation table and a 3B4B transformation table to form an 8B10B transformation table.

[0233] A step of decoding the symbol received through the network into A + C-bit data by referring to the third variable transformation table may be added.

[0234] As an example, a network transceiver for performing variable block coding includes a first variable transformation table that maps A-bit data and B-bit symbols (A and B are natural numbers greater than or equal to 1, A < B) in a 1:1 mapping, a second variable transformation table that maps C-bit data and D-bit symbols (C and D are natural numbers greater than or equal to 1, C < D) in a 1:1 mapping, a management interface that allows the first and second variable transformation tables to be accessed for editing and setting, a third variable transformation table formed by combining the first and second variable transformation tables, and an encoder that converts data into symbols by referring to the third variable transformation table. A network transceiver is disclosed.

[0235] A transmitting unit that transmits the output of the encoder, a receiving unit that receives a signal including symbols from a network, and a decoder that converts the received symbols into data by referring to the third variable conversion table may be added.

[0236] The configuration of the present invention has been described in detail above with reference to preferred embodiments of the present invention. However, the embodiments described above are merely illustrative, and it goes without saying that various modifications and changes are possible within the scope of the technical idea of ​​the present invention, such as combinations of each embodiment. Therefore, the scope of protection of the present invention should be defined by the following claims.

Claims

1. A method for performing time synchronization within a network in which a coordinator and one or more followers are linked based on the PTP method, The coordinator broadcasts one of the symbols as a Sync message, The plurality of followers that received the Sync message will determine the time of receipt of the Sync message (t ２ The stage of saving ) The step in which each of the aforementioned multiple followers sends a Req message, The coordinator that has received multiple Req messages determines the transmission time (t) of the Sync message. １ ) and the reception time of each of the multiple Req messages (t ４ The stage of broadcasting a single Resp message that includes ) The transmission time of the aforementioned Sync message (t １ ) and the reception time of the Req message (t ４ The steps include: a step in which multiple followers who receive the message calculate a time offset with the coordinator, A time synchronization method comprising the step of the plurality of followers synchronizing their time with the coordinator based on the time offset.

2. The step of broadcasting the Sync message is as follows: The time synchronization method according to claim 1, wherein a symbol previously defined as a Sync message is broadcast after the transmission of a beacon signal.

3. The step of sending the aforementioned Req message is: The time synchronization method according to claim 1, wherein a symbol defined in advance as a Req message is transmitted.

4. The step of sending the aforementioned Req message is: The time of sending the aforementioned Req message (t ３ The time synchronization method according to claim 1, further comprising the step of saving ).

5. The step of broadcasting the Sync message is as follows: The transmission time of the aforementioned Sync message (t １ The time synchronization method according to claim 1, further comprising the step of saving ).

6. The stage of broadcasting the Resp message is, The time (t) at which the coordinator received the Req message. ４ The stage of saving ) said time (t １ ) and said time (t ４ ) in an Ethernet frame, and The time synchronization method according to claim 1, further comprising the step of broadcasting the Ethernet frame as a Resp message.

7. A method for performing time synchronization within a network when the master of a 10BASE-T1S network is a time synchronization coordinator based on the PTP method, The aforementioned coordinator periodically broadcasts the beacon as a Sync message and transmits it at the time (t １ The stage of saving ) One or more followers who received the beacon will determine the beacon reception time (t ２ The stage of saving ) The step of one or more followers sending a Request message, The coordinator that received the Req message determines the transmission time of the beacon (t １ ) and the reception time of the Req message (t ４ The stage of broadcasting a single Resp message that includes ) The transmission time of the aforementioned Sync message (t １ ) and the reception time of the Req message (t ４ A time synchronization method comprising the step of one or more followers who receive a ) calculate a time offset with the coordinator.

8. The step in which one or more followers calculate the time offset with the coordinator is: The time (t １ ), the time (t ２ ), the time (t ３ ), the time (t ４ The time synchronization method according to claim 7, wherein the time offset is calculated based on ).

9. The step of calculating the aforementioned time offset is: The time synchronization method according to claim 8, wherein the time offset (O) is calculated by the following formula (1). [Math 1]

10. The time synchronization method according to claim 7, further comprising the step of one or more followers synchronizing their time with the coordinator based on the time offset.

11. The step of sending the aforementioned Req message is: The time synchronization method according to claim 1, further comprising the step of determining one of the reserved symbols among the 10BASE-T1S BME block coding symbols to be a Req message.

12. A PTP coordinator that performs time synchronization of the PTP infrastructure on an Ethernet network, A clock that performs the master clock function on the network, A control unit that performs PTP messaging using symbols, A PTP coordinator including a transmitting / receiving unit that sends and receives PTP messages with one or more followers according to instructions from the control unit.

13. The aforementioned symbol is The PTP coordinator according to claim 12, wherein the 10BASE-T1S BME block coding symbols are reserved symbols.

14. The control unit, The symbol defined in advance as a Sync message is used at time (t １ It sends to ( ) and when it receives the symbol defined as the Req message, it receives it at the time of reception (t ３ ) and save the said time (t １ ) and time (t ４ The PTP coordinator according to claim 12, which controls the transmitting and receiving unit to generate a single Resp message including ) and broadcast it.

15. The control unit, The PTP coordinator according to claim 14, which broadcasts the Resp message in an Ethernet frame.

16. The control unit, The PTP coordinator according to claim 12, which periodically transmits a beacon signal, which is a data transmission reference signal for the aforementioned network, as Sync.

17. A PTP follower that performs PTP-based time synchronization on an Ethernet network, A clock that provides the operating reference point for the internal components, A control unit that performs PTP messaging using symbols, A PTP follower including a transmitting / receiving unit that sends and receives PTP messages with a coordinator according to instructions from the control unit.

18. In paragraph 17, The control unit, When a broadcasted Sync message is received through the transmitting / receiving unit, the reception time (t ２ ) confirm and save, and send a Req message composed of the above symbols and the transmission time (t ３ ) saves the broadcasting time (t) of the Sync message from the coordinator. １ ) and the time (t) when the Req message arrived at the coordinator. ４ When the above time (t) is received, １ ), time (t ２ ), time (t ３ ), time (t ４ The PTP follower according to claim 17, which calculates an offset with the coordinator based on the above and performs time synchronization with the coordinator based on the offset.

Images