KR101593504B1 - A datalink layer Reception Protocol for long range underwater networks - Google Patents

Abstract

The present invention relates to a datalink layer reception protocol for a long range underwater network. The present invention comprises: (a) an initial stage for a bus bar to set an initial communication path; (b) a normal stage for the bus bar and multiple cluster heads to communicate through the communication path; and (c) a final stage for the bus bar and the multiple cluster heads to finish the communication. The communication transmits and receives a packet-train type packet for transmitting the packet en bloc in a time division multiple access (TDMA). The packet receiving method of the packet-train train type comprises the steps of: (d) receiving the packet from Q by a packet-train lead algorithm to check the table of RX state and a header based on whether there is an error in the received packet, initializing the times of packet loss and the number of packets received based on whether reception is repeated to check if the received number of packets is the same as the total number of the packets based on whether newly created packets are received in the middle; and (e) checking if the table of RX state is updated or not and if the same is transmitted to an upper level based on reception signals are identical to a seq value of a beacon signal or are uplink data after receiving the packet train produced by the packet-train lead algorithm.

Description

[0001] The present invention relates to a data link layer reception protocol for an underwater long distance network,

The present invention relates to an underwater data link reception protocol, and more particularly, to a system and method for performing a medium access control, a time synchronization, and a routing, in order to efficiently perform communication in a poor communication environment underwater by transmitting and receiving a bus- The present invention relates to a data link layer reception protocol for an underwater long distance network using a packet train reception algorithm that can be commonly applied to various algorithms.

Today, there is growing recognition that the utilization of resources, energy and space possessed by the vast ocean is indispensable to mankind.

Various nodes may exist in the water. In this specification, a node means a communicable object. These nodes may be implemented in a mobile object such as an Automatic Underwater Vehicle (AUV), a submarine, a diver, or a fixed object.

The underwater environment is very harsh in communication environment compared to the ground environment. The signal transmission rate is very slow, the number of usable channels is very limited, and the usable bandwidth is very narrow. Despite this barren underwater environment, the demand for various forms of underwater communication is increasing rapidly.

The prior art document related to the present invention is Korean Patent Registration No. 10-1090402. In the prior art document, the intermediate base stations located on the surface of the water are divided into the data transmitted from the underwater nodes, TDMA1, which is an access method for transmitting data, and TDMA2, which is an access method for transmitting data to a terrestrial base station that controls itself during a time period in which underwater nodes divide and allocate time, Thereby improving the channel utilization rate by reducing the number of idle time slots, while overcoming the limitation of mobility that the TDMA has. The present invention proposes a hierarchical time division multiple access method for an underwater acoustic network.

However, considering the characteristics of the underwater long distance network, the prior art document still fails to overcome the problem that the yield due to saturation of data is lowered.

In addition, the prior art still does not overcome the problem of data loss or corruption due to collision when underwater nodes receive data simultaneously due to long propagation delay time in underwater environment.

KR 10-1090402 B

SUMMARY OF THE INVENTION The present invention has been made to solve the problems of the prior art as described above, and it is an object of the present invention to provide a packet train receiving method, a packet train receiving method, A data link layer reception protocol for an underwater long distance network including an algorithm, a reception protocol of a central control node, a reception protocol of a general node, and a common packet train reception algorithm.

To this end, a data link layer reception protocol for an underwater long distance network according to the present invention comprises: (A) an initial stage in which a bus line sets an initial communication path; (B) a normal stage in which the bus bar and the plurality of cluster heads communicate through the communication path; And (C) an end stage in which the bus and the plurality of cluster heads terminate communication, wherein the communication transmits and receives packets in a packet train format for collectively transmitting packets in a time division multiple access (TDMA) manner, (D) Receiving a packet from the queue by the packet train read algorithm, checking the header and the RX state table according to whether there is an error in the received packet, and if the received packet And determining whether the number of received packets is the total number of fragmented packets according to whether a new start packet has been received in the middle or not. And (E) receiving the packet train generated by the packet train read algorithm and determining whether the RX state table is updated and whether the response signal is the same as the Seq value of the beacon signal and whether it is the uplink data, And a step of determining whether or not it is determined.

Also, the data link layer reception protocol for underwater long distance network according to the present invention is characterized in that (A) the cluster head receives the first initial beacon signal and transmits a first initial response signal corresponding to the first initial beacon signal, 2) an initial stage for transmitting an initial beacon signal to receive a second initial response signal corresponding to the second initial beacon signal and setting a path; (B) the cluster head receives a first normal beacon signal and transmits a first normal response signal corresponding to the first normal beacon signal, and transmits the second normal beacon signal to correspond to the second normal beacon signal A normal stage receiving a second normal response signal; And (C) the cluster head receives a first end beacon signal and transmits a first end response signal corresponding to the first end beacon signal and transmits the second end beacon signal to the second end beacon signal Wherein the first initial response signal includes information of the second initial response signal and the first normal response signal includes information of the first normal response signal, Wherein the first end acknowledgment signal includes information of the second end acknowledgment signal, and the transmission and reception of the signals include transmission and reception of a packet in a packet train format for collectively transmitting packets in a time division multiple access (TDMA) (D) receiving the packet from the queue by the packet train read algorithm, and determining whether or not there is an error in the received packet, The state table is checked, and the number of received packets and the number of packet losses are initialized in accordance with whether or not the received packets are duplicated, and whether or not the number of received packets is the total number of fragmented packets ; And (E) receiving the packet train generated by the packet train read algorithm and synchronizing the time or setting up a timer according to whether the beacon signal is downlink data or the type of the beacon signal, and whether or not the packet train is the last hop And transmits the packet to the upper layer after correcting the beacon signal or the downlink data or corrects the downlink data, the uplink data or the response signal according to the type of the address of the cluster head And then transmitting or dropping the packet to an upper layer.

The features and advantages of the present invention will become more apparent from the following detailed description based on the accompanying drawings.

Prior to that, terms and words used in the present specification and claims should not be construed in a conventional and dictionary sense, and the inventor may properly define the concept of the term in order to best explain its invention It should be construed in accordance with the meaning and concept consistent with the technical idea of the present invention.

According to various embodiments of the present invention, it is possible to improve the performance of a poor underwater network communication system by reducing the message overhead in transmission and reception of a packet train type in a long distance underwater network and reducing the complexity of the reception algorithm of the entire network protocol.

Therefore, according to the various embodiments of the present invention, ultimately, an underwater network can be efficiently configured to facilitate marine exploration and resource harvesting, thereby enhancing the national interest.

1 is an exemplary diagram illustrating a concept of a data link layer reception protocol for an underwater long distance network according to an embodiment of the present invention;
FIG. 2 is a flowchart illustrating in detail an initialization stage (S110) of a bus (CS) data link protocol according to an embodiment of the present invention;
3 is an exemplary diagram showing an example of a packet of TX I_BEACON according to an embodiment of the present invention;
FIG. 4 is a flowchart for showing in detail a normal stage S120 of a CS (Command Ship) data link protocol according to an embodiment of the present invention.
5 is an exemplary diagram showing an example of a packet of N_BEACON according to an embodiment of the present invention;
FIG. 6 is a flowchart for illustrating in detail the end stage (S130) of a bus (CS, Command Ship) data link protocol according to an embodiment of the present invention;
FIG. 7 is an exemplary diagram showing a structure of a packet for T_BEACON according to an embodiment of the present invention; FIG.
FIG. 8 is a flowchart illustrating a packet train read algorithm of a CS (Command Ship) data link protocol according to an embodiment of the present invention in detail. FIG.
9 is a flowchart illustrating a packet processing algorithm of a CS (Command Ship) data link protocol according to an embodiment of the present invention in detail.
FIG. 10 is a flowchart showing an initialization stage (S210) of a data link protocol of a cluster head (CH) among a data link layer reception protocol for an underwater long distance network according to an embodiment of the present invention;
11 is a flowchart showing a normal stage S230 of a data link protocol of a cluster head (CH, Cluster Head) among data link layer reception protocols for an underwater long distance network according to an embodiment of the present invention.
FIG. 12 is a flowchart showing an end stage (S250) of a data link protocol of a cluster head (CH) among a data link layer reception protocol for an underwater long distance network according to an embodiment of the present invention;
13 is a flowchart illustrating a packet processing algorithm of the cluster head data link protocol in detail according to an embodiment of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS The objectives, specific advantages, and novel features of the present invention will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which: FIG. It should be noted that, in the present specification, the reference numerals are added to the constituent elements of the drawings, and the same constituent elements are assigned the same number as much as possible even if they are displayed on different drawings. Also, the terms "first "," second ", and the like are used to distinguish one element from another element, and the element is not limited thereto.

