JP5293452B2 - Control method, control device, and storage medium - Google Patents

Description

  The present invention relates to a control method, a control device, and a storage medium.

  In recent years, research on ad hoc networks in which wireless terminals (for example, “nodes”) are interconnected in an autonomous distributed manner has been underway. In an ad hoc network, no access point is installed, and each node forms a communication path by relaying a packet received from an adjacent node to another adjacent node based on the communication path information.

  By the way, in an ad hoc network, the network environment frequently changes with changes in radio field intensity or movement of nodes. For this reason, each node connected to the ad hoc network performs communication path control before communicating with other nodes.

  For example, conventionally, each node performs communication path control by a technique called pure flooding. Specifically, each node transmits request control information (for example, “HELLO packet”) with the other node as the final destination for the purpose of confirming the communication path with the other node recognized by the node. . Then, each node that has received the HELLO packet determines whether or not the final destination is its own node. If the final destination is its own node, presence control information (for example, “ REGISTER packet ") is returned. On the other hand, if the final destination is not the local node, the HELLO packet is relayed to the adjacent node.

JP 2008-47984 A

  However, the above-described conventional method has a problem that the load on the network increases. That is, the source node that is the source of the HELLO packet must transmit HELLO packets as many as the number of other nodes that the node recognizes, and the more nodes increase, the more HELLO packets are loaded on the network. It was a factor.

  The disclosed technology has been made in view of the above, and an object thereof is to provide a control method, a control device, and a storage medium capable of suppressing a load on a network.

  In one aspect, a control method, a control device, and a storage medium disclosed in the present application receive request control information for requesting existence confirmation from another terminal in a network to which a plurality of terminals are connected. A control method for processing the request control information. The specific terminal includes a reception step of receiving request control information for requesting existence confirmation from another terminal. The specific terminal includes a relay step of relaying the request control information received in the reception step to a terminal different from the other terminals. In addition, the specific terminal identifies the source terminal that is the terminal that first transmitted the request control information from the request control information received in the reception step, and the identified terminal exists as the identified source terminal. A return step of transmitting the presence control information, which is set as the final destination of presence control information indicating that the final destination is set, to the other terminal that has transmitted the request control information to the specific terminal.

  According to one aspect of the control method, the control device, and the storage medium disclosed in the present application, there is an effect that it is possible to suppress the load on the network.

FIG. 1 is a block diagram illustrating a configuration of a network system according to the first embodiment. FIG. 2 is a sequence diagram illustrating a processing procedure of the network system according to the first embodiment. FIG. 3 is a diagram for explaining the outline of the ad hoc network system according to the second embodiment. FIG. 4 is a block diagram illustrating a configuration of the ad hoc network system according to the second embodiment. FIG. 5 is a diagram for explaining a packet and a routing table according to the second embodiment. FIG. 6 is a flowchart for explaining the entire processing procedure in the node. FIG. 7 is a flowchart for explaining routing table update processing. FIG. 8 is a flowchart for explaining the HELLO packet relay process. FIG. 9 is a flowchart for explaining a REGISTER packet return process. FIG. 10 is a flowchart for explaining the relay process of the REGISTER packet. FIG. 11 is a diagram for explaining the effect of the second embodiment. FIG. 12 is a diagram illustrating a computer that executes a control program.

  Hereinafter, embodiments of a control method, a control apparatus, and a storage medium disclosed in the present application will be described. In addition, this invention is not limited by the following examples.

[Configuration of Network System in Embodiment 1]
First, the configuration of the network system according to the first embodiment will be described with reference to FIG. FIG. 1 is a block diagram illustrating a configuration of a network system according to the first embodiment.

  As shown in FIG. 1, a plurality of terminals are connected to the network 1 in the first embodiment. Here, the specific terminal 10 is an arbitrary terminal, receives request control information for requesting existence confirmation from another terminal, and processes the request control information. The source terminal 20 is a terminal that first transmits request control information.

  As illustrated in FIG. 1, the specific terminal 10 includes a request control information receiving unit 11, a request control information relay unit 12, and a presence control information reply unit 13.

  The request control information receiving unit 11 receives request control information from another terminal.

  The request control information relay unit 12 relays the request control information received by the request control information receiving unit 11 to a terminal different from other terminals that transmitted the request control information to the specific terminal 10.

  The presence control information return unit 13 identifies the source terminal 20 from the request control information received by the request control information receiving unit 11. In addition, the presence control information return unit 13 sets the identified source terminal 20 as the final destination of presence control information indicating that the specific terminal 10 exists. In addition, the presence control information reply unit 13 transmits the presence control information in which the final destination is set to the other terminal that has transmitted the request control information to the specific terminal 10.

[Processing Procedure of Network System in First Embodiment]
Next, the processing procedure of the network system according to the first embodiment will be described with reference to FIG. FIG. 2 is a sequence diagram illustrating a processing procedure of the network system according to the first embodiment.

  As shown in FIG. 2, the specific terminal 10 receives the request control information (step S1).

  The specific terminal 10 that has received the request control information relays the request control information to a terminal 30 different from the terminal 30 that has transmitted the request control information to the specific terminal 10 (step S2).

  Further, the specific terminal 10 identifies the source terminal 20 from the request control information received in step S1 (step S3).

  Next, the specific terminal 10 sets the source terminal 20 identified in step S3 as the final destination of presence control information indicating that the specific terminal 10 exists (step S4).

  Then, the specific terminal 10 transmits the presence control information in which the final destination is set in step S4 to the terminal 30 that has transmitted the request control information to the specific terminal 10 (step S5).

  In the first embodiment, the processing procedure for identifying the source terminal 20 in step S3 after the specific terminal 10 relays the request control information in step S2 has been described. However, the present invention is not limited to this. For example, the process of step S2 and the processes of steps S3 to S5 may be performed in parallel, or the process of step S2 may be performed after the processes of steps S3 to S5.

[Effect of Example 1]
As described above, according to the first embodiment, the specific terminal 10 that has received the request control information relays the request control information to another terminal 30 and returns the presence control information to the source terminal 20. In other words, when the transmission source terminal 20 transmits one request control information on the communication path, each terminal 30 on the communication path relays the request control information and returns the presence control information. As described above, the existence of each terminal 30 can be confirmed only by transmitting one request control information from the transmission source terminal 20. As a result, the number of request control information can be reduced and the load on the network can be suppressed. Is possible.

[Outline of Ad Hoc Network System in Embodiment 2]
Subsequently, an ad hoc network system will be described as an embodiment of a control method, a control apparatus, and a storage medium disclosed in the present application. First, the outline of the ad hoc network system according to the second embodiment will be described with reference to FIG. FIG. 3 is a diagram for explaining the outline of the ad hoc network system according to the second embodiment.

  As shown in FIG. 3, at least a node X, a node Y, and a node Z are connected to the ad hoc network in the second embodiment. Here, the node Y and the node Z are arbitrary nodes, receive HELLO packets for requesting existence confirmation from other nodes, and process the HELLO packets. Node X is a transmission source node that first transmits a HELLO packet.

  As illustrated in FIG. 3, the node X transmits a HELLO packet, and the node Y receives the HELLO packet (step S10).

  The node Y that has received the HELLO packet relays the HELLO packet to the node Z different from the node X, and the node Z receives the HELLO packet (step S11). Further, the node Z that has received the HELLO packet relays the HELLO packet to a node different from the node Y (step S12).

  Further, the node Y identifies the node X as a transmission source node from the HELLO packet received in step S10 (step S13).

  Next, the node Y sets the transmission source node X identified in step S13 as the final destination of the REGISTER packet indicating that the node Y exists (step S14).

  Then, the node Y transmits the REGISTER packet in which the final destination is set in step S14 to the node X that has transmitted the HELLO packet to the node Y (step S15).

  Similarly, the node Z identifies the node X as a transmission source node from the HELLO packet received in step S11 (step S16).

  Next, the node Z sets the transmission source node X identified in step S16 as the final destination of the REGISTER packet indicating that the node Z exists (step S17).

  Then, the node Z transmits the REGISTER packet in which the final destination is set in step S17 to the node Y that transmitted the HELLO packet to the node Z (step S18).

  Then, the node Y that has received the REGISTER packet relays the REGISTER packet to the node X (step S19).

  For this reason, according to the second embodiment, the node Y that has received the HELLO packet relays the HELLO packet to the other node Z and returns the REGISTER packet to the node X, thereby suppressing the load on the network. It becomes possible.

  That is, in the conventional method, each node that has received the HELLO packet returns a REGISTER packet only when the final destination is its own node, and when the final destination is not its own node, relays the HELLO packet to the adjacent node. It was only. For this reason, the transmission source node that is the transmission source of the HELLO packet must transmit HELLO packets by the number of other nodes recognized by the own node, and as the number of other nodes increases, the load on the network increases. It was.

  On the other hand, according to the second embodiment, each node that receives the HELLO packet relays the HELLO packet to another node and returns a REGISTER packet regardless of whether or not the final destination is its own node. To do. In other words, when the source node transmits one HELLO packet on the communication path, each node on the communication path relays the HELLO packet and returns a REGISTER packet. As described above, the existence of each node can be confirmed only by transmitting one HELLO packet from the transmission source node. As a result, the number of HELLO packets can be reduced, and the load on the network can be suppressed. .

[Configuration of Ad Hoc Network System in Embodiment 2]
Next, the configuration of the ad hoc network system according to the second embodiment will be described with reference to FIGS. 4 and 5. FIG. 4 is a block diagram illustrating a configuration of the ad hoc network system according to the second embodiment. FIG. 5 is a diagram for explaining a packet and a routing table according to the second embodiment.

  As illustrated in FIG. 4, the node 100 includes a communication unit 110, a storage unit 120, and a control unit 130.

  The communication unit 110 is a wireless module and an antenna that can perform wireless communication.

  The storage unit 120 stores data used for various processes by the control unit 130, and particularly includes a routing table unit 121 and a work data unit 122.

  The routing table unit 121 stores communication path information. Here, the communication path information is information indicating a communication path when a packet is transmitted to a destination node. In other words, the communication path information is information indicating a correspondence relationship between a node that is a packet destination and a node that relays the packet. In addition to the information indicating the correspondence relationship, the routing table unit 121 stores quality information indicating the quality of the communication path and FID (Frame ID) for uniquely identifying the packet from which the communication path information has been acquired.

  Specifically, the routing table unit 121 stores communication path information by being updated by a routing table updating unit 132 described later when a packet is received by a packet receiving unit 131 described later. The communication path information stored in the routing table unit 121 is used for processing by a HELLO packet relay unit 133 (described later), processing by a REGISTER packet return unit 134, processing by a REGISTER packet relay unit 135, and the like.

  For example, as shown in FIG. 5, the routing table unit 121 stores communication path information (shown as “routing table” in FIG. 5). That is, the routing table unit 121 includes a destination node (“destination”) indicating a node that is a packet destination, and an adjacent node (“adjacent”) indicating a node that interconnects with the own node among nodes that relay packets. Are stored in association with each other. In addition, the routing table unit 121 corresponds to the quality (“quality”) of the communication path for transmitting and receiving packets with the destination node, and the FID (“FID”) that uniquely identifies the packet for which the communication path information has been acquired. Add and remember. Here, the quality is a value calculated from the number of hops, for example.

  For example, as shown in S102 of FIG. 5, the routing table unit 121 communicates with the destination node “X”, the quality “1”, the adjacent node “X”, and the FID “1”. Stores route information. That is, the routing table unit 121 stores that there is a communication path to be transmitted to the adjacent node “X” when the packet is transmitted to the node “X” as the destination, and the quality of the path is “1”. In addition, the routing table unit 121 stores that the FID for uniquely identifying the packet from which the communication path information has been acquired is “1”.

  The work data unit 122 has a storage area having the same structure as the routing table unit 121, the HELLO packet, and the REGISTER packet. Specifically, the work data unit 122 temporarily stores indeterminate communication path information before being stored in the routing table unit 121, or temporarily stores indeterminate information when generating a HELLO packet or a REGISTER packet. Remember me.

  The control unit 130 controls the node 100 to execute various processes. In particular, the control unit 130 includes a packet reception unit 131, a routing table update unit 132, a HELLO packet relay unit 133, a REGISTER packet return unit 134, and a REGISTER packet relay unit 135.

  The packet receiving unit 131 receives a HELLO packet or a REGISTER packet from another node. Specifically, when the packet receiving unit 131 receives a packet from an adjacent node via the communication unit 110, the packet receiving unit 131 determines whether the received packet is a HELLO packet, a REGISTER packet, or a normal data packet. To do.

  When the packet reception unit 131 determines that the received packet is a HELLO packet or a REGISTER packet, the packet reception unit 131 sends the received packet to the routing table update unit 132. On the other hand, when it is determined that the received packet is a normal data packet, normal data packet processing is performed, and the processing ends.

  The routing table update unit 132 updates communication path information (routing table) stored by the routing table unit 121. Specifically, when receiving the HELLO packet or the REGISTER packet from the packet receiving unit 131, the routing table updating unit 132 refers to the routing table using an FID that uniquely identifies the HELLO packet or the REGISTER packet. Then, the routing table update unit 132 determines whether or not a FID that matches the FID included in the HELLO packet or the REGISTER packet exists in the routing table. The routing table update unit 132 performs a routing table update process when it is determined that it does not exist, and ends the process as it is when it is determined that it exists.

  In addition, when the routing table update unit 132 performs the routing table update process for the HELLO packet, the routing table update unit 132 then sends the HELLO packet to the HELLO packet relay unit 133. On the other hand, when the routing table update unit 132 performs the routing table update process for the REGISTER packet, the routing table update unit 132 then sends the REGISTER packet to the REGISTER packet relay unit 135. The routing table update process will be described in detail when explaining the processing procedure.

  The HELLO packet relay unit 133 relays the HELLO packet to other nodes. Specifically, when the HELLO packet relay unit 133 receives a HELLO packet from the routing table update unit 132, the HELLO packet relay unit 133 performs a HELLO packet relay process. When the HELLO packet relay unit 133 performs the HELLO packet relay process, the HELLO packet relay unit 133 then sends the HELLO packet received from the routing table update unit 132 to the REGISTER packet return unit 134. The HELLO packet relay process will be described in detail when the processing procedure is described.

  The REGISTER packet return unit 134 returns the REGISTER packet to the transmission source node of the HELLO packet. Specifically, when the REGISTER packet reply unit 134 receives the HELLO packet from the HELLO packet relay unit 133, the REGISTER packet reply unit 134 performs a REGISTER packet reply process, and then ends the process. The REGISTER packet return process will be described in detail when the processing procedure is described.

  The REGISTER packet relay unit 135 relays the REGISTER packet to another node. Specifically, when the REGISTER packet relay unit 135 receives the REGISTER packet from the routing table update unit 132, it first determines whether or not the destination of the REGSITER packet is its own node.

  If the REGISTER packet relay unit 135 determines that the node is not its own node, the REGISTER packet relay unit 135 performs the REGISTER packet relay process, and then ends the process. On the other hand, if the REGISTER packet relay unit 135 determines that the node is the own node, the REGISTER packet relay unit 135 ends the process. Note that the REGISTER packet relay processing will be described in detail when the processing procedure is described.

[Processing Procedure of Ad Hoc Network System in Embodiment 2]
Next, the processing procedure of the ad hoc network system according to the second embodiment will be described with reference to FIGS. FIG. 5 is a diagram for explaining a packet and a routing table according to the second embodiment.

[Overall procedure in the node]
First, the entire processing procedure in the node will be described with reference to FIG. FIG. 6 is a flowchart for explaining the entire processing procedure in the node.

  As shown in FIG. 6, in the node 100, the packet receiver 131 receives a packet (step S201).

  Here, the HELLO packet is a packet having a structure as shown in FIG. 5, for example. Specifically, a transmission source node (“transmission source”) indicating the node that first transmitted the HELLO packet, a hop number (“hop count”) indicating the quality of the communication path from the transmission source node, an adjacent node (“adjacent” )) And a FID (“FID”) for uniquely identifying the HELLO packet. That is, for example, in the HELLO packet transmitted by the node X in step S101, the node “X” is the transmission source node, the hop count from the transmission source node X is “1”, and the adjacent node is the own node “X ", And the FID includes information indicating" 1 ".

  The REGISTER packet is a packet having a structure as shown in FIG. 5, for example. Specifically, it has a transmission source node (“transmission source”) indicating the node that first transmitted the REGISTER packet, and a hop count (“hop count”) indicating the quality of the communication path from the transmission source node. In addition, a destination node (“destination”) indicating a node that is a final destination of the REGISTER packet, an adjacent node (“adjacent”), and a FID (“FID”) for uniquely identifying the REGISTER packet are included. That is, for example, the REGISTER packet transmitted by the node Z in step S108 includes information indicating that the node “Z” is the transmission source node and the hop count from the transmission source node Z is “1”. In addition, information indicating that the node as the final destination is the node “X”, the adjacent node is the local node “Z”, and the FID is “1”.

  Then, the packet reception unit 131 determines whether the received packet is a HELLO packet (step S202), a REGISTER packet (step S207), or a normal data packet.

  If it is determined that the received packet is a HELLO packet (Yes at step S202), the packet receiving unit 131 sends the received packet to the routing table updating unit 132.

  Then, the routing table update unit 132 refers to the routing table using the FID included in the HELLO packet, and determines whether there is an FID that matches the FID included in the HELLO packet (step S203). .

  When it is determined that there is a matching FID (No at Step S203), the routing table update unit 132 ends the process as it is. On the other hand, when it is determined that there is no matching FID (Yes at Step S203), the routing table update unit 132 performs a routing table update process described later (Step S204). Send to.

  Then, the HELLO packet relay unit 133 performs a HELLO packet relay process to be described later (step S205), and then sends the HELLO packet received from the routing table update unit 132 to the REGISTER packet return unit 134.

  Subsequently, the REGISTER packet return unit 134 performs a REGISTER packet return process described later (step S206), and then ends the process.

  On the other hand, when it is determined in step S202 that the received packet is not a HELLO packet (No in step S202), the packet receiver 131 next determines whether or not the received packet is a REGISTER packet (step S202). S207).

  If it is determined that the received packet is a REGISTER packet (Yes at step S207), the packet receiving unit 131 sends the received packet to the routing table updating unit 132.

  Then, the routing table update unit 132 refers to the routing table using the FID included in the REGISTER packet, and determines whether there is an FID that matches the FID included in the REGISTER packet (step S208). .

  When it is determined that there is a matching FID (No at Step S208), the routing table update unit 132 ends the process as it is. On the other hand, if it is determined that there is no matching FID (Yes at Step S208), the routing table update unit 132 performs a routing table update process described later (Step S209), and then transmits the REGISTER packet to the REGISTER packet relay unit 135. Send to.

  Then, the REGISTER packet relay unit 135 first determines whether or not the destination of the REGSITER packet is the local node (step S210). If it is determined that the node is the own node (No at step S210), the process is terminated as it is.

  On the other hand, if it is determined that the node is not the own node (Yes at Step S210), the REGISTER packet relay unit 135 performs a REGISTER packet relay process (to be described later) (Step S211), and then ends the process.

  On the other hand, if it is determined in step S207 that the received packet is not a REGISTER packet (No in step S207), the packet receiver 131 determines that the received packet is a normal data packet, and performs normal data packet processing. (Step S212), and the process ends.

