JP7582004B2 - Gate status confirmation system, gate status confirmation method, and communication device - Google Patents

Description

The present invention relates to a communication device equipped with the "IEEE802.1AS (gPTP)" function and the "IEEE802.1Qbv (traffic scheduling)" function of TSN (Time-Sensitive Networking).

TSN, described in Patent Document 1 and Non-Patent Document 1, is a network technology that enables interoperability between industrial networks and IT networks that extend standard Ethernet (registered trademark), and is composed of multiple standards such as "IEEE802.1AS" and "IEEE802.1Qbv."

1. IEEE802.1AS
The "IEEE 802.1AS" standard is abbreviated as "gPPT". The time synchronization packets by this "gPTP" function are only available at the L2 layer and only with the "PtoP (between adjacent devices)" transparency function. It differs from a normal PTP time synchronization packet.

Specifically, time synchronization in the "gPTP function" involves a "PtoP (adjacent devices)" TWO step as shown in Figure 1, and the transmission time D (Meanpath) is calculated using Equation 1.

Equation (1): Transmission time D = "(T4-T3) + (T2-T1)" / 2 = "(T4-T1) - (T3-T2)" / 2
2 shows the difference between time synchronization by the ONE step of PTP and the TWO step by using the "SYNC" message as an example. That is, in the "ONE step", the time stamp information of "T1" is set in the "SYNC" message packet and transmitted.

On the other hand, in the TWO step, "T1" is set in the "Follow_UP" message packet rather than the "SYNC message" packet and sent (the same applies to the "Pdelay_Resp_Follow_UP" message).

Then, the elapsed time (t1) from "T1" is calculated using Equation 2, which takes into account the delay in reception time (t3 - T2) based on Figure 2, and the time between the master and slave is corrected based on the time difference between "t1" and "t3".

Equation (2): Elapsed time (t1) = T1 + D + (t3 - T2)
2. IEEE802.1Qbv
The IEEE 802.1Qbv time-aware scheduler divides communications on an Ethernet network into fixed-length, repeating time cycles, and within these cycles configures time slices that are assigned to one or more of the eight Ethernet priorities (a "traffic scheduling" function).

This allows a traffic class that requires guaranteed transmission and cannot be interrupted to be granted exclusive use of the Ethernet transmission medium for a limited period of time. The basic concept is Time Division Multiple Access (TDMA), which allows time-critical communications to be separated from non-critical background traffic by establishing virtual communications channels for specific periods of time.

Patent Publication No. 2020-107943

"Outline and implementation of "TSN" that combines IT and OT networks", [online], searched on March 3, 2021, Internet <URL: http:ednjapan.com/edn/arrticies/1803/23/news014.html>

TSN-compatible communication devices (switching hubs: hereafter referred to as TSN hubs) are equipped with the "gPTP" and "traffic scheduling" functions.

This allows time synchronization between TSN hubs and sets up traffic scheduling (hereafter referred to as "gates") for packet transmission that is shifted by the distance between the TSN hubs and the time required to pass through the TSN hubs, making it possible to transmit priority packets without delay even under high load.

However, because gates are set up individually by each TSN hub, there is a risk of packets being stalled if the gates between all TSN hubs are not set up correctly.

The present invention aims to solve the problem of proposing a method to detect gate setting errors by checking the gate status between TSN-compatible communication devices.

(1) One aspect of the present invention is a system for checking the status of a gate that defines a schedule for packet transmission set in a TSN-compatible communication device, the system comprising:
The communication device that initiates the confirmation transmits a packet to and from the other communication device that is arbitrarily selected as the target of the confirmation,
Obtain gate information describing the "mean path value" between the two communication devices and the actual reception time to the other communication device;
Calculate the time difference between the ideal reception time based on the "Meanpath value" described in the gate information and the actual reception time,
The state of the gate is confirmed based on the time difference.

(2) Another aspect of the present invention is a method for checking the status of a gate that defines a schedule for packet transmission set in a TSN-enabled communication device, the method comprising the steps of:
A step in which one of the communication devices initiating the confirmation transmits a packet back and forth between the communication device and the other communication device arbitrarily selected as the subject of the confirmation, thereby acquiring gate information describing a "mean path value" between the two communication devices and an actual reception time to the other communication device;
The method is characterized by having a step of calculating a time difference between an ideal reception time based on a "Meanpath value" described in the gate information and the actual reception time, and confirming a state of the gate based on the calculated time difference.

