KR101469718B1 - Packet processing method in network layer for ship ad hoc network - Google Patents

Abstract

A packet processing method in a network layer for a ship ad hoc network (SANET) according to the present invention includes: receiving upper layer data from an upper layer; And constructing a network packet by attaching an address header to the upper layer data with reference to a route table, wherein in the step of configuring the network packet, the address header is transmitted to a Maritime Mobile Service Identity (MMSI) of a ship or a base station ) Number. ≪ / RTI >

Description

Technical Field [0001] The present invention relates to a packet processing method in a network layer for a ship ad hoc network (SANET)

The present invention relates to a ship ad hoc network (SANET), and more particularly to a packet processing method at a network layer for a ship ad hoc network (SANET).

Today, along with the rapid development of terrestrial wireless communication services, it is required to provide various multimedia services even in ships that are on the coast or offshore. That is, various types of multimedia services such as bi-directional digital data transmission, video, and Internet access are required as in the case of the land, by connecting to a land network infrastructure on a ship. For this purpose, it is possible to apply the existing WLAN to the shore and provide service to the ship, but communication restriction is large due to short communication distance within 1 km. On the other hand, satellite communication can guarantee a wide range of communication and high data rate, which is a strong possibility to provide various ship multimedia services. However, satellite communication has a disadvantage in that service cost is burdensome to provide multimedia service to a ship frequently, such as on land.

Currently, for maritime digital communication, ITU-R M1842-1 standardizes VHF band maritime digital communication, and according to this standard, it is possible to support data rate of over 100kbps in VHF band communication. Considering that the transmission distance of the VHF communication band is several tens of kilometers, the VHF band digital digital communication can replace the satellite communication and provide the multimedia service to the ship.

The concept of Ship Ad-hoc NETwork (SANET), which can cope with MANET and VANET on the land, has been proposed to provide multimedia service to vessels using ad-hoc communication method in VHF band. When implementing SANET, the specification of the physical layer proposed in ITU-R M1842-1 can be referred to, but specifications for the upper layer are not standardized at present.

The network protocol for SANET can be designed based on a protocol developed for land mobile ad-hoc network (MANET). However, in order to apply the terrestrial ad hoc network protocol to the maritime communication, it is necessary to reflect various situations that can occur in the sea such as the presence of a neighboring ship, a route to a destination, and a communication mode change in a poor communication environment.

SUMMARY OF THE INVENTION The present invention provides a packet processing method in a network layer suitable for a ship ad hoc network (SANET).

According to an aspect of the present invention, there is provided a method of processing packets in a network layer for a ship ad hoc network (SANET), the method comprising: receiving upper layer data from an upper layer; And constructing a network packet by attaching an address header to the upper layer data with reference to a route table, wherein in the step of configuring the network packet, the address header is transmitted to a Maritime Mobile Service Identity (MMSI) of a ship or a base station ) Number. ≪ / RTI >

In one embodiment, the address header may include addresses of a source, a destination, a source relay, and a destination relay.

In one embodiment, the address header may be represented using an MMSI number of a ship or a base station by converting the MMSI number into a 3-byte bit string.

In one embodiment, the address header may be represented using the MMSI number of the ship by converting six numbers after the "MID" in the MMSI number into a 3-byte bit string.

In one embodiment, the address header is represented by using the MMSI number of the base station. In this embodiment, the base station is represented by a specific bit string of 1 byte, and four numbers after "00MID" in the MMSI number are converted into a 2-byte bit string .

In one embodiment, the packet processing method includes: determining whether a path corresponding to the upper layer data exists; And if the route does not exist, performing a predetermined routing algorithm to generate a route table.

According to an aspect of the present invention, there is provided a method of processing a packet in a network layer for a ship ad hoc network (SANET), the method comprising: receiving a network packet from a data link layer; Generating a route table by performing a predetermined routing algorithm when the network packet is a route determination packet; Reading upper layer data received from an upper layer from a queue temporarily stored with the upper layer data; And constructing a network packet by attaching an address header to the upper layer data by referring to the route table. In the step of configuring the network packet, the address header is transmitted to a Maritime Mobile Service (MMSI) Identity) number.

In one embodiment, the packet processing method may further include extracting upper layer data from the network packet when the network packet is not a routing packet, and delivering the upper layer data to an upper layer.