[Routing table update processing]
Next, routing table update processing will be described with reference to FIG. FIG. 7 is a flowchart for explaining routing table update processing. Since the routing table update processing is not different between the case of updating using the HELLO packet and the case of updating using the REGISTER packet, the case of updating using the HELLO packet will be described below.

  The routing table update unit 132 first identifies the transmission source node from the HELLO packet (step S204-1). For example, the routing table updating unit 132 of the node Y illustrated in FIG. 5 identifies the transmission source node “X” from the HELLO packet received in step S101.

  Next, the routing table update unit 132 sets a work table as a temporary storage area having the same structure as the routing table in the work data unit 122, and newly creates a record in the set work table (step S204-2). ).

  Subsequently, the routing table update unit 132 sets the transmission source node identified in step S204-1 to the “destination” of the newly created record in the work table (step S204-3). For example, the routing table update unit 132 sets the transmission source node “X” as the “destination” of the newly created record in the work table.

  Further, the routing table update unit 132 identifies the adjacent node from the received HELLO packet, and sets the identified adjacent node in “adjacent” of the newly created record in the work table (step S204-4). For example, the routing table update unit 132 identifies the adjacent node “X” from the HELLO packet received in step S101, and sets the identified adjacent node “X” in “adjacent” of the newly created record in the work table.

  Also, the routing table update unit 132 identifies the number of hops from the received HELLO packet, and sets the identified number of hops in the “quality” of the newly created record in the work table (step S204-5). For example, the routing table updating unit 132 identifies the hop number “1” from the HELLO packet received in step S101, and sets the identified hop number “1” as the “quality” of the newly created record in the work table.

  Further, the routing table update unit 132 identifies the FID from the received HELLO packet, and sets the identified FID in “FID” of the newly created record in the work table (step S204-6). For example, the routing table updating unit 132 identifies the FID “1” from the HELLO packet received in step S101, and sets the identified FID “1” to “FID” of the newly created record in the work table.

  Then, the routing table updating unit 132 determines whether or not the same “destination” and “adjacent” records exist in the routing table (step S204-7). If there is (Yes at Step S204-7), the routing table update unit 132 overwrites the routing table with the newly created record in the work table (Step S204-8), and ends the process. For example, the routing table updating unit 132 of the node Y illustrated in FIG. 5 updates the routing table as illustrated in Step S102 from the HELLO packet received in Step S101.

  On the other hand, if not (No at Step S204-7), the routing table update unit 132 adds a newly created record to the work table to the routing table (Step S204-9), and ends the process.