Also, the singular forms as used below include plural forms unless the phrases expressly have the opposite meaning. Throughout the specification, when an element is referred to as "including" an element, it means that it can include other elements as well, without departing from the other elements unless specifically stated otherwise.

The same reference numerals are given to the same members in Figs. 1 to 13.

The basic principle of the present invention is to generate a packet of a signal transmitted and received by a bus and a cluster head in a form of a packet train that is easy to collectively transmit, and to set a time when a transmission and reception of a signal is inactive to a sleep mode.

First, the cluster head (CH, Cluster Head) used in the embodiment of the present invention refers to a mobile node moving in the water as a concept relative to a CS (Command Ship).

In the following description of the present invention, detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

Before describing the present invention in detail, the parameters described for explaining the present invention will be defined as the following [Table 1] Parameter definition 1 to [Table 2] Parameter definition 2.

parameter Justice Normal

Number of network hops

Total number of CH

Hop number (

)

Node identification number (

), CS:

, CH:

The hop number of the node (

), CS:

, CH:

,

hop

The sub-hop number (

)

Inter-hop group number (

)

Group of hops that can be sent at the same time

Arbitrary hop

Top

Group of sub-hops

Arbitrary hop

Child

Group of sub-hops

Number of CH per hop
(

)

hop

, Sub hop

Number of CHs in
(

)

hop

, Sub hop

My CH Identification Number (

)

Number of failed responses

Failed response default value

Number of packets received in one packet train

Number of pkt losses occurred in one packet train

The number of consecutive empty queues during a single PTRA

Maximum value of Time setting

hop

, Sub hop

In

The propagation delay time when the CH sends the packet to the CH that is the least distant from its communication radius

hop

, Sub hop

In

The propagation distance when the CH sends the packet to the CH that is the least distant from its communication radius

MAC frame transmission time

Guard time (considering switching time, packet processing time)

Inter hop count

, Hop

, Sub hop

In

Time offset (TO)

CS, cycle period in which all CHs transmit data

Initial time reference point

Current time packet

hop

The total number of packets the CH can send at the maximum at one time

hop

The size of the data that the CH can send at the maximum at one time

hop

The size of the data sent by the CH in

Uplink, downlink data size that can be sent in one MAC frame

Uplink Number of CHs to be transmitted to uplink referring to route_table

Length of the header in the packet train MAC frame

Length of header in packet train first MAC frame

Length of the payload in the packet train MAC frame

Packet train Length of the payload in the first MAC frame

Packet control number

Total number of fragmented packets

The fragment number of the fragmented packet

About time synchronization

Sequence number per packet (

) Routing

Address of Next Hop CH to be forwarded referring to Route_table

CH address for unicast data packets sent by CS

hop count

Overall iso-spacing indicator of the routing path

CH

Location of

CH

Uplink data

CS's downlink data

Packet train start packet indicator

CRC value

Number of significant bits

Invalid bits in the packet

Before describing the present invention in detail, the updated contents of the tables described for explaining the present invention will be defined as the update contents of the following table.

Before describing the present invention in detail, before describing the present invention in detail, among the abbreviations used for explaining the present invention, I is an initialization stage and is an abbreviation of Initialization . And N is an abbreviation of Normal, which means a signal transmitted and received in a normal operation stage. Also, T is an abbreviation of Terminal, which means a signal transmitted and received at a terminal stage.

And BEACON or beacon is synonymous with beacon signal, and RESPONSE or response is synonymous with response signal.

Finally, Tx is used as the meaning of transmission and Rx is used as the meaning of reception.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is an exemplary diagram illustrating a concept of a data link layer reception protocol for an underwater long distance network according to an embodiment of the present invention.

The concept of a data link layer reception protocol for an underwater long distance network according to an embodiment of the present invention will be described with reference to FIG.

The concept of a data link layer reception protocol for an underwater long distance network according to an embodiment of the present invention will be briefly described.

First, the MAC (Media Access Control) of the bus and the cluster head according to the embodiment of the present invention is divided into three stages as an initialization stage, a normal stage, and a final stage.

Here, it is assumed that all bus lines (CS, Command Ship) can know their positions and cluster head (CH, Cluster Head) can know the position of bus line (CS).

In particular, the bus (CS) is located at the center of the network and has little movement.

It is assumed that the bus line (CS) and the cluster header (CH) know the maximum multi-hop (m).

At this time, the bus line CS controls the long distance within the communication radius (30 km, 1hop), and controls the cluster header CH through the long-distance relay communication (multi-hop) at the ends other than the communication range of the bus line CS.

The present invention performs communication between the bus (CS) and the cluster header (CH) using a data link layer reception protocol for underwater long distance networks.

Particularly, the bus line CS and the cluster head CH are a protocol for fragmenting packets of transmission / reception data and configuring the packets in a packet train manner and transmitting / receiving them collectively.

Since the data link layer reception protocol for the underwater long distance network according to the embodiment of the present invention uses the propagation delay, the cluster header CH can simultaneously transmit without collision.

On the other hand, the sleep mode is set during a waiting time when communication is inactivated, and the wake mode is set during a communication time when communication is activated.

The data link layer reception protocol for the underwater long distance network according to the present invention includes a data link protocol of a CS (Command Ship) for controlling an entire network and a step change according to a situation, and a processing protocol based on a reception beacon (X_BEACON) And the data link protocol of the head (CH, Cluster Head).

Particularly, the data link protocol of the bus CS and the cluster head CH is an initialization stage in which the bus CS initializes the network and reconfigures the network path after the initial stage, And a terminal stage for terminating all communications and returning the cluster heads (CH) to the cluster heads (CHs), are divided into three stages, respectively.

The data link protocol of the bus (CS, Command Ship)

First, in the initialization stage of the bus, parameters are set, a beacon is transmitted, a response is received, and a path is set. Here, the starting point and the offset are set when the beacon of the bus is transmitted, and the response is received by waiting for a preset time. When the route setting is completed, confirm whether or not the route setting is completed.

The initialization stage of the CS (Command Ship) for controlling the entire network among the data link layer reception protocols for the underwater long distance network according to the present invention and for changing the step according to the situation will be described in detail.

CS (Command Ship) Data link protocol initial stage

2 is a flowchart illustrating in detail an initialization stage (S110) of a bus (CS, Command Ship) data link protocol according to an embodiment of the present invention.

Referring to FIG. 2, an initialization stage S110 of a CS (Command Ship) data link protocol according to an embodiment of the present invention includes a step S111 in which a bus transmits an initial beacon signal, (B) determining whether the set time for waiting for the initial response signal has expired in step S113; (c) in step (c), if the set time has expired A step S114 of determining whether all the initial response signals of the plurality of cluster heads have been received, and a step S115 of setting a communication path between the bus and the plurality of cluster heads when all the initial response signals are received in step (d) ).

The initialization step (S110) of the bus (CS, Command Ship) data link protocol according to the embodiment of the present invention configured as shown in FIG. 2 will be described in detail as follows.

First, the bus transmits I_BEACON through a TX I_BEACON path (S111).

I_BEACON is generated according to the following procedure.

How to create I_BEACON for bus

1. First, the packet header value of I_BEACON is determined by the following procedure.

a. In order to determine the packet header value, a time offset (BEACON and RESPONSE time offset (TO)) of BEACON and RESPONSE is set. In this case, the time offset is set in consideration of necessary position information and maximum payload length.

b. Thereafter, the CS BEACON start time, the CH BEACON start time, and the CH RESPONSE start time are determined.

c. Next, the route start time and the route period are determined.

d. Finally, set Seq and P values sequentially.

2. If the packet header value is determined by this procedure, I_BEACON packet train is configured.

a. If P> P _{MAC, the} packet is fragmented and then LEN is set.

b. Where LEN is determined using Equation (1) and Equation (2).

c. Then, FN, C _sum , and TS are set in the fragmented packet.

d. If P ≤ P _{MAC, the} packet is not fragmented and LEN = 1 and FN = 1 are set. However, C _sum and TS value are set in the packet.

e. The generated TX I_BEACON packet is composed of a header and a payload as shown in FIG.

3 is an exemplary diagram illustrating an example of a packet structure for TX I_BEACON according to an embodiment of the present invention.

Referring to FIG. 3, CN of the header is 1 (I_BEACON), Seq is set to 0 at start, and Seq = 0 is set. The next TX I_BEACON is Seq = 1, and h _i and i are set to zero. On the other hand, I_BEACON start time, BEACON time offset, I_RESPONSE start time, RESPONSE time offset, Route start time and Route period information are sequentially generated in the payload.