(3) Yet another aspect of the present invention is a TSN-compatible communication device,
a function for checking a gate state that defines a schedule for packet transmission of the TSN in another arbitrarily selected communication device;
By sending a packet back and forth to another communication device arbitrarily selected as the subject of the confirmation, gate information describing a "mean path value" between the two communication devices and an actual reception time to the other communication device are obtained,
Calculate the time difference between the ideal reception time based on the "Meanpath value" described in the gate information and the actual reception time,
The state of the gate is confirmed based on the time difference.

The present invention makes it possible to check the gate status between TSN hubs, making it possible to detect errors in gate settings, etc.

Schematic diagram of TSN time synchronization (gPTP). FIG. 2 is a schematic diagram showing the difference between the ONE step and the TWO step. Network configuration diagram of a TSN hub. FIG. 1 is a schematic diagram showing an example of gate configuration within a TSN hub. FIG. 2 is a diagram showing the transmission paths of a gate confirmation packet and a gate information packet of the gate status confirmation system according to the embodiment of the present invention. FIG. 4 is an explanatory diagram showing the generation of gate information. FIG. 13 is an explanatory diagram showing the processing performed when a gate status confirmation request is made. FIG. 11 is an explanatory diagram showing the processing performed when responding to a gate status confirmation response. FIG. 13 is an explanatory diagram showing the gate confirmation process of the same. 13 is a flowchart showing the main TSN packet transfer processing of the "gPTP" task. 13 is a flowchart showing the gate confirmation packet reception process of the "gPTP" task. 13 is a flowchart showing a gate management main process of the gate management task of the embodiment; 4 is a flowchart showing gate information receiving processing according to the embodiment; 13 is a flowchart showing the gate status confirmation request process of the embodiment; 4 is a flowchart showing the gate status confirmation response process of the first embodiment;

The following describes a gate status confirmation system according to an embodiment of the present invention. This gate status confirmation system makes it possible to confirm whether a gate for packet transmission for each class set on a TSN hub is operating normally between any TSN hubs.

As an example, let us consider the network shown in Figure 3. This network is made up of TSN hubs 1 to 7. These TSN hubs 1 to 7 are equipped with the TSN "IEEE802.1AS (gPTP)" function and "IEEE802.1Qbv (traffic scheduling)" function.

As a result, time synchronization is possible between TSN hubs 1-7 using the "gPTP" function, and the "gPTP" ports of each TSN hub 1-7 are configured with a traffic scheduling function that takes into account the transmission delay between TSN hubs 1-7 (hereafter, traffic scheduled to a "gPTP" port inside a TSN hub will be referred to as a gate).

3, the "Roman numerals + TSN hub numbers" between TSN hubs 1 to 7 represent the "Meanpath" values in the arrow directions between TSN hubs 1 to 7. That is, "≡-1" and "≡-2" represent the "Meanpath" values between TSN hubs 1 and 2, "≡-1" and "≡-2" represent the "Meanpath" values between TSN hubs 2 and 3,
“≡-1” and “≡-2” indicate the “Meanpath” values between TSN hubs 3 and 4,
“≡-1” and “≡-2” indicate the “Meanpath” values between TSN hubs 2 and 5, “≡-1” and “≡-2” indicate the “Meanpath” values between TSN hubs 5 and 6, and “≡-1” and “≡-2” indicate the “Meanpath” values between TSN hubs 6 and 7.

Figure 4 shows the gate function using the TSN hub 6 as an example. Here, the TSN hub 6 can set "Priority 0-7" (hereafter referred to as "Qpri0-7") of the "Queue" as the gate 14, and can transmit data in the order of the set "Qpri0-7" with priority for a certain period of time.

For example, when "Qpri5" of gate 14 is open, a packet of "Queue5" that enters "gPTP" port 11 of TSN hub 6 is forwarded to "gPTP" port 12, but if "Qpri" of another gate 14 is open, the packet is not forwarded and is put into a waiting state until the next time "Qpri5" of gate 14 opens. TSN hubs 1, 2, 4 to 7 also have the same gate function.