[Relay processing of HELLO packet]
Next, HELLO packet relay processing will be described with reference to FIG. FIG. 8 is a flowchart for explaining the HELLO packet relay process.

  First, the HELLO packet relay unit 133 sets a work packet as a temporary storage area having the same structure as the HELLO packet in the work data unit 122, and copies the received HELLO packet to the set work packet (step S205). -1). For example, the HELLO packet relay unit 133 of the node Y shown in FIG. 5 copies the HELLO packet received in step S101 to the work packet.

  Next, the HELLO packet relay unit 133 adds 1 to the “hop count” copied to the work packet and sets a new hop count (step S <b> 205-2). For example, the HELLO packet relay unit 133 sets a new hop number “2” in the work packet.

  Further, the HELLO packet relay unit 133 sets its own node to “adjacent” copied to the work packet (step S205-3). For example, the HELLO packet relay unit 133 sets its own node “Y” to “adjacent”.

  Further, the HELLO packet relay unit 133 sets “FID” as it is to “FID” copied to the work packet (step S205-4). For example, the HELLO packet relay unit 133 sets FID “1” to “FID”.

  Then, the HELLO packet relay unit 133 generates a new HELLO packet, and sets the contents of the work packet in the generated new HELLO packet (step S205-5).

  Thereafter, the HELLO packet relay unit 133 transmits the HELLO packet generated in step S205-5 (step S205-6). For example, the HELLO packet relay unit 133 of the node Y illustrated in FIG. 5 transmits the generated HELLO packet to the node Z (see step S103).