f. When a packet for I_BEACON is generated in this way, I_BEACON is broadcasted downlink from 1 hop to m-hop at time t ₀ .

g. Thereafter, the CS IB_table is updated. In this case, the update items are t ₀ , t _IB , t _IR , T _B (h, k, j), T _R (h, k, j), T _CS , t _rout , T _route , Seq.

h. Finally, a timer up to T _CS is set to end the step S111.

Upon completion of step S111, I_RESPONSE is received and processed through the RX I_RESPONSE path (S112). Hereinafter, the processing method of the bus line for the received I_RESPONSE will be described in detail as follows.

How to handle bus I_RESPONSE

1. First check the header of the received packet and check whether there is an error in the C _sum value. If an error occurs, drop the received packet and if no error occurs, t _c Check the value.

2. Drop the received packet if t _C > t ₀ + T _CS , otherwise check h _i value.

3. Drop the packet if the hop number h _i is lower than the hop number of the bus, otherwise check i.

4. If it is confirmed with the node identification number of the cluster head that the i value is not received, it is determined that the information of the new cluster head is received.

5. Save the received packet and update the CS IR_table accordingly. However, if the i value is determined to be the information of the cluster head that has already been received, the FN value is confirmed.

6. If the FN value is equal to the LEN value, the payload is analyzed, h _i , i, Pos _i information of the cluster heads to be delivered are obtained, and step S 112 ends while updating the CS IR_table.

If the FN and LEN values are not the same, store them in the packet buffer and update the CS IR_table.

The update items of the CS IR_table are N _RES , FN, LEN, h _i , i, and Pos _i .

In the next step, it is determined whether the set time of the set timer has expired (S113).

If the time has not expired, the procedure returns to step S112 until the expiration date is reached, and if the set time of the timer expires, the flow advances to step S114 to check whether all cluster heads have responded.

The reason for setting the time of the timer is to consider the propagation delay time.

If the set time of the timer has expired, it is determined in step S114 whether all cluster heads have responded (S114).

If all of the cluster heads have not responded, the flow returns to step S111 to proceed from the beginning again.

If all the cluster heads have responded, the flow advances to the next step, the Route Determination Phase (S115). Here, the path setting phase is a step of setting a communication path between the bus and the cluster head.

If it is determined in step S116 that all paths have been set in step S115, the process returns to step S111 to repeat the procedure. If it is determined that the path setting is not completed If it is completed, it moves to the normal operation stage 120.

Normal (CS, Command Ship) data link protocol normal stage

First, at the normal stage of the bus, a beacon is transmitted and a corresponding response is received. This is to check whether the cluster head is alive or not.

4 is a flowchart illustrating in detail a normal stage S120 of a CS (Command Ship) data link protocol according to an embodiment of the present invention.

Referring to FIG. 4, a normal stage S120 of a CS (Command Ship) data link protocol according to an embodiment of the present invention includes a step S121 in which a bus transmits a normal beacon signal to a plurality of cluster heads, A step S122 of receiving a normal response signal of a plurality of cluster heads corresponding to a beacon signal, a step S123 of determining whether a set time for waiting for a normal response signal has expired in a step S123, and a step (S124) if the number of times the response time of the response signal is exceeded exceeds the predetermined number of response failure times.

The normal stage 120 according to the embodiment of the present invention constructed as shown in FIG. 4 will now be described in detail.

First, N_BEACON is transmitted through the TX N_BEACON phase (S121).

N_BEACON is generated according to the following procedure.

How to create bus N_BEACON

1. First, perform the following procedure to determine the time parameter.

a. First, the CS BEACON start time, the BEACON start time, and the RESPONSE start time are determined.

b. Then, the Seq value and the P value are sequentially determined.

2. Once the time parameters are determined in this way, configure N_BEACON as a packet train. Here, the method of fragmenting a packet in the construction of the packet train has been described in detail in 2 a to 2 d of the I_BEACON generation method of the bus described above, and the details thereof will be omitted.

3. The packet of N_BEACON set as described above is composed of a header and a payload as shown in FIG.

5 is an exemplary diagram showing an example of a packet of N_BEACON according to an embodiment of the present invention.

5, the header the CN 5 (N_BEACON) and, Seq, h _i, i, FN, LEN, Csum, when the TS is set in sequence, payload N_BEACON start time, t _NB, and N_RESPONSE start time , t _NR are set.

4. When N_BEACON is generated in this way, N_BEACON is broadcasted downlink from 1 hop to m-hop at t ₀ .

5. Thereafter, CS NB_table is updated with the items t ₀ , t _NB , t _NR , T _CS , Seq value.

6. Finally, step S121 is ended by setting a timer up to T _CS .

Upon completion of step S121, N_RESPONSE is received and processed through the RX N_RESPONSE phase (S122). The processing method for RX N_RESPONSE received here will be described in detail as follows.

How to handle bus N_RESPONSE

1. Check the C _sum value to check whether an error has occurred. Drop the received packet if an error occurred, and check the value of t _c if no error occurred.

2. Drop the received packet if t _C > t ₀ + T _CS , otherwise check SR value.

3. Drop the SR value if it does not exist, otherwise check the FN value.

4. If the FN and LEN values are the same, analyze the payload to obtain h _i , i, Pos _i , and DATA _i value information of the cluster heads to be delivered, and end step S 122 while updating CS NR_table.

Here, if the FN value and the LEN value are not the same, the packet buffer is stored and the CS NR_table is updated.

If the FN and LEN values are not the same, drop the packet.

Update items of CS NR_table include N _RES , FN, LEN, h _i , i, Pos _i , DATA _i .

In the next step, it is determined whether the set time of the set timer has expired (S123)

If it has not expired, step S122 is repeated until it expires, and if the set time of the timer expires, the NF _RES (S124).

NF _RES The value is NF _default The process returns to step S111 to repeat the procedure, and if not, it is determined whether to proceed to the terminal stage (S125).

If it is determined not to proceed to the end stage, the procedure described above is repeated from step S121.

End of bus (CS, Command Ship) data link protocol stage

First, at the end stage of the bus, a beacon is transmitted and a response is received in order to check whether the communication is completed or not.

6 is a flowchart illustrating in detail the end stage (S130) of a bus (CS, Command Ship) data link protocol according to an embodiment of the present invention.

6, the end stage S130 according to an embodiment of the present invention includes a step S131 of sending a bus end beacon signal to a plurality of cluster heads (S131), an end of a plurality of cluster heads corresponding to the end beacon signal (S133) of determining whether the set time has elapsed to wait for the normal response signal in step (b), and when the set time has expired in step (c), the response signal is received (S134) whether all of them have been received on the bus line.

The ending stage S130 according to the embodiment of the present invention will be described in detail with reference to FIG.

First, the bus transmits T_BEACON through the TX T_BEACON phase (S131).

T_BEACON is generated according to the following procedure.

How to create T_BEACON

1. Perform the following procedure to determine the priority time parameter.

a. First, the CS BEACON start time, the BEACON start time, and the RESPONSE start time are determined.

b. Then, the Seq value and the P value are sequentially determined.

2. Once the time parameters are determined in this way, T_BEACON is configured as a packet train. Here, the method of fragmenting a packet in the construction of the packet train has been described in detail in 2 a to 2 d of the I_BEACON generation method of the bus described above, and the details thereof will be omitted.

3. The T_BEACON packet thus configured is composed of a header and a payload as shown in FIG.

7 is an exemplary diagram illustrating a structure of a packet for T_BEACON according to an embodiment of the present invention.

7, the header, the CN 7 (T_BEACON) and, Seq, h _i, i, FN, LEN, C _sum, when the TS is set in sequence, payload T_BEACON start time, t _TB and T_RESPONSE start time , t _TR are set.

4. When T_BEACON is generated as described above, T_BEACON is broadcasted downlink from one hop to m-hop at t ₀ .

5. After this, CS TB_table is updated as t ₀ , t _TB , t _TR , T _CS , Seq value.

6. Finally, step S131 is ended by setting a timer up to T _CS .

Upon completion of step S131, RX T_RESPONSE is received and processed through the RX T_RESPONSE path (S132). Hereinafter, a processing method for the received RX T_RESPONSE will be described in detail.

bus RX  How to handle T_RESPONSE

1. Check the C _sum value to check whether an error has occurred. Drop the received packet if an error occurred, and check the value of t _c if no error occurred.

2. Drop the received packet if t _C > t ₀ + T _CS , otherwise check SR value.

3. Drop the SR value if it does not exist, otherwise check the FN value.