The "Qpri" of gates 14 with TSNs 1 to 7 works in conjunction with time synchronization (gPTP), allowing packets corresponding to "Qpri" to be sent stress-free even under high load conditions.

However, if the "Qpri" of the gate 14 of each TSN hub 1-7 is not set correctly, it will take a long time to open the "Qpri" of the gate 14 for each TSN hub 1-7, which could cause packet loss in the worst case. Therefore, the gate status confirmation system checks the gate status by performing the following operations.

<Gate status check operation>
When the TSN hubs 1 to 7 arranged on the network of FIG. 3 are functioning as time synchronization and gate settings of "gPTP", any of the TSN hubs 1 to 7 checks the gate status between them.

As an example, the overall operation of the system when checking the gate status from TSN hub 1 to TSN hub 7 will be described with reference to Figures 6 to 9. Here, TSN hubs 1 to 7 each have a "gPTP" task 21 and a gate management task 23.

6 to 9, 21a and 23a indicate the "gPTP" task 21 and gate management task 23 of the TSN hub 1 that start checking the gate status. 21b and 23b indicate the "gPTP" task 21 and gate management task 23 of the TSN hub 7 that are the target (end) of checking the gate status. (1) First, the "gPTP" task 21a sets the "ID" of the TSN hub 7 (see FIG. 6) and sets the execution flag.

Then, a gate confirmation packet is sent from TSN hub 1 using "gPTP" port 12 to TSN hub 7 via TSN hubs 2, 5, and 6, as shown by arrow R1 in Figure 5.

At this time, the "gPTP" task 21 of TSN hubs 2, 5, and 6 adds its own "ID" and the "Meanpath value" of the packet input port (receiving port) 11 to the data portion 25 (see Figure 6) of the received gate confirmation packet, and forwards it to the next TSN hub.

That is, "TSN hub 2 → TSN hub 5", "TSN hub 5 → TSN hub 6",
The packet is transferred in the order of "TSN hub 6 -> TSN hub 7." Finally, when TSN hub 7 receives the gate status confirmation packet, the "gPTP" task 21b generates the gate information 26 shown in FIG.

To explain in more detail, when TSN hub 7 receives the gate status confirmation packet, data portion 25 contains the "IDs of TSN hubs 2, 5, and 6" and the "Meanpath value" on the packet input port 11 side for each "ID."

Then, the "gPTP" task 21b adds its own "ID" and the "Meanpath value" for each of its packet input ports to the information in the data section 25, thereby generating gate information 26 that describes the "Meanpath values" between TSN hubs 1, 2, 5-6.

After creating this gate information 26, the "gPTP" task 21b issues a gate information notification to the gate management task 23b in the TSN hub 7. The gate management task 23b, which receives this gate information notification, generates a gate information packet that describes the gate information 26. The generated gate information packet is sent to TSN1 via TSNs 6, 5, and 2, as shown by the arrow R2 in FIG. 5.

(2) Next, the gate management task 23a in the TSN hub 1 acquires the gate information 26 from the gate information packet and stores the acquired gate information 26. In addition, the gate management task 23a generates a dummy packet (gate status confirmation request packet) for the TSN hub 7 to confirm the gate status, as shown in FIG. 7. The generated gate status confirmation request packet is sent to the TSN hub 7 via the route indicated by the arrow R1, including the transmission time.

When TSN hub 7 receives this gate status confirmation request packet, gate management task 23b calculates the reception time of the gate status confirmation request packet from TSN hub 7. Here, TSN hubs 1 to 7 are time-synchronized by "gPTP", and the reception time is calculated based on the transmission and reception times synchronized by "gPTP". The specific calculation method uses formula (3) in Figures 7 and 8.

After calculating the reception time, the gate management task 23b sends a gate status confirmation response packet containing the reception time, the destination ID (TSN hub 1), and the source ID (TSN hub 7) to TSN hub 1 via the route indicated by arrow R2.