According to the present invention, since the address header is expressed using the Maritime Mobile Service Identity (MMSI) number of the ship or the base station in the process of configuring the network packet, the length of the header can be reduced, Can be commonly used.

1 is a reference diagram for explaining SANET.
2 illustrates a network hierarchical structure of a SANET according to an embodiment of the present invention.
3 is a diagram illustrating a structure of a SANET frame according to an embodiment of the present invention.
4A to 4C show specific configurations of IP-based applications, non-IP-based applications, and messages for each layer in the case of path determination.
5 is a diagram for explaining an addressing method according to an embodiment of the present invention.
6 is a flowchart illustrating a packet processing method in a network layer according to an embodiment of the present invention.
7 is a flowchart illustrating a method of processing a packet in a data link layer according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings. In the following description and the accompanying drawings, substantially the same components are denoted by the same reference numerals, and redundant description will be omitted. In the following description of the present invention, a 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.

1 is a reference diagram for explaining SANET. SANET (Ship Ad-Hoc NETwork) is a network that has a communication distance of several tens of kilometers under a topology where nodes (for example, ships in operation) are scattered randomly, and is used as a MAC (Media Access Control) Organizing Time Division Multiple Access).

As shown in FIG. 1, the SANET can be composed of a plurality of base stations (BSs) and marine vessels. A node according to an embodiment of the present invention may be implemented in a marine mobile body such as each of these marine vessels. Hereinafter, for convenience of explanation, the marine mobile body is assumed to be a marine vessel.

The terrestrial base station (BS) is connected to a ground-based Internet Protocol (IP) back-bone network and provides a variety of multimedia services to marine vessels.

Marine vessels may be scattered randomly across the entire ocean, but are generally more distributed on the coast or coast rather than the desired one. The 'node' implemented in each of these maritime vessels can communicate with the surrounding maritime vessel (strictly speaking, the node embodied in the maritime vessel around it) or the land base station. To this end, each maritime vessel is equipped with a VHF (Very High Frequency) transceiver. On the other hand, each marine vessel is equipped with a communication system of HF (High Frequency) or satellite frequency band in preparation for VHF band communication disruption.

Of course, the fact that a certain node communicates with neighboring nodes assumes that the neighboring node is located within the communication distance of any node (within about 30 km in the case of VHF). Here, the communication distance means a distance at which a node can exchange information with another node.

Meanwhile, nodes according to at least one embodiment of the present invention communicate with each other ad-hoc, and each of them transmits data received from its own data or neighboring nodes through a communication path defined by a given routing protocol .

2 illustrates a network hierarchical structure of a SANET according to an embodiment of the present invention.

SANET applications include IP based applications (e.g., email, web browsing) and non-IP based applications (e.g., logistics data transfer applications), as shown. The transport layer is employed only in IP-based applications. In the case of IP-based applications, protocols such as HTTP and FTP may be used as the application layer protocol, and protocols widely used in the Internet such as TCP and UDP may be used as the transport layer protocol. For non-IP based applications, the logistics data may be obtained from an external interface device (e.g., RS-232).

The network layer has a role of setting a corresponding path for transmission of data coming from an upper layer, sending a network packet down to a data link layer by adding a network layer header, and transmitting a MAC packet received from the data link layer to a path And serves to divide the packets into configuration packets and data packets. In the case of IP-based data, an IP header is added at the network layer, and IPv4 may be applied to reduce the length of the header. In the network layer, a conventional Ad hoc On-demand Distance Vector (AODV) algorithm can be used as the routing algorithm, and furthermore, a GAODV (Geometric AODV, Korean Patent Application 10-2011-0098582) proposed by the inventors of the present application is used .