[Register packet reply processing]
Next, the REGISTER packet return process will be described with reference to FIG. FIG. 9 is a flowchart for explaining a REGISTER packet return process.

  The REGISTER packet return unit 134 first generates a new field of the new REGISTER packet in order to generate a new REGISTER packet (step S206-1). For example, the REGISTER packet return unit 134 of the node Y shown in FIG. 5 generates empty fields of “transmission source”, “hop count”, “destination”, “adjacent”, and “FID”.

  Next, the REGISTER packet return unit 134 sets its own node in the empty field “transmission source” (step S206-2). For example, as shown in step S104 of FIG. 5, the REGISTER packet reply unit 134 sets its own node “Y” as “transmission source”.

  Further, the REGISTER packet reply unit 134 sets “1” to the empty field “hop count” (step S206-3).

  Further, the REGISTER packet reply unit 134 sets the transmission source node of the HELLO packet in the empty field “destination” (step S206-4). For example, as shown in step S104 of FIG. 5, the REGISTER packet reply unit 134 sets the transmission source node “X” identified in the routing table update process to “destination”.

  Further, the REGISTER packet reply unit 134 sets its own node in the empty field “adjacent” (step S206-5). For example, as shown in step S104 in FIG. 5, the REGISTER packet reply unit 134 sets its own node “Y” to “adjacent”.

  The REGISTER packet return unit 134 sets “FID” of the HELLO packet in the empty field “FID” (step S206-6). For example, as shown in step S104 of FIG. 5, the REGISTER packet reply unit 134 sets the FID “1” included in the HELLO packet received in step S101.

  Then, the REGISTER packet return unit 134 transmits the REGISTER packet generated up to step S206-6 (step S206-7). For example, as shown in step S104 of FIG. 5, the REGISTER packet return unit 134 of the node Y transmits the generated REGISTER packet to the node X that has transmitted the HELLO packet to the node Y in step S101.