(3) When the TSN hub 1 receives the gate status confirmation response packet, as shown in FIG. 8, the gate management task 23a calculates the ideal reception time of the TSN hub 7 based on the gate information 26. The specific calculation method uses formula (4) in FIG. 8.

The gate management task 23a also finds the time difference between the ideal reception time and the reception time (actual reception time) of the gate status confirmation response packet. The time difference found here is affected by the gate offset set in TSN hubs 1 to 7, so the actual reception time deviates from the ideal reception time by the amount of the gate offset. The gate management task 23a then presents the gate information 26 and the time difference by outputting them to a screen or file on a computer such as an administrator.

(4) After that, the “gPTP” task 21a and the gate management task 23a of TSN hub 1 confirm the gate status of TSN hubs 2, 5, and 6 in the same manner as TSN hub 7 (transmitting a gate status confirmation request packet and a gate status confirmation response packet back and forth), as shown in FIG. 9, and output the confirmation result 30.
At this time, the ideal reception time of TSN hubs 2, 5, and 6 can be calculated from gate information 26, so transmission of gate information packets is omitted. Also, the confirmation result 30 first displays the time difference with TSN hub 7, which is the confirmation target (destination), and then displays the time differences with TSN hubs 2, 5, and 6 in order. Here, if it is determined that the time difference with TSN hub 7 is small, the time differences with TSN hubs 2, 5, and 6 are treated as just a reference.

On the other hand, if it is determined that the time difference with TSN hub 7 is large, it is possible to quickly detect the location of the gate in question by checking the time differences with TSN hubs 2, 5, and 6. The size of the time difference can be automatically detected by setting a threshold value in advance. For example, if the time difference between TSN hubs 7, 2, 5, and 6 exceeds a threshold value, it may be automatically detected that the time difference of TSN hub 7 is large.

<TSN Hub internal processing>
In accordance with the above-mentioned gate status confirmation operation from TSN hub 1 to TSN hub 7,
10, the TSN packet transfer main process, FIG. 10, the gate confirmation packet reception process, FIG. 11, the gate management main process, FIG. 12, the gate information reception process, FIG. 13, the gate status confirmation request process, FIG. 14, and the gate status confirmation response process, FIG.

The TSN packet transfer main process and gate confirmation packet reception process are executed by the "gPTP" task 21. On the other hand, the gate management main process, gate information reception process, gate status confirmation request process, and gate status confirmation response process are executed by the gate management task 23.

(1) TSN Packet Transfer Main Processing The TSN packet transfer main processing will be described with reference to Fig. 10. This processing is started when an administrator or the like uses a command to input the following data A and B and writes them in the gate information definition file.
A: ID of the destination TSN hub (the TSN hub to be checked)
B: Gate start confirmation flag (= TRUE)
S01: The "gPTP" task 21 of the TSN hub reads the gate definition file and sets the data A and B as internal data of the TSN hub.

S02: The "gPTP" task 21 checks whether or not to start checking the gate status by referencing its own gate check start flag. If the flag is set as a result of the check, the process proceeds to S03 to start checking the gate status. On the other hand, if the flag is not set, the process proceeds to S06.

For example, in the case of "gPTP" 21a of TSN hub 1, the gate confirmation start flag is set, so proceed to S06. On the other hand, in the case of "gPTP" task 21b of SN hubs 2, 5, 6, and 7, the gate start flag is not set, so proceed to S06.

S03-S05: Set the "ID" of the TSN hub that starts checking the gate status and the "ID" of the TSN hub that is the subject (end) of the check (the "ID" of the destination TSN hub) in the gate information (S03).

After that, a gate confirmation packet is generated (S04) and sent from the "gPTP" port 11 to the TSN hub to be confirmed (S05). For example, in the case of "gPTP" 21a of TSN hub 1, a gate confirmation packet with TSN hub 7 as the destination "ID" is generated and sent.

S06, S07: If a TSN hub other than the sender of S05 receives a TSN packet (S06), the "gPTP" task 21 of that TSN hub checks whether the TSN packet is a gate confirmation packet (S07).