4. Step S122 ends with updating the CS TR_table if the FN value and the LEN value are not equal or the same or are stored in the packet buffer.

The items of CS TR_table that are updated at this time are FN, LEN, h _i , i.

In the next step, it is determined whether the set time of the set timer has expired (S133)

If it has not expired, step S132 is repeated until it expires. If the set time of the timer expires, it is determined whether all cluster heads have responded (S134).

If all the cluster heads have responded, the end stage is terminated. If not, the procedure returns to step S131 and the above-described procedure is repeated.

Packet train read algorithm for data link protocol (CS, Command Ship)

FIG. 8 is a flowchart illustrating in detail a packet train read algorithm of a CS (Command Ship) data link protocol according to an embodiment of the present invention.

The packet train read algorithm is an algorithm for reading one packet train from a queue of the physical layer in a reception mode and for initiating the initialization stage S110, the normal stage S120 and the end stage S130 of the data link protocol, .

In this case, even if a mode packet of the packet train is received or a part of the packet train is received using the packet loss information obtained from the physical layer, the process is performed.

Basically, it is performed until one packet train is read, but the queue (Que) is checked (S141) and it is determined whether or not the queue is continuously empty (S142).

이 되면 알고리즘이 종료된다.If the queue is consecutively empty, the EQ is incremented by '1' (S143). If the EQ is less than EQmax (S144), the process returns to step S141,

The algorithm terminates.

If there is a queue in step S142, the EQ is initialized to '0' (S145), the packet is received from the queue and temporarily stored in the BUF (S146), and it is determined whether there is an error in the received packet (S147).

If there is an error, the BUF is deleted (S151), and the flow returns to step S141. If there is no error, the header and the RX state table are checked (S148).

및 수신 시간 업데이트 정보, 패킷의 임시 저장 메모리 주소,

당 I_BEACON 또는 T_BEACON에 대한 CH별 응답 유무,

당 CH별 업링크 데이터(Upload Data) 송신 유무 등을 체크하고, 소정의 수신 시간 이후, 업데이트 정보를 삭제한다.That is, the RX state table

And receive time update information, a temporary storage memory address of the packet,

Whether there is a response by CH per I_BEACON or T_BEACON,

Whether there is transmission of upload data for each channel, and deletes the update information after a predetermined reception time.

이 되는지 여부를 판단하여(S149),

이 아닌 경우, 즉 중간에 새로운 시작 패킷이 수신된 경우에는 BUF를 삭제하고(S151) 단계(S141)로 회귀하고,

인 경우 중복 여부를 판단한다(S150).Start header

(Step S149)

If a new start packet is received in the middle, the BUF is deleted (S151), and the flow returns to step S141,

, It is determined whether or not they are duplicated (S150).

정보 등이 동일한 패킷 트레인은 중복이 되고, 유니캐스트(Unicast) 트래픽(IR, TR, UD, DD_unicast)의 경우

정보 등이 동일한 패킷 트레인은 중복이 된다.That is, in the case of broadcast (I_BEACON, T_BEACON, DD_broadcast)

Packet train having the same information is duplicated, and in case of unicast traffic (IR, TR, UD, DD_unicast)

Packet trains having the same information are duplicated.

)를 '1'로 초기화하고, 패킷 트레인에서 발생한 패킷 로스의 회수(

)를 '0'으로 초기화한다(S152).In step S, the BUF is deleted (S151), and the flow returns to step S141. If not, the number of packets received in the packet train (

) Is initialized to '1', and the number of packet losses generated in the packet train

) To '0' (S152).

)가 조각된 패킷의 총 개수(

)인지 여부를 판단하여(S153), 조각된 패킷의 총 개수(

)인 경우 동작을 종료하고, 조각된 패킷의 총 개수(

)가 아닌 경우 큐를 체크하여(S154) 패킷 로스가 있는지 여부를 판단한다(S156).Number of packets received on the packet train (

) Is the total number of fragmented packets (

) (S153), and determines whether the total number of the fragmented packets (

), The operation is terminated and the total number of fragmented packets (

, The queue is checked (S154) and it is determined whether there is a packet loss (S156).

) 및 패킷 로스의 회수(

)를 '1' 증가시켜(S157, S158) 패킷 트레인에서 수신한 패킷의 수(

)가 조각된 패킷의 총 개수(

)인지 여부를 판단한다(S153).If there is a packet loss, the number of packets received in the packet train (

) And the number of packet losses (

) Is increased by '1' (S157 and S158), and the number of packets received in the packet train (

) Is the total number of fragmented packets (

) (S153).

If there is no packet loss, the packet is read from the queue (Que) and temporarily stored in the BUF (S156), and it is determined whether there is an error in the packet (S161).

) 및 패킷 로스의 회수(

)를 '1' 증가시킨 후에(S157, S158) 단계(S153) 이후의 동작을 수행하고, 에러가 없는 경우 헤더 및 RX 상태 테이블을 체크한다(S163).If there is an error in the packet, after deleting the current packet from the BUF (S162), the number of packets received in the packet train

) And the number of packet losses (

(S157, S158) after the step S153, and if there is no error, the header and the RX state table are checked (S163).

이 되는지 여부를 판단하여(S164),

이 아닌 경우에는 현재 패킷을 BUF에 저장하고(S165), 패킷 로스의 회수(

)를 '1' 증가시킨 후에(S158) 단계(S153) 이후의 동작을 수행하고,

인 경우 BUF의 삭제 및 현재 패킷의 BUF 저장한 후(S166) 단계(S150) 이후의 동작을 수행한다.Start header

(Step S164)

, The current packet is stored in the BUF (S165), and the number of times of packet loss (

) Is incremented by '1' (S158), the operation after step S153 is performed,

, The BUF is deleted and the BUF of the current packet is stored (S166), and the operation after step S150 is performed.

Packet Processing Algorithm for Bus Link (CS, Command Ship) Data Link Protocol

9 is a flowchart illustrating a packet processing algorithm of a CS (Command Ship) data link protocol according to an embodiment of the present invention in detail.

The bus line packet processing algorithm is an algorithm for analyzing a packet train received from a packet train read algorithm (PTRA) and processing it on a case-by-case basis. The algorithm includes an initialization stage S110, a normal stage S120, (S130).

This algorithm is also processed when a mode packet of a packet train is received or only a part of it is received.

First, the packet train is received from the packet train read algorithm (PTRA) (S171), and it is determined whether it is I_BEACON or T_BEACON (S172).

If it is I_BEACON or T_BEACON, the BUF is deleted (S173), and it is determined whether the timer is terminated (S180). If the timer is not I_BEACON or T_BEACON, it is determined whether it is I_RESPONSE or T_RESPONSE (S174).

If the timer ends in step S180, the operation is terminated. If the timer has not ended, the flow returns to step S171.

If I_RESPONSE or T_RESPONSE in step S174, it is determined whether the transmitted I_BEACON or T_BEACON is the same as the Seq value in step S175. If they are the same, the RX state table is updated in step S176. If they are not the same, the BUF is deleted in step S173 ) The operation after step S180 is performed.

If it is not I_RESPONSE or T_RESPONSE in step S174, it is determined whether it is uplink data (S177).

In the case of the uplink data, the RX state table is updated and the packet is transmitted to the upper layer Q _{TX _DL_ UL} ( _{S 178} ). If the uplink data is not uplink data, the BUF is deleted (S 179) do.

The data link protocol of the cluster head (CH, Cluster Head)

Next, a cluster head (CH) for performing signal processing according to BEACON (X_BEACON) received from a command ship (CS) among data link layer reception protocols for underwater long distance networks according to the present invention, The data link protocol of the present invention will be described in detail.

Initialization of the data link protocol of the cluster head (CH, Cluster Head) stage

In the cluster head initialization stage, a beacon is transmitted, a response is transmitted, and a path is set. Here, time synchronization is performed when the beacon of the cluster head is transmitted, and the survival and location information is included in the response transmission.

10 is a flowchart showing an initialization stage (S210) of a data link protocol of a cluster head (CH) among a data link layer reception protocol for an underwater long distance network according to an embodiment of the present invention.