[Relay processing of REGISTER packet]
Next, the relay processing of the REGISTER packet will be described with reference to FIG. FIG. 10 is a flowchart for explaining the relay process of the REGISTER packet.

  The REGISTER packet relay unit 135 first sets a work packet as a temporary storage area having the same structure as the REGISTER packet in the work data unit 122, and copies the received REGISTER packet to the set work packet (step S211). -1). For example, the REGISTER packet relay unit 135 of the node Y shown in FIG. 5 copies the REGISTER packet received in step S108 to the work packet.

  Next, the REGISTER packet relay unit 135 adds 1 to the “hop count” copied to the work packet, and sets a new hop count (step S211-2). For example, the REGISTER packet relay unit 135 sets a new hop number “2” in the work packet.

  Further, the REGISTER packet relay unit 135 sets its own node to “adjacent” copied to the work packet (step S211-3). For example, the REGISTER packet relay unit 135 sets its own node “Y” to “adjacent”.

  The REGISTER packet relay unit 135 sets “FID” as it is to “FID” copied to the work packet (step S211-4). For example, the REGISTER packet relay unit 135 sets FID “1” to “FID”. The REGISTER packet relay unit 135 does not change the “transmission source” and “destination” copied to the work packet.

  Then, the REGISTER packet relay unit 135 generates a REGISTER packet for relay, and sets the content of the work packet in the generated REGISTER packet (step S211-5). For example, the REGISTER packet relay unit 135 of the node Y illustrated in FIG. 5 sets the transmission source “Z”, the number of hops “2”, the destination “X”, the adjacent “Y”, and the FID “1” in the generated REGISTER packet. To do.

  Thereafter, the REGISTER packet relay unit 135 transmits the REGISTER packet generated in step S211-5 (step S211-6). For example, the REGISTER packet relay unit 135 of the node Y shown in FIG. 5 transmits the generated REGISTER packet to the node X (see step S110).