If the confirmation result is that it is a gate confirmation packet, the process proceeds to gate confirmation packet reception processing in S08, but if not, the process proceeds to existing TSN packet reception processing in S09. For example, the "gPTP" task 21b of TSN hubs 2, 5, 6, and 7 receives the gate confirmation packet sent from TSN hub 1, and proceeds to gate confirmation packet reception processing in S08.

(2) Gate Confirmation Packet Reception Processing The gate confirmation packet reception processing in S08 will be described in detail with reference to Fig. 11. This processing is executed by the "gPTP" task 21 of the TSN hub that has received the gate confirmation packet as described above.

S11 to S13: When processing starts, the "gPTP" task 21 obtains the "ID" of the TSN hub to be confirmed from the received packet (gate confirmation packet) of S06 (S11).

Then, the acquired "ID" is compared with the "ID" of the own TSN hub (S12) to check whether they are the same (S13). If they are not the same, the process proceeds to S14, and if they are the same, the process proceeds to S16. For example, if the TSN hubs are 2, 5, and 6, the process proceeds to S14, and if the TSN hub is 7, the process proceeds to S16.

S14, S15: This process is performed by intermediate TSN hubs such as TSN hubs 2, 5, and 6 that relay the gate confirmation packet.

First, the "ID" of its own TSN hub and the "Meanpath" value on the receiving port 11 side of S06 are added to the data portion (received information) 25 of the received packet (gate confirmation packet) of S06 (S14).

Next, a gate confirmation packet is created based on the added reception information and sent from a "gPTP" port 12 other than the reception port (S15). For example, TSN hub 2 sends to TSN hub 5, TSN hub 5 sends to TSN hub 6, and TSN hub 6 sends to TSN hub 7.

S16 to S18: This process is executed by the TSN hub that is checking the gate status, such as TSN hub 7.

That is, the data portion 25 of the received packet of S06 is saved as gate information (S16), and the "ID" of the own TSN hub and the "Meanpath" value on the receiving port 11 side of S06 are added to the saved gate information (S17).

Then, a gate information notification (gate confirmation reception notification) is sent to the gate management task 23 (S18). For example, the "gPTP" task 21b of the TSN hub 7 sends a gate information notification to the gate management task 23b.

(3) Gate Management Main Processing The gate management main processing will be described in detail with reference to Fig. 12. This processing is executed by the gate management task 23 of the TSN hub.

S21, S22: That is, when processing starts, the gate management task 23 checks whether there is a gate information notification in S18 (S21, S22). If there is a gate information notification as a result of the check, the process proceeds to S23, whereas if there is no such notification, the process proceeds to S25.

S23, S24: The gate management task 23 generates a gate information packet based on the received gate information notification (S23) and sends the created gate information packet to the TSN hub that started the confirmation (S24). For example, the gate management task 23b of TSN hub 7 sends a gate information packet to TSN hub 1.

S25, S26: The gate management task 23 receives the TSN packet of S06 (S25) and checks whether a gate information packet has been received (S26). If the check shows that a gate information packet has been received, the process proceeds to gate information reception processing of S27, and if not, the process proceeds to S28.

S28-S30: The gate management task 23 checks whether the packet received in S25 is a gate status confirmation packet (S28).

If the result of the check is that it is a gate status confirmation request packet, proceed to gate status confirmation request processing in S29, otherwise proceed to S30.

In S30, it is confirmed whether the packet received in S25 is a gate status confirmation response packet. If it is a gate status confirmation response packet, the process proceeds to the gate status confirmation response process in S31, but if not, the process ends.

(4) Gate Information Reception Processing The gate information reception processing in S27 will be described in detail with reference to FIG.

S41 to S43: When processing starts, the gate management task 23 obtains the "ID" of the TSN hub that will start the check from the data portion 25 of the received packet in S25 (S41).

Then, the acquired "ID" is compared with the "ID" of the own TSN hub (S42). If the comparison shows that the "ID" is the same, the process proceeds to S44, but if they are not the same, the process ends (S43).

S44, S45: The gate management task 23 saves the data portion 25 of the received packet (only after the addition in S14) as gate information (S44), and obtains the ID of the TSN hub to be confirmed from the saved gate information (S45).

Then, a gate status confirmation request packet is generated (S46), and the generated gate status confirmation request packet is sent to the TSN hub of the "ID" to be confirmed (S47), and the process ends.