The data link layer (Datalink layer) determines a time slot according to a MAC algorithm for a packet coming from a network layer, and generates and transmits a MAC packet to a physical layer. The Datalink layer extracts a MAC packet from a message transmitted from the physical layer, Performs a check, and updates and synchronizes the time slot state table. Time information can be obtained from a GPS connected through an external interface. As a MAC algorithm, a conventional SO-TDMA (Self-Organizing Time Division Multiple Access) can be used, and furthermore, an ASO-TDMA ("Yun-Y. Lim" (ASO-TDMA) MAC protocol for shipborne ad-hoc network (SANET), "accepted in EURASIP WCN, Nov. 2012.) can be used.

The physical layer receives the MAC packet from the data link layer and transmits the MAC packet to the data link layer.

3 is a diagram illustrating a structure of a SANET frame according to an embodiment of the present invention. Referring to FIG. 3, the SANET frame is composed of 2250 time slots, and the length thereof is 1 minute, so that the length of one time slot is 26.667ms. The frame number (NOSF) of the SANET frame is newly started every hour, there are 60 SANET frames per hour, and the frame number (NOSF) is given from 1 to 60 (i.e., NOSF = 1: 1: 60) . The time slot number (NOTS) is given from 1 to 2,250 (i.e., NOTS = 1: 1: 2250).

The SANET frame is composed of five subframes (SF), and a control subframe (CSF) exists at a boundary between the subframes. In each subframe, a different number of time slots are allocated, as shown in the figure, and the control subframe is allocated a time slot for each base station to transmit a packet and each time slot.

When transmitting MAC packets to the physical layer, the data link layer includes time information (NOSF, NOTS) to be transmitted. It is more efficient to transmit the time information obtained from the GPS to the physical layer or to express it in the MAC packet header by the frame number (NOSF) and the time slot number (NOTS). The physical layer checks the time stamp header information of the received MAC packet, converts the start time of the occupied time slot into 'M (minutes): S (second)', and transmits it at the start time. The conversion relationship between the frame number (NOSF) and the time slot number (NOTS) and the start time information (M (minutes): S (seconds)) is as follows.

M = NOSF, S = (NOTS-1) * 26.668 msec

NOSF = M, NOTS = (S / 26.668 msec) +1

The following table shows a schematic configuration of a layer-by-layer message according to an embodiment of the present invention.

Definition by hierarchy
Justice IP-based applications Non-IP based applications Routing Application layer:
Application layer data Header + application data Header + application data Delivery Layer:
Forwarding layer data Header + application layer data Network layer:
Network packet IP header + address header + forwarding layer data Address header + application layer data Routing header Data Link Layer:
MAC packet MAC header + payload

4A to 4C show specific configurations of IP-based applications, non-IP-based applications, and messages for each layer in the case of path determination.

Referring to FIG. 4A, in the case of an IP-based application, the application layer data includes an application layer header (for example, an HTTP header) and application data. The application layer data is transport layer data by attaching a transport layer protocol header (e.g., TCP or UDP). The transport layer data is a network packet to which an IP header, an address header (S, D, SR, DR), and a Type_N header are attached. The network packet is a MAC packet with a time stamp, CRC, Type_DL, start and end header attached thereto.

Referring to FIG. 4B, in the case of a non-IP-based application, application layer data includes application data, a LEN header, and a NO header. The application layer data is a network packet with an address header (S, D, SR, DR) and a Type_N header attached thereto. A network packet is a MAC packet with a time stamp, CRC, Type_DL, start and end header attached.

Referring to FIG. 4C, there are two types of routing packets: a route request packet (RREP) and a route response packet (RREQ) (AODV). In the GAODV algorithm, the route request packet is called GRREP and the route reply packet is called GRREP. In FIG. 4C, a Type_N header is attached to the RREP and the RREQ to form a network packet, and the network packet is a MAC packet with a time stamp, CRC, Type_DL, start and end header attached thereto.

Referring to the MAC packets in FIGS. 4A to 4C, SYNC_start and SYNC_end are headers indicating the start and end of a MAC packet, respectively. The Type_DL header indicates the type of the MAC packet, and the values are 'R', 'I', and 'N', respectively, indicating path determination, IP based application, and non-IP based application. The timestamp header is a header indicating a frame number (NOSF) and a time slot number (NOTS). Six bits can be used to represent NOSF (NOSF = 1: 1: 60), and 12 bits can be used to represent NOTS (NOTS = 1: 1: 2250). Therefore, the length of the timestamp header is 3 bytes, the first byte is NOSF, and the second 2 bytes are NOTS. The CRC is for checking an error of a MAC packet, for example, CRC-32 can be used.

Referring to the network packets of FIGS. 4A to 4C, the Type_N header is used to indicate the type of the network packet. Like the Type_DL header, its value is 'R', 'I' Based applications, and non-IP based applications. The address header is a header for ad hoc communication with neighboring vessels and one-hop acknowledgment (ACK) confirmation. The address header includes a source, a destination, a source relay, And a destination relay (DR). D is a receiving vessel to which data is to be finally transmitted, SR is a vessel for transmitting data in an ad hoc communication process, a forwarding vessel for transmitting data to a DR, DR is an ad hoc communication process Which is a ship that transmits data from the SR, and which receives data from the SR.

In the embodiment of the present invention, a Maritime Mobile Service Identity (MMSI) number, which is a unique identification number of a ship or a base station, is used as an address of an address header, that is, S, D, SR, DR, It is commonly used in layers.

5 is a diagram for explaining an addressing method according to an embodiment of the present invention.

The maximum length of a packet that can be transmitted during one time slot is fixed to 54 bytes, for example, when adopting a data rate of 28.8 kbps and? / 4-DQPSK. Since the total length of the header plus the payload can not exceed this maximum transmission packet length, it is required to reduce the length of the header to increase the payload length. According to the conventional addressing method, 4 bytes (IPv4) is required as the IP-based routing address in the network layer, and 6 bytes are required as the MAC address in the data link layer. In the embodiment of the present invention, the MMSI number is commonly used in the data link layer and the network layer, so that the address can be represented by only three bytes.

The MMSI number consists of nine digits or letters, expressed as "MIDXXXXXX" for the ship station, and "00MIDXXXX" for the coast station. Here, X is a number from 0 to 9.

Therefore, the address of the ship can be expressed based on the six numbers following the letter "MID ". A number between 0 and 9 can be represented by a binary number using 4 bits. Thus, as shown in FIG. 5A, the address of the ship can be expressed as "xxxxxxxx xxxxxxxx xxxxxxxx ", and 3 bytes are required. For example, in the case of MID625112, the address can be represented as "01100010 01010001 00010010 ".

Further, the address of the base station can be expressed based on the four digits following the MID. At this time, the first byte of the address may be represented by a specific bit string, for example, 11111111, and four digits may be represented by the remaining two bytes. Therefore, as shown in FIG. 5 (b), the address of the base station can be represented by "11111111 xxxxxxxx xxxxxxxx". For example, in the case of 00MID4579, the address of the base station can be expressed as "11111111 01000101 01111001 ".

Using the MMSI number, the address can be represented by a 24-bit (3-byte) bit stream, and the length of the header is much smaller than the conventional method using the IP-based routing address and MAC address. In addition, by using the MMSI number as an address, address headers common to IP-based applications and non-IP-based applications can be used, and can be used in common at the network layer and the data link layer.

6 is a flowchart illustrating a packet processing method in a network layer according to an embodiment of the present invention.

The network layer processes network packets from the data link layer and upper layer data from the upper layer (e.g., the transport layer for IP-based applications, or the application layer for non-IP based applications).

Referring to FIG. 6, in the embodiment of the present invention, five queues are provided in the network layer in order to temporarily store packets coming into the network layer and packets leaving the network layer. In the cues, packets are processed in a first-come first-served-first-served (FCFS) manner. The five queues are defined as follows.

Netw_DLRQQueue 621: a queue for storing network packets received from the data link layer

Netw_DLTXQueue (632): Queue for storing network packets to be forwarded to the data link layer

Netw_UPRXQueue 611: A queue for storing upper layer data received from an upper layer

Netw_UPTXQueue (634): A queue for storing upper layer data to be transferred to an upper layer

Netw_midQueue 617: a queue storing upper layer data waiting for the determination of a route before entering NetwDLTXQueue 632

Referring to FIG. 6, the upper layer data received from the upper layer is stored in the Netw_UPRXQueue 611.

Next, it is determined whether a path corresponding to the upper layer data exists (step 612), and if there is a path, the route table is referred to (step 613). In step 616, an address header is attached to the upper layer data according to the route table to form a network packet.

The address header includes addresses of a source S, a destination D, a source relay SR, and a destination relay DR, as described with reference to Figs. 4A and 4B. The address header is represented using the Maritime Mobile Service Identity (MMSI) number of the ship or the base station, as described with reference to FIG. That is, the address header represents the MMSI number of the ship or the base station converted into a 3-byte bit string. In the case of a ship, six numbers following "MID" in the MMSI number are converted into a 3-byte bit string, The base station is represented by a specific bit string of 1 byte and the four numbers following "00MID" in the MMSI number are converted into a 2-byte bit string.

The network packet configured in step 616 is stored in the Netw_DLTXQueue 632 to be transmitted to the data link layer.

If it is determined in step 612 that there is no path corresponding to the upper layer data, the upper layer data is stored in the Netw_midQueue 617 to wait for path determination. In step 615, a routing algorithm is performed to determine a route to the upper layer data. In step 614, an RREQ packet is generated and the network timer is turned on in step 615. It has already been described that a conventional AODV or a GAODV proposed by the present inventors can be used as the routing algorithm. In step 616, the RREQ packet generated in step 614 is configured as a network packet. The configured network packets are stored in the Netw_DLTXQueue 632 for delivery to the data link layer.

On the other hand, the network packet received from the data link layer is stored in the Netw_DLRQQueue 621.

Next, it is determined whether the received network packet is a route determination packet (RREQ or RREP) (Step 622). Whether the packet is a route determination packet can be confirmed through the Type_N header of the network packet. That is, when the value of the Type_N header is 'R', it can be determined as a route determination packet.

As a result of the determination in step 622, if the packet is not a path determination packet, the upper layer data is extracted by removing the network headers from the network packet (step 633), and the upper layer data is stored in the Netw_UPTXQueue 634 to deliver the upper layer data to the upper layer.

If it is determined in step 622 that the packet is a route determination packet, it is determined whether the packet is expired (step 623). If it has expired, the network packet is dropped (Step 624).

If it has not expired, a routing algorithm (AODV or GAODV) is performed (step 625). As a result of the routing algorithm, if a route has been determined (step 626), a route table is generated according to the route (step 629). In step 631, the upper layer data stored in the Netw_midQueue 617 is read (step 630), and the address header is attached to the upper layer data according to the route table (step 631). Here, the address header includes the addresses of the source S, the destination D, the source relay SR, and the destination relay DR, as in the above-described step 616, and the Maritime Mobile Service Identity (MMSI) Number.

The network packet configured in step 631 is stored in the Netw_DLTXQueue 632 to be transmitted to the data link layer.

As a result of the routing algorithm of step 625, if the path is not determined (step 626), the path determination process is currently in progress and the path determination packet must be continuously transmitted. Accordingly, the network timer is turned on (step 627), the routing decision packet RREQ or RREP is changed according to the routing algorithm (step 628) and stored in the Netw_DLTXQueue 632 for delivery to the data link layer.

7 is a flowchart illustrating a method of processing a packet in a data link layer according to an embodiment of the present invention.

Apart from the packet processing method described below, the data link layer determines a time slot for transmitting a physical layer message received from the physical layer and a network packet received from the network layer, and a MAC algorithm for updating the time slot state table is performed do. However, since ASO-TDMA proposed by the inventor of the present application is used for the MAC algorithm in the embodiment of the present invention as described above, a detailed description thereof will be omitted.

As described above, since the maximum length of packets that can be transmitted during one time slot is limited, in the embodiment of the present invention, the route table determined in the network layer is referenced without adding an address header in the data link layer, The address header, which is attached to the layer, is identified by using an address header that is commonly used in the network layer and the data link layer, that is, the MMSI number, and processes the packets based on the address header.

Referring to FIG. 7, in order to temporarily store a packet coming from the data link layer and a packet leaving the data link layer, five cues are provided in the data link layer in the embodiment of the present invention. In the cues, packets are processed in a first-come first-served-first-served (FCFS) manner. The five queues are defined as follows.

DL_PhyRXQueue 711: A queue for storing physical layer messages received from the physical layer

DL_PhyTXQueue 736: A queue for storing physical layer messages to be transferred to the physical layer

DL_NetwRXQueue 725: A queue for storing network packets received from the network layer

DL_NetwTXQueue (735): A queue storing network packets to be forwarded to the network layer

DL_midQueue 726: A queue for storing MAC packets for allocation of frame numbers and time slot numbers before entering DL_PhyTXQueue 736

Referring to FIG. 7, a physical layer message received from the physical layer is stored in the DL_PhyRXQueue 711.

Next, a MAC packet is extracted from the physical layer message (step 712), and a CRC error is checked (step 713). If a CRC error is detected at this time, the MAC packet is dropped (step 717).

As a result of the CRC error checking in step 713, if no CRC error is detected, it is determined whether the received MAC packet is a route determination packet (RREQ or RREP) (step 714). Whether the packet is a route determination packet can be confirmed through the Type_DL header of the MAC packet. That is, when the value of the Type_DL header is 'R', it can be determined as a route determination packet.

If it is determined in step 714 that the packet is a route determination packet, the network packet is extracted by removing the MAC headers from the MAC packet in step 734, and stored in the DL_NetwTXQueue 735 to deliver the network packet to the network layer.

If the Type_DL header value is 'I' or 'N' as a result of the determination in step 714, the route table determined in the network layer is referred to, and the address header of the network packet included in the MAC packet, that is, Source, destination, source relay, and destination relay addresses (step 715). And processes the MAC packet as described below based on the route table and the address header. The address header is described using a Maritime Mobile Service Identity (MMSI) number of a ship or a base station.

First, it is confirmed whether the address of the self-ship is the same as the source S of the address header (step 716). If the address of the self-ship is the same as the source (S) of the address header, it is dropped (step 707) because it is a packet sent by itself.

If the address of the self-ship is not the same as the source (S) of the address header in step 716, it is checked whether the address of the self-ship is the same as the destination (D) of the address header in step 718. If the address of the self-ship is the same as the destination (D) of the address header, since the self-ship is the final destination, the network packet is extracted by removing the MAC headers from the MAC packet (step 734) And stores it in the DL_NetwTXQueue 735.

If the address of the self-ship is not the same as the destination (D) of the address header in step 718, it is checked whether the address of the self-ship is identical to the source relay (SR) of the address header in step 719. Similar to step 716, if the address of the self-ship is the same as the source relay (SR) of the address header, it is dropped because it is a packet sent by itself (step 717).

If the address of the self-ship is not identical to the source relay (SR) in the address header in step 719, it is checked whether the source relay (SR) of the address header and the destination relay (DR) on the route table are identical (step 720). The fact that the source relay (SR) of the address header is the same as the destination relay (DR) on the route table implies that the received MAC packet can be a one-hop ACK.

When a packet is transmitted to the next 1-hop node as a relay node, a packet transmitted to the next 1-hop node by the next 1-hop node is also received by itself, and the source relay address of the received packet is transmitted to its destination relay address . Accordingly, if the source relay (SR) of the address header of the packet received within a predetermined time is the same as the destination relay (DR) on the route table, it can be confirmed that the next 1-hop node has successfully received the packet, -hop ACK).