[Effect of Example 2]
As described above, according to the second embodiment, when an arbitrary node in an ad hoc network to which a plurality of nodes are connected receives a HELLO packet for confirmation of existence from another node, the received HELLO packet is transferred to another node. Relay to a node different from the node. Also, the node identifies the source node that is the node that first transmitted the HELLO packet from the received HELLO packet, and sets the identified source node as the final destination of the REGISTER packet indicating that the node exists. . Then, the node transmits the REGISTER packet in which the final destination is set to the other node that has transmitted the HELLO packet to the node.

  For this reason, according to the second embodiment, it is possible to suppress the load on the network. That is, in the conventional method, each node that has received the HELLO packet returns a REGISTER packet only when the final destination is its own node, and when the final destination is not its own node, relays the HELLO packet to the adjacent node. It was only. For this reason, the transmission source node that is the transmission source of the HELLO packet must transmit HELLO packets by the number of other nodes recognized by the own node, and as the number of other nodes increases, the load on the network increases. It was.

  On the other hand, according to the second embodiment, each node that receives the HELLO packet relays the HELLO packet to another node and returns a REGISTER packet regardless of whether or not the final destination is its own node. To do. In other words, when the source node transmits one HELLO packet on the communication path, each node on the communication path relays the HELLO packet and returns a REGISTER packet. As described above, the existence of each node can be confirmed only by transmitting one HELLO packet from the transmission source node. As a result, the number of HELLO packets can be reduced, and the load on the network can be suppressed. .

  FIG. 11 is a diagram for explaining the effect of the second embodiment. For each number of nodes from the transmission source to the gateway, the conventional method (see “number of packets requiring the conventional method”) and the second embodiment are described. This is a comparison with a method (see “Number of Packets Required for Method of Example 2”). Here, the gateway node is a node connected to an external network, and it is assumed that the source node sets the gateway node as the final destination.

  Then, in the conventional method, when the number of nodes is “n”, the number of packets is required by “Σ2n”, whereas in the method of the second embodiment, “Σ2n−Σ (n−1)” packets are used. It will be understood that the number of packets can be reduced.

  Further, as described in the second embodiment, each node returns a REGISTER packet regardless of whether or not the final destination of the HELLO packet is set. That is, each node returns a REGISTER packet even if the final destination of the HELLO packet is not set in the HELLO packet. On the other hand, even when the final destination of the HELLO packet is set, each node returns a REGISTER packet regardless of whether or not the own node is set as the final destination of the HELLO packet.

  Further, as described in the second embodiment, each node stores the FID included in the received HELLO packet in the routing table. Then, each node determines whether or not a FID that matches the FID included in the received HELLO packet exists in the routing table, and if it exists, does not relay the HELLO packet to another node. For this reason, according to the second embodiment, it is possible to prevent a situation in which the same HELLO packet is continuously relayed.

  Although some of the embodiments have been described in detail with reference to the drawings, these are only examples, and various modifications and improvements can be made based on the knowledge of those skilled in the art including the aspects described in the column of the disclosure of the invention. It is possible to implement the present invention in other forms.