Referring to FIG. 10, an initialization stage (S210) of a data link protocol of a cluster head (CH, Cluster Head) among data link layer reception protocols for an underwater long distance network according to an embodiment of the present invention includes: (S212), comparing the first initial beacon signal with the maximum number of packets that can be sent at one time (S212), performing time synchronization with the time parameter (S213), comparing the current time If the initial beacon transmission start time does not exceed the sum of the hop h and the beacon time offset of j in the sub hop k in step S214, the second initial beacon signal is transmitted and the sleep mode (S215). If the current time is less than the sum of the transmission start time of the initial beacon, the hop h, and the beacon time offset of j in the sub hop k (S216), the second initial response (S217). If the current time is equal to the sum of the transmission start time of the initial beacon, the hop h, and the beacon time offset of j in sub-hop k (S218) (S220) of determining whether a first initial beacon signal is received for a predetermined period of time (S220), and when a first initial beacon signal is not received (S220) And setting a path (S222).

Wherein the second initial beacon signal is generated by signal processing the first initial beacon signal and the second initial response signal is generated by signal processing the first initial response signal. Therefore, if I_BEACON is the first initial beacon signal, I_BEACON generated by signal processing is the second initial beacon signal, and if I_RESPONSE is the first initial response signal, I_RESPONSE generated by signal processing becomes the second initial response signal.

Here, the signal processing procedure will be described later.

First, the cluster head receives I_BEACON through the RX I_BEACON path (S211).

The received I_BEACON is processed according to the following procedure.

Cluster head RX  How to handle I_BEACON

1. First, the header of the received I_BEACON is checked and processed in the following procedure.

a. C _sum And determines whether an error (err) has occurred. If an error has occurred, the received packet is dropped.

b. C _sum If there is no error in the value, check the value of Seq. If the value of Seq is not the same, discard the packet with the previous Seq value and store it in the packet buffer with count = 1. And performs a time synchronization phase. Time synchronization phase is to provide modified time information using information received from BEACON. As information that is specifically input is _{Seq, i, h i, FN} , LEN, TS. In this case, TS is the time information, which means that the bus or cluster head sends BEACON packets. When such information is input, corrected time information is output.

2. Seq value not equal, a drop in the received packet is determined h _i h _i is higher than their cluster head and high surface received packet.

3. If not, update the TS. Where TS update, h _i is to store only the TS value lower than their cluster head h _i.

4. Check if the FN value exists and drop the received packet if it exists.

5. If the FN value is not present, increment the packet count by one, store it in the packet buffer, and update the cluster head CH IB_table.

6. Here, the CH IB_table information is Seq, i, FN, LEN, TS, and count information.

When step S211 is performed as described above, it is determined whether count and LEN are the same (S212)

At this time, if count = LEN, a time parameter is acquired, time synchronization is performed, and CH IB_table is updated (S213).

The updates of CH IB_table is _{Seq, i, h i, FN} , LEN, TS, count, t IB, t IR, T B (h, k, j), t route, T route

On the other hand, the count LEN step returns to step S211.

Next, it is determined whether t _C > t _IB + T _B (h, k, j) (S214), and the flow returns to step S211.

On the other hand, if t _C > t _IB + T _B (h, k, j), I_BEACON processed in the TX I_BEACON phase is transmitted (S215).

How to handle TX I_BEACON of cluster head

1. The header is set using the received I_BEACON information in the following procedure, and the payload is set.

a. The information set to be the same as the received packet is CN, Seq, FN, and LEN, and h _i i, C _sum and TS are changed to the information of the cluster head itself.

b. Set the payload to be the same.

2. Update CH IB_table afterwards. At this time, t _IB , t _IR , Is _{T B (h, k, j} ), T R (h, k, j), t route, T route.

3. When the update is finished, t _IB + Broadcast TX I_BEACON until T _B (h, k, j).

4. Finally, by switching to sleep mode or power saving mode until t _IR time, power consumption is prevented.

Next, it is determined whether t _C <t _IR + T _R (h, k, j) (S215). If so, I_RESPONSE is received through the RX I_RESPONSE path and a sleep mode is set for a predetermined time S217).

That is, the sleep mode is t _IB + After the TX I_BEACON is broadcast until T _B (h, k, j), it is set until t _IR time.

The received RX I_RESPONSE is processed as follows.

Cluster head RX  I_ RESPONSE processing method

1. The head packet of the I _RESPONSE received first is treated in the following procedure.

a. Check the C _sum value to check whether an error has occurred. If an error occurs, drop the received packet and if no error occurs, t _c Check the value.

b. If t _C > t _IR + T _R (h, k, j), the packet is dropped. If t _C > t _IR + T _R (h, k, j), the RESPONSE time offset value is checked.

c. If there is no RESPONSE time offset value, drop the packet and check the value of h _i if it is.

d. If h _i is lower than h _i of the cluster head that received the current packet, discard the packet, otherwise check i.

e. As a result of checking the i value, if it is judged that it is a new cluster head, it is stored in the packet buffer and CH IR_table is updated. If it is determined that the cluster head is not a new cluster head after confirming the i value, the FN value is confirmed.

f. If FN = LEN, the CH IR_table is updated by acquiring the h _i , i, and Pos _i information of the cluster head to analyze and transfer the payload.

g. If FN LEN, store it in the packet buffer and update CH IR_table.

h. The items to be updated here are FN, LEN, h _i , i, Pos _i .

On the other hand, it is determined whether t _C = t _IR + T _R (h, k, j) (S 218)

If t _C = t _IR + T _R (h, k, j), I_RESPONSE is transmitted through the TX I_RESPONSE phase (S219). The following describes the generation of I_RESPONSE to be transmitted by the cluster head.

How to Create TX I_RESPONSE on Cluster Head

1. First, the header and payload are set in the following procedure.

a. CN of the header is set to 2, and Seq is set to be equal to the received I_BEACON value. On the other hand, h _i , i, FN, LEN, and C _sum values are changed to their own numbers.

b. The payload contains updated h _i , i, Pos _i information and its own location information in the received I_RESPONSE. The packet of the thus configured I_RESPONSE is illustrated in FIG. 12 is an exemplary diagram showing a packet structure of I_RESPONSE generated by a cluster head.

2. When a packet is generated in this way, broadcast I_RESPONSE at time t _IR + T _R (h, k, j).

3. When broadcasting ends, remove the received I_RESPONSE.

4. Then t _route - t _IR - T Set the timer at _R (h, k, j) time.

When the step S218 is finished, it is checked whether the predetermined time has expired (S220). At this time, the procedure returns to step S211 until the time of the timer expires, and the above procedure is repeated.

If it is determined that the I_BEACON has been received (S221), the flow returns to step S211 to perform the above-described procedure. If the reception is not confirmed, a route is determined (Route Determination Phase) (S222).

Normal of data link protocol of cluster head (CH, Cluster Head) stage

In the normal stage of the cluster head, the beacon is transmitted and the response is transmitted in order to provide its survival information as a bus.

In particular, time synchronization is performed before the transmission of the beacon.

11 is a flowchart showing a normal stage S230 of a data link protocol of a cluster head (CH, Cluster Head) among data link layer reception protocols for an underwater long distance network according to an embodiment of the present invention.

11, the normal stage S230 of the data link protocol of the cluster head (CH, Cluster Head) among the data link layer reception protocols for the underwater long distance network according to the embodiment of the present invention receives the first stationary beacon signal In step 231, it is determined whether or not the first normal beacon signal is the same as the maximum number of packets that can be sent at one time (S232) (Step S234), a second normal beacon signal is transmitted and a sleep mode is set for a predetermined time (step S234) S235), a step S237 of receiving a second normal response signal if the current time is less than the sum of the transmission start time of the normal beacon and the beacon time offset of j in the hop h and sub hop k (S236), and When the current time is equal to the sum of the transmission start time of the normal beacon and the beacon time offset of j in the hop h and the sub hop k, the first normal response signal corresponding to the first normal beacon signal is transmitted (S238) .

Here, the second normal beacon signal is generated by signal processing the first normal beacon signal, and the second normal response signal is generated by signal processing the first normal response signal. Therefore, if N_BEACON is the first normal beacon signal, N_BEACON generated by signal processing is the second normal beacon signal, and if N_RESPONSE is the first normal response signal, N_RESPONSE generated by signal processing becomes the second normal response signal.

Here, the signal processing procedure will be described later.

First, N_BEACON is received through the RX N_BEACON phase (S231).

The received N_BEACON checks the header and processes it as follows.

Cluster head RX  How to handle N_BEACON

1. First check the C _sum value to check whether an error has occurred.

a. If an error occurs, drop the packet. If no error occurs, check the Seq value.

b. If the Seq values are the same, check the hi value. If the Seq values are not the same, discard packets having the previous Seq value, increment the count by 1, and store the packets in the packet buffer. Thereafter, CH NB_table is updated and a time synchronization phase is performed. Since the time synchronization has been described above, the details thereof will be omitted.