For example, the gate management task 23a of TSN1 obtains the "ID" of the TSN hub 7 from the stored gate information, generates a gate status confirmation request packet, and transmits the generated gate status confirmation request packet to the TSN hub 7.

(5) Gate Status Confirmation Request Processing The gate status confirmation request processing of S29 will be described in detail with reference to FIG.

S51 to S53: When processing starts, the gate management task 23 obtains the ID of the destination TSN hub from the data portion 25 of the received packet in S25 (S51).

Then, the acquired "ID" is compared with the "ID" of the own TSN hub (S52). If the comparison shows that the "ID" is the same, the process proceeds to S54, but if not, the process ends (S53).

S54 to S57: The gate management task 23 calculates the reception time of the received packet of S25 (S54). After this calculation, it obtains the "ID" of the sending TSN hub from the data portion 25 of the received packet (S55) and generates a gate status confirmation response packet that describes the reception time (S56).

The gate status confirmation response packet generated here is sent to the TSN hub having the "ID" of S55 (S57), and the process ends. For example, the gate management task 23b of the TSN hub 7 calculates the reception time of the gate status confirmation request packet (see equation (1) in Figures 7 and 8), and sends the calculated reception time to the TSN hub 1 as a gate status confirmation response packet.

(6) Gate Status Confirmation Response Processing The gate status confirmation response processing in S31 will be described in detail with reference to FIG.

S61: When processing begins, the gate management task 23 obtains the TSN hub reception time, the source TSN hub "ID", and the destination TSN hub "ID" from the data portion 25 of the received packet in S25.

S62: Calculate the ideal reception time to the TSN hub for the sender "ID" acquired in S61. For example, the gate management task 23a of TSN hub 1 calculates the ideal reception time to TSN 7 based on the "Meanpath" value of the gate information saved in S44 (see formula (2) in Figure 8).

S63, S64: The time difference between the reception time acquired in S61 and the ideal reception time calculated in S62 is calculated (S63). The time difference calculated here and the gate information saved in S44 are output, and the result of the gate status check is output (S64).

S65-S68: The "ID" of the next destination TSN hub (the TSN hub to be checked) is obtained (S65). After that, the gate information saved in S44 is referenced to check whether or not there is a TSN hub next to the "ID" obtained in S65 (S66).

If the check finds that the gate exists, a gate status check request packet is created (S67), and the created gate status check request packet is sent to the TSN hub that has the "ID" of the destination (the object to be checked) (S68).

For example, for TSN hubs 2, 5, and 6, if gate information is created in TSN 7, the ideal reception time of S62 can be calculated, so a gate status confirmation request packet is sent without sending a gate confirmation packet by "gPTP" task 21a.

This type of gate status confirmation system makes it possible to check the status of all gates between any selected TSN hubs. This makes it possible to determine the validity of the gates between TSN hubs, and also makes it easy to detect problem areas such as gate setting errors.

At this time, the creation of gate information (Figures 10 and 12) and confirmation of gate status (Figures 12 to 15) are executed in separate tasks 21 and 23, so the impact on the actual TSN processing is reduced. In particular, if gate information is created in TSN 7, then it is sufficient to check the gate status for TSN hubs 2, 5, and 6, which also reduces the processing burden.

The present invention is not limited to the above embodiment, and can be modified and implemented within the scope of the claims. For example, the present invention is not limited to checking the gate status from TSN hub 1 to TSN hub 7, and can check the gate status between any TSN hubs. The network configuration is not limited to that shown in FIG. 3, and can be any network configured with TSN hubs.

1 to 7: TSN hub 11, 12: port 14: gate 21, 21a, 21b: "gPTP" task 23, 23a, 23b: gate management task 25: data portion of gate status confirmation packet 26: gate information 30: confirmation result

Claims (12)