[Computer]
In the various processes described in the above embodiments, a program prepared in advance is stored in a storage medium such as a flexible disk (FD), a CD-ROM, an MO disk, a DVD disk, a magneto-optical disk, and an IC card. Can be realized by reading and executing the program from the storage medium. In the following, an example of a computer that reads and executes a control program having the same function as that of the above embodiment from a storage medium will be described with reference to FIG. FIG. 12 is a diagram illustrating a computer that executes a control program.

  As shown in FIG. 12, the control program (computer) 40 is a bus for a cache 41, a RAM (Random Access Memory) 42, an HDD (Hard Disk Drive) 43, a ROM (Read Only Memory) 44 and a CPU (Central Processing Unit) 45. 46 is connected. Here, the computer 40 reads the control program from the storage medium, and stores the request control information receiving program 44a, the request control information relay program 44b, and the presence control information return program 44c in the ROM 44.

  Then, the CPU 45 reads and executes these programs 44a to 44c, so that each of the programs 44a to 44c has a request control information reception process 45a, a request control information relay process 45b, and presence control as shown in FIG. The information return process 45c is performed. Each process 45a to 45c corresponds to the request control information reception unit 11, the request control information relay unit 12, and the presence control information return unit 13 shown in FIG.

DESCRIPTION OF SYMBOLS 1 Network 10 Specific terminal 11 Request control information receiving part 12 Request control information relay part 13 Existence control information reply part 20 Source terminal 30 Terminal 100 Node 110 Communication part 120 Storage part 121 Routing table part 122 Work data part 130 Control part 131 Packet Reception unit 132 Routing table update unit 133 HELLO packet relay unit 134 REGISTER packet return unit 135 REGISTER packet relay unit