c. If the hop number h _i is higher than the hop count of the cluster head itself, the packet is dropped, and if the hop number h _i is lower, the TS is updated. That is, the hop number is updated to store only TS values lower than the hop number. Thereafter, the FN value is confirmed.

d. If there is an SR, it checks the FN value, and if there is no SR, drops the packet.

e. If the FN value is present, check the FN value, otherwise increase the packet count by 1 to save the packet and update the CH NB_table.

The CH NB_table updates is _{Seq, i, h i, FN} , LEN, TS, count.

After step S231 is performed, it is determined whether count = LEN (S232).

On the other hand, if count = LEN, a timing parameter is acquired, time synchronization is performed (S233), and the CH NB_table is updated (S233). The updated item is _{Seq, i, h i, FN} , LEN, TS, count, t NB, t NR.

If the count is LEN, the process returns to step S221 to repeat the above-described procedure.

It is determined that the following procedure is _{a, t c> t NB + T} B (h, k, j) (S234).

t _c > _NB + T _B (h, k, j), the process returns to step S231 and the above procedure is repeated.

If it is not t _C > t _NB + T _B (h, k, j), N_BEACON processed by the following procedure is transmitted via TX N_BEACON phase (S235).

TX N_BEACON The generation method of N_BEACON transmitted through the phase will be described as follows.

How to create TX N_BEACON for cluster head

1. First, the header is set using the received N_BEACON information.

a. Header is set by CN, Seq, FN, LEN of the received N_BEACON information is set equal to and, h _i is a his h _i cluster head, i also changes to their i and, C _sum, TS also changes.

b. The payload then sets the header to be the same as the received N_BEACON information.

2. Once the header and payload are set like this, CH NB_table is updated. The update items are t _NB and t _NR .

3. Then broadcast N_BEACON at time t _NB + T _B (h, k, j).

4. Finally, switch to sleep mode or sleep mode until t _NR .

That is, the sleep mode is set up to the time t _NR after broadcasting N_BEACON at time t _NB + T _B (h, k, j).

When step S235 ends, t _C <t _{NR +} T _R (h, k, j) (S236).

t _C If it is & lt _; t _{NR +} T _R (h, k, j), N_RESPONSE is received through the RX N_RESPONSE phase (S237). The received N_RESPONSE is processed as follows.

Cluster head RX  How to handle N_RESPONSE

The procedure for receiving N_RESPONSE over the RX N_RESPONSE phase is as follows.

1. First, the header of the received N_RESPONSE is checked and processed as follows.

a. Check C _sum value, drop packet if error occurs, otherwise t _c Check the value.

b. If t _c > t _NR + T _R (h, k, j), drop the packet and check the SR value.

If there is an SR value, the FN value is checked. If the SR value does not exist, the packet is dropped.

c. If the FN value is equal to the LEN value, the payload is analyzed to acquire the value of h _i , i, Pos _i , and DATA _i of the CHs to be transmitted, and then the CH NR_table is updated.

d. On the other hand, if the FN value is not equal to the LEN value, the packet buffer is stored and CH NR_table is updated.

e. At this time, the update items of CH NR_table are FN, LEN, h _i , i, Pos _i , and DATA _i .

If it is determined that the step S224 is carried _{out, t c = t NR + T} R (h, k, j) (S238)

If t _c = t _NR + T _R (h, k, j), then N_RESPONSE is transmitted via TX N_RESPONSE phase (S239).

The procedure for generating N_RESPONSE sent over the TX N_RESPONSE phase is as follows.

How to generate TX N_RESPONSE for cluster head

1. First, set the header and payload.

a. The header is set in the same manner as I_BEACON described above.

b. The payload contains updated h _i , i, Pos _i information and its own location information in the received N_RESPONSE.

c. Thus configured N_RESPONSE packet CN constituting the header 6 (N_RESPONSE), cluster head in _{Seq, h i, i, FN} , LEN, the Pos _i, the payload consists of a C _sum, its location information in the sub- I, Pos _i , and DATA _i , which are information of the channels CH.

d. Thereafter, N_RESPONSE is broadcasted at time t _NR + T _R (h, k, j), and then the received N_RESPONSE is removed.

On the other hand, if _{t c t NR + T R (} h, k, j) and returns to step S231.

Termination of the data link protocol of the cluster head (CH, Cluster Head) stage

At the end stage of the cluster head, communication with the bus is terminated by transmitting a beacon and sending a response.

12 is a flowchart showing an end stage (S250) of a data link protocol of a cluster head (CH) among a data link layer reception protocol for an underwater long distance network according to an embodiment of the present invention.

Referring to FIG. 12, the end stage (S250) of the data link protocol of the cluster head (CH) among the data link layer reception protocols for the underwater long distance network according to the embodiment of the present invention receives the first end beacon signal (Step S251). If it is determined that the first end beacon signal is equal to the maximum number of packets that can be transmitted at one time (S252), the step S253 performs time synchronization with the time parameter (S253) If it is less than the sum of the transmission start time of the beacon, the hop h, and the beacon time offset of j in the sub hop k (S254), a second end beacon signal is transmitted and a sleep mode is set for a preset time (S255). If the current time is less than the sum of the transmission start time of the end beacon, the hop h, and the beacon time offset of j in the sub hop k (S256), a step S257 of receiving the second end response signal, If the current time is equal to the sum of the transmission start time of the end beacon, the hop h, and the beacon time offset of j in the sub hop k (S258), transmitting the first end response signal corresponding to the first end beacon signal (S259).

Wherein the second end beacon signal is generated by signal processing the first end beacon signal and the second end response signal is generated by signal processing the first end response signal. Therefore, if N_BEACON is the first end beacon signal, N_BEACON generated by signal processing is the second end beacon signal, and if N_RESPONSE is the first end response signal, N_RESPONSE generated by signal processing becomes the second end response signal.

Here, the signal processing procedure will be described later.

First, T_BEACON is received through the RX T_BEACON phase (S251).

The received T_BEACON is processed in the following procedure by checking the header.

Cluster head RX  T_BEACON processing method

1. First check the C _sum value of the header to see if an error occurred.

a. Drop the packet if an error occurs, otherwise check Seq value.

b. If the Seq value is the same, check the value of h _i , otherwise discard packets with Seq value and store the count in the packet buffer as 1. Then, the CH TB_table is updated and a time synchronization phase is performed. Since the time synchronization has been described above, the details thereof will be omitted.

c. Next, if the hop number h _i is higher than the hop number h _i of the current cluster head, the packet is dropped. If the hop number h _i is lower, the TS is updated. That is, the hop number is updated to store only TS values lower than the hop number. Thereafter, the FN value is confirmed.

d. Then, the presence of the SR value is confirmed, and if the SR value exists, the FN value is confirmed. If the SR value does not exist, the packet drops.

e. If the FN value is present, the FN value is checked. If the FN value does not exist, the count is incremented by 1 to store the packet and update the CH TB_table.

Wherein the update of the entry is a value CH TB_table _{Seq, i, h i, FN} , LEN, TS, count.

After performing step S251, if count = LEN (S252), a timing parameter is obtained, a time synchronization phase is performed, and a CH TB_table is updated (S253).

The update items of the CH TB_table are Seq, i, h _i , FN, LEN, TS, count, t _TB , and t _TR .

If the count is LEN, the process returns to step S221 to repeat the above-described procedure.

Determines whether the next _{procedure, t c> t TB + T} B (h, k, j) (S254).

If t _c > t _TB + T _B (h, k, j), the procedure returns to step S221 and the above procedure is repeated.

If t _c > t _TB + T _B (h, k, j), T_BEACON is transmitted via the TX T_BEACON path (S 255).

A procedure for generating T_BEACON to be transmitted via TX N_BEACON phase will be described as follows.

How to Create TX T_BEACON for Cluster Head

1. First, a header is set using the received T_BEACON information.

a. The header sets CN, Seq, FN, and LEN of the received T_BEACON information to the same, h _{i changes} its own h _i , i changes its own i, and C _sum and TS change.

b. Then, the setting of the payload sets the header to be equal to the received T_BEACON information.

2. Once the header and payload are set in this manner, CH TB_table is updated. At this time, t _TB and t _TR are update items.

3. Then broadcast T_BEACON at time t _TB + T _B (h, k, j).

Finally, it switches to sleep mode or sleep mode until t _TR time.

That is, the sleep mode is set to t _TR after broadcasting T_BEACON at time t _TB + T _B (h, k, j).

When step S255 ends, t _C <t _{NR +} T _R (h, k, j) (S256).

t _C If it is & lt _; t _{NR +} T _R (h, k, j), T_RESPONSE is received via the RX T_RESPONSE phase (S257).