A system for checking the status of a gate that defines a schedule for packet transmission set in a TSN-enabled communication device, comprising:
The communication device that initiates the confirmation transmits a packet to and from the other communication device that is arbitrarily selected as the target of the confirmation,
Obtain gate information describing the "mean path value" between the two communication devices and the actual reception time to the other communication device;
Calculate the time difference between the ideal reception time based on the "Meanpath value" described in the gate information and the actual reception time,
A gate status confirmation system, characterized in that the status of the gate is confirmed based on the time difference. The intermediate communication device that transfers the first packet transmitted from one of the communication devices to the other communication device adds the "Meanpath value" of the receiving port to the data portion of the packet,
The other communication device that lastly receives the first packet returns gate information in which the "Meanpath" value on the reception port side is added to the data portion to the one communication device,
one of the communication devices transmits a second packet including a transmission time to the other of the communication devices after receiving the reply;
The other communication device that has received the second packet calculates an actual reception time based on a transmission/reception time of the second packet, and returns the calculated actual reception time to the one communication device;
The gate information confirmation system according to claim 1, characterized in that, after receiving the reply, one of the communication devices calculates the time difference between the ideal reception time based on the "Meanpath" value described in the gate information and the actual reception time of the reply. Sending a second packet to the intermediate communication device ;
The intermediate communication device that has received the second packet calculates the actual reception time based on a transmission/reception time of the second packet, and returns the calculated actual reception time to the one of the communication devices;
The gate information confirmation system according to claim 2, characterized in that, after receiving the reply, one of the communication devices calculates the time difference between the ideal reception time at the intermediate communication device based on the "Meanpath" value described in the gate information and the actual reception time. The gate status confirmation system according to any one of claims 1 to 3, characterized in that the gate status is confirmed depending on the magnitude of the time difference. The communication devices are time-synchronized using TSN's "gPTP"
5. The gate information confirmation system according to claim 1, wherein the actual reception time is calculated based on the synchronized time. 1. A method for verifying the status of a scheduled gate for packet transmission configured in a TSN-enabled communication device, comprising:
A step in which one of the communication devices initiating the confirmation transmits a packet back and forth between the communication device and the other communication device arbitrarily selected as the subject of the confirmation, thereby acquiring gate information describing a "mean path value" between the two communication devices and an actual reception time to the other communication device;
A step of calculating a time difference between an ideal reception time based on a "Meanpath value" described in the gate information and the actual reception time, and confirming a state of the gate based on the calculated time difference;
A gate state confirmation method comprising the steps of: A TSN-enabled communication device,
a function for checking a gate state that defines a schedule for packet transmission of the TSN in another arbitrarily selected communication device;
By sending a packet back and forth to another communication device arbitrarily selected as the subject of the confirmation, gate information describing a "mean path value" between the two communication devices and an actual reception time to the other communication device are obtained,
Calculate the time difference between the ideal reception time based on the "Meanpath value" described in the gate information and the actual reception time,
A communication device that checks the state of the gate based on the time difference. A "gPTP" task that transmits a first packet to another communication device and obtains the gate information from a reply from the other communication device;
a gate management task of transmitting a second packet including a transmission time to another of the communication devices, and calculating the time difference when an actual reception time based on the transmission and reception time of the second packet is received from the other of the communication devices;
8. The communication device according to claim 7, further comprising: The gate management task transmits the second packet to each intermediate communication device that forwards the first packet;
If an actual reception time based on the transmission and reception time of the second packet is returned from the intermediate communication device,
9. The communication device according to claim 8 , further comprising: a calculation unit for calculating a time difference between an ideal reception time at an intermediate communication device based on a "Meanpath" value of the gate information and the actual reception time of the returned message.
Another communication device according to claim 8,
a "gPTP" task that, upon receiving the first packet, returns gate information describing the "Meanpath" value of the port on which the first packet was received;
a gate management task that, upon receiving the second packet, calculates the actual receiving time and returns the calculated time;
A communication device comprising: 10. The intermediate communication device of claim 9,
a "gPTP" task that, when receiving the first packet, adds the "Meanpath value" of the port on which the first packet is received to the data portion of the first packet and transfers the first packet to another communication device;
a gate management task that, upon receiving the second packet, calculates the actual receiving time and returns the calculated time;
A communication device comprising: Time is synchronized by TSN's "gPTP",
The communication device according to any one of claims 7 to 11, wherein the actual reception time is calculated based on the synchronized time.

Images