If the source relay (SR) of the address header is the same as the destination relay (DR) in the route table in step 720, it is determined whether the packet has expired (step 721).

Whether or not the timer has expired is determined by the difference between the start time of the MAC timer (minute / second), the frame number (NOSF) of the timestamp header of the MAC packet, and the time of converting the time slot number (NOTS) It can be judged according to the perception. For example, when a new MAC packet is transmitted, the start time of the MAC timer is T _start , and the value obtained by converting the timestamp header (NOSF, NOTS) of the one-hop ACK packet into time is T _Ack . Since NOSF is initialized every time, T _Ack can be converted to M (minutes): S (seconds), where M is equal to NOSF and S = (NOTS-1) * 26.668 ms. If the difference between T _Ack and T _start is ΔT _timer , if the ΔT _timer is within the timer expiration time, the packet is not expired.

If the packet has not expired, the received MAC packet is regarded as a one-hop ACK, and the MAC timer is turned off in step 722.

If the packet has expired in step 721, the MAC packet is retransmitted and is stored in the DL_midQueue 726.

If the source relay (SR) of the address header is not the same as the destination relay (DR) in the route table in step 720, it is checked whether the address of the self-ship is the same as the destination relay (DR) of the address header in step 723. If the address of the ship is the same as the destination relay (DR) in the address header, the MAC packet must be delivered to the destination relay according to the route table. Accordingly, after the source relay (SR) and the destination relay (DR) of the MAC packet are changed to the address of the self-ship and the destination relay address in the route table in step 724, a physical layer message is formed and DL_midQueue (726).