The procedure for receiving T_RESPONSE through the RX T_RESPONSE phase is as follows.

Cluster head RX  How to create T_RESPONSE

1. First, the header of the received T_RESPONSE is checked and processed as follows.

a. Check C _sum value, drop packet if error occurs, otherwise check t _c value.

b. If t _c > t _TR + T _R (h, k, j), drop the packet and check the SR value.

If there is an SR value, the FN value is checked. If the SR value does not exist, the packet is dropped.

c. After that, the FN value is stored in the packet buffer regardless of whether it is equal to the LEN value, and the CH TR_table is updated.

d. At this time, CH TR_table update items are FN, LEN, h _i , i.

When step S234 ends, t _C = t _{NR +} T _R (h, k, j) (S258).

t _C = t _{NR +} T _R (h, k, j), then T_RESPONSE is transmitted via the TX T_RESPONSE phase (259).

The procedure for generating T_RESPONSE to transmit via TX T_RESPONSE phase is as follows.

How to generate TX T_RESPONSE for cluster head

1. First, set the header.

a. The header is set in the same manner as I_BEACON described above.

b. Thereafter, T_RESPONSE is broadcasted at time t _TR + T _R (h, k, j), and then T_RESPONSE is removed.

Packet processing algorithm of cluster head (CH, Cluster Head) data link protocol

13 is a flowchart illustrating a packet processing algorithm of the cluster head data link protocol in detail according to an embodiment of the present invention.

The cluster head packet processing algorithm is an algorithm for analyzing a packet train received from a packet train read algorithm (PTRA) and processing it on a case-by-case basis. The cluster head packet processing algorithm includes an initialization stage S210, a steady stage S230, And is commonly used in the end stage (S250).

This algorithm is also processed when a mode packet of a packet train is received or only a part of it is received.

First, the packet train is received from the packet train read algorithm (PTRA) (S171) and it is determined whether it is I_BEACON (S181).

If I_BEACON is set, the time offset (TO) is set and the time is synchronized (S182). If it is not I_BEACON, it is determined whether it is T_BEACON (S183).

If T_BEACON is set, a timer is set up (S184) to determine whether or not a final hop is provided (S185), and if it is not T_BEACON, it is determined whether or not it is downlink data (S188).

Step (S185) to end-hop case the packet after transmitting the packet after creating the I_RESPONSE or T_RESPONSE to Q _{TX _DL_ PL} of the upper layer, and (S186), if it is not the last hop to modify the header and payload of I_BEACON or T_BEACON in and it transmits it to the Q _{TX _DL_ PL} of the upper layer (S187).

In step S188, the time is synchronized with the downlink data in step S189. If the downlink data is not downlink data, it is determined in step S190 whether the address is the address NH of the next hop channel to be transmitted with reference to the route table.

If it is determined that the broadcast mode is not the broadcast mode, it is determined whether it is the last hop in the broadcast mode (S194). If the broadcast mode is not the broadcast mode, It is determined whether the CS is the address (TH) of the CH for the unicast data packet to be transmitted (S196).

Transmits a case the final hop packet in step (S194) to the Q _{TX _DL_UL} the higher layer and sends it to the (S195), Q _{TX _DL_ PL} packet after modifying the downlink data of the upper layer if it is not the last hop (S198) .

If it is the address (TH) of the CH for the unicast data packet transmitted by the CS in step S196, the packet is transmitted to the upper layer Q _{TX _DL_UL} (S199), and the CH for the unicast data packet transmitted by the CS If it is not the address (TH), it determines whether it is the address (NH) of the next hop channel to be transmitted with reference to the route table by using the downlink route table (S197).

If the address (NH) of the next hop CH to be passed by reference to the routing table, sending the packet after modifying the downlink data received by the Q _{TX _DL_ PL} of the upper layer, and (S198), address (NH next hop CH ), The packet is dropped (S192).

Step if (S190) the address (NH) of the next hop CH in that must be passed by referring to the route table I_RESPONSE, T_RESPONSE or transmits a packet after modifying the uplink data to the Q _{TX _DL_ PL} of the upper layer (S191), If it is not the address (NH) of the next hop CH, the packet is dropped (S192).

In addition to improving the communication efficiency between the bus and the plurality of cluster heads, it is possible to reduce the message overhead in transmitting and receiving packet trains in the underwater long distance network, It is possible to improve the performance of a poor underwater network communication system by lowering the algorithm complexity.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is clearly understood that the same is by way of illustration and example only and is not to be construed as limiting the scope of the invention as defined by the appended claims. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.

CS: bus CH: cluster head

Claims (17)