Claims (8)

An arbitrary specific terminal in a network to which a plurality of terminals are connected receives request control information for requesting existence confirmation from another terminal, and processes the request control information.
A specific device
A receiving step of receiving request control information for requesting existence confirmation from another terminal;
Relaying the request control information received by the receiving step to a first terminal different from the other terminal and the specific terminal ;
From the request control information received by said receiving step, to identify the source terminal is a terminal that has transmitted the request control information first, which is uniquely generated by said specific terminal, said specific terminal is present reply transmitting as the final destination of the presence control information indicating to set the source terminal, the presence control information set of the final destination, to the other terminal that has sent the request control information to the specific terminal and,
The first terminal is
Receiving the request control information relayed by the relay step from the specific terminal;
Relaying the request control information received in the receiving step to a second terminal different from the source terminal, the other terminal, the specific terminal, and the first terminal;
The source terminal is identified from the request control information received in the reception step, and the first terminal is generated by the first terminal independently from the specific terminal. A return step of setting the source terminal as the final destination of the presence control information indicating, and transmitting the presence control information with the final destination set to the other terminal via the specific terminal . A control method characterized by that.   The control method according to claim 1, wherein a final destination of the request control information is not set in the request control information. In the request control information, a final destination of the request control information is set,
The specific terminal is
2. The control method according to claim 1, wherein, in the reply step, the presence control information is transmitted regardless of whether or not the own terminal is set as a final destination of the request control information. The specific terminal is
In the reception step, storing identification information for uniquely identifying the request control information included in the received request control information in a storage table;
In the relay step, the storage table is referenced to determine whether or not identification information that matches the identification information included in the received request control information exists in the storage table. The control method according to claim 1, wherein control information is not relayed to the first terminal. As a specific terminal in a network to which a plurality of terminals are connected, a control apparatus that receives request control information for requesting existence confirmation from another terminal and processes the request control information,
A receiving unit for receiving request control information for requesting existence confirmation from another terminal;
A relay unit that relays the request control information received by the receiving unit to a first terminal different from the other terminal and the specific terminal ;
From the request control information received by the receiving unit, to identify the source terminal is a terminal that has transmitted the request control information first, which is uniquely generated by said specific terminal, said specific terminal is present as the final destination of the existence control information indicating the source to set the terminal, the said presence control information set in the final destination, the reply unit for transmitting the request control information to the other terminal which transmits to the specific terminal It equipped with a door,
The first terminal is
A receiving unit that receives the request control information relayed by the relay unit from the specific terminal;
A relay unit that relays the request control information received by the receiving unit to a second terminal different from the source terminal, the other terminal, the specific terminal, and the first terminal;
The source terminal is identified from the request control information received by the receiver, and the first terminal is generated by the first terminal independently of the specific terminal. A return unit configured to set the source terminal as a final destination of presence control information indicating, and to transmit the presence control information in which the final destination is set to the other terminal via the specific terminal A control device characterized by that.   6. The control apparatus according to claim 5, wherein a final destination of the request control information is not set in the request control information. In the request control information, a final destination of the request control information is set,
6. The control apparatus according to claim 5, wherein the reply unit transmits the presence control information regardless of whether or not the own terminal is set as a final destination of the request control information. An arbitrary specific terminal in a network to which a plurality of terminals are connected is a storage medium that stores request control information for requesting existence confirmation from another terminal and stores a control program for processing the request control information,
A specific device
A reception procedure for receiving request control information for requesting existence confirmation from another terminal,
A relay procedure for relaying the request control information received by the reception procedure to a first terminal different from the other terminal and the specific terminal ;
The source terminal that is the terminal that first transmitted the request control information is identified from the request control information received by the reception procedure , and the specific terminal that is uniquely generated by the specific terminal exists. reply procedure as the final destination of the existence control information, sets the source terminal, the presence control information set of the final destination, and transmits the request control information to the other terminal which transmits to the specific terminal shown and,
The first terminal is
A reception procedure for receiving the request control information relayed by the relay procedure from the specific terminal;
A relay procedure for relaying the request control information received by the reception procedure to a second terminal different from the source terminal, the other terminal, the specific terminal, and the first terminal;
The source terminal is identified from the request control information received by the reception procedure, and the first terminal is generated by the first terminal independently from the specific terminal. The transmission source terminal is set as the final destination of the presence control information indicating, and the return procedure for transmitting the presence control information with the final destination set to the other terminal via the specific terminal is executed A storage medium for storing a control program.

Images