If the address of the self-ship is not the same as the destination relay DR in the address header in step 723, the MAC packet is dropped because it does not correspond to any of steps 716, 718, 719, 720 and 723 in step 717.

On the other hand, the network packet received from the network layer is stored in the DL_NetwRXQueue 725, and the network packet of the DL_NetwRXQueue 725 is transmitted to the DL_midQueue 726.

As a result, in the DL_midQueue 726, the network packet from the DL_NetwRXQueue 725 and the MAC packet from the DL_PhyRXQueue 711 are temporarily stored. In step 727, a frame number NOSF and a time slot number (NOTS) are determined with reference to a time slot state table determined by a MAC algorithm for a packet from the DL_midQueue 726.

Next, it is determined whether a Type_DL header exists in the corresponding packet (step 728). In step 728, it is determined whether the corresponding packet is a MAC packet or a network packet. If the Type_DL header exists, the packet is regarded as a MAC packet. Otherwise, the packet can be regarded as a network packet.

If the Type_DL header does not exist in step 728, since the corresponding packet is a network packet, the MAC header is added to form a MAC packet (step 730). Then, it is determined whether the packet is a route determination packet (step 731). Whether the packet is a route determination packet can be confirmed through the Type_DL header of the MAC packet. That is, when the value of the Type_DL header is 'R', it can be determined as a route determination packet. In step 731, a physical layer message is configured in the case of a path determination packet (step 733) and stored in the DL_PhyTXQueue 736 for transmission to the physical layer.