(A) an initial stage in which a bus line establishes an initial communication path;
(B) a normal stage in which the bus bar and the plurality of cluster heads communicate through the communication path; And
(C) an end stage in which the bus and the plurality of cluster heads terminate communication,
The communication includes transmitting and receiving a packet in a packet train format for collectively transmitting packets in a time division multiple access (TDMA)
The packet train type packet reception
(D) Receiving the packet from the queue by the packet train read algorithm, checking the header and RX state table according to whether or not there is an error in the received packet, and checking the number of received packets and the number of packet losses Determining whether the number of received packets is the total number of the fragmented packets according to whether a new start packet is received in the middle; And
(E) receiving the packet train generated by the packet train read algorithm and determining whether the RX state table is updated and whether the response signal is transmitted to an upper layer according to whether the response signal is equal to the Seq value of the beacon signal or not, Wherein the step &lt; RTI ID = 0.0 &gt;
Characterized by
A method of communication using a data link layer reception protocol for underwater long distance networks.
2. The method of claim 1, wherein step (A)
(a) transmitting the initial beacon signal by the bus;
(b) receiving an initial response signal of the plurality of cluster heads corresponding to the initial beacon signal;
(c) determining whether a predetermined reception waiting time of the initial response signal has expired;
(d) determining whether all of the initial response signals of the plurality of cluster heads have been received when the reception wait time has expired in step (c); And
(e) if the initial response signal is received in step (d), setting a communication path between the busbars and the plurality of cluster heads
And a data link layer receiving protocol for a long-distance underwater network.
The method of claim 1, wherein (B)
(a) sending a normal beacon signal to the plurality of cluster heads via the bus;
(b) receiving a normal response signal of the plurality of cluster heads corresponding to the normal beacon signal;
(c) determining whether the predetermined reception waiting time of the normal response signal has expired; And
(d) judging whether the number of times the response signal has failed to respond exceeds the predetermined number of response failure limits, when the reception waiting time has expired in the step (c)
And a data link layer receiving protocol for a long-distance underwater network.
The method of claim 1, wherein the step (C)
(a) transmitting the end beacon signal to the plurality of cluster heads via the bus;
(b) receiving, by the bus, an end response signal of the plurality of cluster heads corresponding to the end beacon signal;
(c) determining whether the predetermined waiting time of the normal response signal has expired in the step (b); And
(d) determining whether all of the response signals have been received on the bus line when the reception waiting time has expired in the step (c)
And a data link layer receiving protocol for a long-distance underwater network.
The method of claim 1, wherein step (D)
(a) checking whether the queue is empty, determining whether the EQ is less than the EQmax when the queue is continuously empty, initializing the EQ if the queue is empty, reading the packet from the queue, and temporarily storing the packet in the BUF;
(b) checking the header and the RX state table according to whether or not there is an error in the received packet to determine whether a new start packet has been received in the middle, and if a new start packet has not been received in the middle, Initializing the number of received packets and the number of packet losses according to whether or not the received packet is lost; And
(c) determining whether or not there is an error in the received packet according to whether the number of the received packets is the total number of the fragmented packets and whether the packet is lost, And checking the RX state table to determine whether the new start packet is received in the middle or whether the number of received packets is the total number of the fragmented packets.
And a data link layer receiving protocol for a long-distance underwater network.
6. The method of claim 5, wherein step (a)
(a-1) checking the queue to determine whether the queue is continuously empty;
(a-2) if the queue is consecutively empty, incrementing the EQ by '1' to determine whether the EQ is less than the EQmax;
(a-3) returning to the step (a-1) when the EQ is less than the EQmax; And
(a-4) initializing the EQ to '0' if the queue is different in step (a-1), receiving a packet from the queue, and temporarily storing the packet in the BUF;
And a data link layer receiving protocol for a long-distance underwater network.
7. The method of claim 6, wherein step (b)
(b-1) determines whether or not there is an error in the received packet, and if there is an error, deletes the BUF and returns to step (a-1). If there is no error, the header and the RX state table are checked ;
(b-2). If a new start packet is received in the middle, it deletes the BUF and returns to the step (a-1). In the middle, a new start packet is received Determining whether the data is duplicated if the data is not received;
(b-3), the BUF is deleted and the flow returns to the step (a-1). If the packet is not duplicated, the number of received packets is initialized to '1' Initializing the number of times to '0';
And a data link layer receiving protocol for a long-distance underwater network.
8. The method of claim 7, wherein step (c)
(c-1) determining whether the number of received packets is the total number of the fragmented packets;
(c-2) checking the queue to determine whether the packet loss is present if the total number of the fragmented packets is not equal to the total number of the fragmented packets;
(c-3) if the packet loss is present, incrementing the number of received packets and the number of packet losses by '1' to determine whether the number of received packets is the total number of the fragmented packets;
(c-4) if there is no packet loss, receiving a packet from the queue and temporarily storing the packet in the BUF, and then determining whether there is an error in the received packet;
(c-5) checking the header and the RX state table when there is no error in the received packet;
(b-3) after determining whether the current packet is stored in the BUF according to whether a new start packet is received in the middle of step (c-6) (C-1) after being stored in the BUF;
And a data link layer receiving protocol for a long-distance underwater network.
6. The method of claim 5, wherein step (E)
(e-1) receiving the packet train and determining whether the beacon signal is I_BEACON or T_BEACON;
(e-2) if it is I_BEACON or T_BEACON, deleting the BUF and determining whether the timer has expired; determining whether the response signal is I_RESPONSE or T_RESPONSE when the timer is not I_BEACON or T_BEACON;
(e-3) terminating the operation when the timer ends, and returning to the step (e-1) if the timer is not finished;
(e-4) whether the I_BEACON or the T_BEACON transmitted in the case of the I_RESPONSE or the T_RESPONSE is the same as the Seq value; updating the RX state table if it is the same, deleting the BUF if not (e-3); And
(e-5) determining whether the uplink data is not the I_RESPONSE or the T_RESPONSE, updating the RX state table in case of the uplink data, and transmitting the packet to the upper layer, Deleting the BUF and returning to step (e-3);
And a data link layer receiving protocol for a long-distance underwater network.
(A) a cluster head receives a first initial beacon signal, transmits a first initial response signal corresponding to the first initial beacon signal, and transmits a second initial beacon signal to generate a second initial beacon signal corresponding to the second initial beacon signal 2 an initial stage for receiving an initial response signal and setting a path;
(B) the cluster head receives a first steady beacon signal, transmits a first steady beacon signal corresponding to the first steady beacon signal, and transmits a second steady beacon signal to generate a second steady beacon signal corresponding to the second steady beacon signal A normal stage receiving a second normal response signal; And
(C) the cluster head receives a first end beacon signal and transmits a first end response signal corresponding to the first end beacon signal, and transmits a second end beacon signal to generate a second end beacon signal corresponding to the second end beacon signal And an end stage for receiving a second end response signal,
Wherein the first initial response signal includes information of the second initial response signal, the first normal response signal includes information of the first normal response signal, and the first end response signal includes information of the second end response Information of the signal,
The transmission and reception of the signals transmit and receive packets in a packet train format for collectively transmitting packets in a time division multiple access (TDMA)
The packet train type packet reception
(D) Receives a packet from a queue by a packet train read algorithm, checks the header and RX state table according to whether there is an error in the received packet, and initializes the number of received packets and the number of packet losses according to the redundancy Determining whether the number of received packets is the total number of the fragmented packets according to whether a new start packet is received in the middle; And
(E) receiving a packet train generated by the packet train read algorithm to synchronize time or set up a timer according to whether a beacon signal is downlink data or a type of a beacon signal, and whether or not the packet is a final hop And transmits the packet to the upper layer after modifying the beacon signal or the downlink data, or modifies the downlink data, the uplink data or the response signal according to the type of the address of the cluster head Transmitting or dropping the packet to an upper layer;
And a data link layer receiving protocol for a long-distance underwater network.
11. The method of claim 10, wherein step (A)
(a) the cluster head receiving a first initial beacon signal;
(b) performing time synchronization with a time parameter if the first initial beacon signal count is equal to the maximum number of packets that can be sent at one time and is the same;
(c) if the current time does not exceed the transmission start time of the initial beacon and the sum of the hop h and the beacon time offset of j in the sub hop k, the second initial beacon signal is transmitted and the sleep mode (Sleep Mode) is set;
(d) receiving the second initial response signal if the current time is less than the sum of the transmission start time of the initial beacon and the beacon time offset of j in hop h and sub hop k;
(e) transmitting a first initial response signal corresponding to the first initial beacon signal if the current time is equal to the sum of the transmission start time of the initial beacon and the beacon time offset of j in the hop h and sub hop k step;
(f) determining whether the first initial beacon signal is received for a predetermined time; And
(g) setting the path if the first initial beacon signal is not received for the preset time period
And a data link layer receiving protocol for a long-distance underwater network.
11. The method of claim 10, wherein step (B)
(a) receiving a first steady beacon signal;
(b) performing time synchronization with a time parameter if the first normal beacon signal count is equal to a maximum number of packets that can be sent at one time;
(c) if the current time is less than the sum of the transmission start time of the normal beacon and the beacon time offset of j in the hop h and the sub hop k, the mobile station transmits the second normal beacon signal and transmits a sleep mode );
(d) receiving the second normal response signal if the current time is less than the sum of the transmission start time of the normal beacon and the beacon time offset of j in the hop h and sub hop k; And
(e) when the current time is equal to the sum of the transmission start time of the normal beacon and the beacon time offset of j in the hop h and sub hop k, the first normal response signal corresponding to the first normal beacon signal is transmitted step
And a data link layer receiving protocol for a long-distance underwater network.
11. The method of claim 10, wherein step (C)
(a) receiving a first end beacon signal;
(b) performing time synchronization with a time parameter if the first end beacon signal is the same as the maximum number of packets that can be sent at one time;
(c) if the current time is less than the sum of the transmission start time of the end beacon and the beacon time offset of j in the hop h and sub hop k, the second end beacon signal is transmitted and the sleep mode );
(d) if the current time is less than the sum of the transmission start time of the end beacon and the beacon time offset of j in the hop h, sub hop k, receiving the second end acknowledgment signal; And
(e) when the current time is equal to the sum of the transmission start time of the end beacon and the beacon time offset of j in the hop h and the sub hop k, the first end response signal corresponding to the first end beacon signal is transmitted step
And a data link layer receiving protocol for a long-distance underwater network.
11. The method of claim 10, wherein step (E)
(e-1) receiving the packet train and determining whether the beacon signal is I_BEACON;
(e-2) synchronizing time after setting a time offset in case of I_BEACON, and determining whether T_BEACON of the beacon signal is not I_BEACON;
(e-3) if it is T_BEACON, determining whether it is the last hop after setting up the timer; determining whether the downlink data is not T_BEACON; And
(e-4) if it is the last hop, it transmits the packet to the upper layer after generating the response signal I_RESPONSE or T_RESPONSE, and if it is not the last hop, modifies the header and payload of the I_BEACON or the T_BEACON, Layer;
And a data link layer receiving protocol for a long-distance underwater network.
15. The method of claim 14, wherein step (E)
(e-5) synchronizing time in the case of the downlink data in step (e-3), determining whether it is the broadcast mode, and determining whether it is the last hop in the broadcast mode;
(e-6) transmitting a packet to the upper layer when the packet is the last hop, and transmitting the packet to the upper layer after correcting the downlink data if the packet is not the last hop;
Further comprising a data link layer receiving protocol for the underwater long distance network.
16. The method of claim 15, wherein step (E)
(e-7) determining whether the address is the address (TH) of the cluster head for the unicast data packet transmitted by the bus using the downlink route table if the broadcast mode is not the broadcast mode;
(e-8) transmits the packet to the upper layer when the address is the address (TH) of the cluster head, and if the address is not the address (TH) of the cluster head, refers to the route table using the downlink route table (NH) of the next hop cluster head;
(e-9) transmits the packet to the upper layer after correcting the received downlink data if the address is the address (NH) of the next hop cluster head, and if the address is not the address (NH) ;
Further comprising a data link layer receiving protocol for the underwater long distance network.
17. The method of claim 16, wherein step (E)
(e-10) determining whether the downlink data is the address (NH) of the next hop cluster head if the downlink data is not the downlink data;
(NH) of the next hop cluster head, and transmits the packet to the upper layer after modifying the I_RESPONSE, the T_RESPONSE or the uplink data, If not, dropping the packet;
Further comprising a data link layer receiving protocol for the underwater long distance network.

Images