If the packet is not a path determination packet in step 731, the MAC timer is turned on in step 732, the physical layer message is configured in step 733, and the PDU is stored in the DL_PhyTXQueue 736 for delivery to the physical layer.

If the Type_DL header is present in step 728, the corresponding packet is a MAC packet, and thus the MAC packet received from the physical layer is retransmitted or the source relay and the destination relay are changed and transmitted. Accordingly, the time stamp header of the MAC packet is changed with NOSF and NOTS determined in step 727 (step 729), the MAC timer is turned on (step 732), the physical layer message is configured (step 733) And stores it in the DL_PhyTXQueue 736.

The above-described embodiments of the present invention can be embodied in a general-purpose digital computer that can be embodied as a program that can be executed by a computer and operates the program using a computer-readable recording medium. The computer-readable recording medium includes a storage medium such as a magnetic storage medium (e.g., ROM, floppy disk, hard disk, etc.), optical reading medium (e.g., CD ROM,

The present invention has been described with reference to the preferred embodiments. 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 as defined by the appended claims. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

Claims (12)

A packet processing method in a network layer for a ship ad hoc network (SANET)
Receiving upper layer data from an upper layer; And
And constructing a network packet by referring to the route table and attaching an address header to the upper layer data,
In the step of constructing the network packet, the address header is represented using a Maritime Mobile Service Identity (MMSI) number of a ship or a base station,
Wherein the address header includes addresses of a source, a destination, a source relay, and a destination relay. delete The method according to claim 1,
Wherein the address header is converted using a MMSI number of a ship or a base station by converting an MMSI number into a 3-byte bit string. The method according to claim 1,
Wherein the address header is represented by using the MMSI number of the ship by converting six numbers after "MID" in the MMSI number into a 3-byte bit string. The method according to claim 1,
In order to indicate the address header using the MMSI number of the base station, the base station is represented by a specific bit string of 1 byte, and four numbers following "00MID" in the MMSI number are converted into a 2-byte bit string Packet processing method. The method according to claim 1,
Determining whether a path corresponding to the upper layer data exists; And
And if the route does not exist, performing a predetermined routing algorithm to generate a route table. A packet processing method in a network layer for a ship ad hoc network (SANET)
Receiving a network packet from a data link layer;
Generating a route table by performing a predetermined routing algorithm when the network packet is a route determination packet;
Reading upper layer data received from an upper layer from a queue temporarily stored with the upper layer data; And
And constructing a network packet by referring to the route table and attaching an address header to the upper layer data,
Wherein the address header is represented using a Maritime Mobile Service Identity (MMSI) number of a ship or a base station in the step of constructing the network packet. 8. The method of claim 7,
Wherein the address header includes addresses of a source, a destination, a source relay, and a destination relay. 8. The method of claim 7,
Wherein the address header is converted using a MMSI number of a ship or a base station by converting an MMSI number into a 3-byte bit string. 8. The method of claim 7,
Wherein the address header is represented by using the MMSI number of the ship by converting six numbers after "MID" in the MMSI number into a 3-byte bit string. 8. The method of claim 7,
In order to indicate the address header using the MMSI number of the base station, the base station is represented by a specific bit string of 1 byte, and four numbers following "00MID" in the MMSI number are converted into a 2-byte bit string Packet processing method. 8. The method of claim 7,
Extracting upper layer data from the network packet when the network packet is not a routing packet, and delivering the upper layer data to an upper layer.

Images