JP2007201663A - Communication node - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a technology whereby a user of a sender communication node can detect a timing of detecting a presence of other communication node by means of a freely designated timing because a watcher cannot freely determine its polling interval due to constraints from an IMPP server in the IMPP and more concretely to provide a poller whereby the user can freely designate a time interval in executing polling by neglecting constraints of a broker. <P>SOLUTION: The user employs uses on-line/off-line confirmation to designate the time interval so as to be able to detect the on-line/off-line of a communication opposite party or state information of the communication opposite party at the time interval. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a destination discovery process for a communication node having a dynamic address and state detection for a communication partner in a storage and switching network.

WO2004 / 059925

A terminal used by a general user after commercialization of the Internet is a terminal that has a fluctuating address and does not have an identifier that identifies the communication partner. There was a demand to communicate with such terminals. The first attempt was to set up a static identifier that uniquely identifies the communication partner (hereinafter referred to as "static identifier"), and to identify the communication partner in a system that follows a fluctuating address. It was to entrust to do. Examples of such a system include webhop, IMPP (RFC2778, RFC2779), dynamic DNS (RFC2136, RFC3007), SIP (RFC3261-3265, RFC3856), ENUM (RFC2916, RFC3401-3406, RFC3761), and the like.
At this time, since communication could not be started unless the communication partner was online, it was important to know the reachability of the communication partner before starting the actual communication. This is the background that required presence.

RFC2778 defines a fetcher and a subscriber among watchers. The fetcher includes a polar.
Among the systems, those that provide presence are SIP and IMPP. SIP is a subscriber type and IMPP is a polar type.

Hereinafter, it will be shown for the polar that the timing of detecting the presence of the communication partner is determined by the relationship with the broker.
IMPP registered its own node status information along with “registration update” for discovering the destination of its own node, and also detected the presence of a pre-registered communication partner (commonly called “buddy” in IMPP) .
FIG. 18 shows an example in which Buddy B detects the presence of Buddy A.
Presence includes at least online / offline (= reachability) and may include state information (actually just a message) of a communication partner.
In the buddy A, “registration update” is performed and the status information of itself is registered in the broker (presence service referred to in RFC 2778) (step S1-a).
In the buddy B, the “registration update” is performed in the same manner as the buddy A, and the state information of itself is registered in the broker (step S1-b). Then, the presence of the buddy pre-registered at the same timing (buddy A in the figure) is acquired from the broker (step S2-b).
The presence of buddy A that buddy B knows at this time is based on the "registration update" and presence registration that buddy A was S1-a.
In other words, the broker propagates step S1-a to buddy B in association with step S2-b (step S3).
If step S1-a is not received for a certain period of time, the broker discards the registration of Buddy A due to a timeout (= expire). At this time, the broker switches the presence of buddy A known by buddy B from online to offline through S2-b.

That is, the “registration update” from the edge node must be done before the registration is expired at the broker. From this, it can be said that “registration update” corresponds to keep-alive.
At this timing, the presence of the communication partner is also detected.

From the above, the presence detection timing is set at an interval shorter than the expiration time of registration performed by the broker. Even if the user on the presence detection side can specify the timing, the limit is bound by the timing of “registration update”. This means that the broker constrains the timing of presence detection.
Therefore, in the IMPP model, only a more limited form of the polar in the fetcher is realized, and the fetcher itself is not realized.

On the other hand, in Patent Document 1, a source communication node detects whether a destination communication node is online or offline in a network in which reachability is obtained by associating a static identifier with a dynamic address. Means for doing so are disclosed.

It is possible to detect the timing at which the user of the source communication node detects the presence of another communication node at a freely specified timing.
More specifically, a poller that allows the user to freely specify the time interval for polling, ignoring the restrictions of the broker, is realized.

  By applying Patent Document 1, the user designates a time interval, and the online / offline trap of the communication partner can detect the status information of the communication partner at the time interval.

(table of contents)
(Embodiment 1) This is a case without additional information. Changes in reachability of communication nodes are detected and displayed at time intervals specified by the user.
(Embodiment 2) This is a case with additional information. Detects and displays communication node status information at time intervals specified by the user.
(Embodiment 3) This is a case where an action is performed by event matching. An event / goal is set for a change in the state of the communication node, and when this is detected, a preset action is taken.

(Term correspondence)
Mapping announcement system 30≈IMPP server = broker.
Second communication node 20 = Buddy B = Communication node that detects presence.
First communication node 10 = buddy A = presence detected communication node.

1. A change in the state of the destination communication node (亦 is a user of the destination communication node) is detected and displayed at a time interval designated by the user of the source communication node.
2. An expected state of the destination communication node (亦 is a user of the destination communication node) can be set as a goal, and the user of the source communication node can be alerted when the goal is reached.
3. By using reachability confirmation, the communication node ろ う who wants to know the presence without relying on “registration renewal” can detect the presence of the communication partner at that time of the communication node. Made possible.
Thus, flexible presence detection is realized, and the convenience of the user (especially the source communication node) is improved.

  Hereinafter, the present invention will be described with reference to the drawings. In addition, the same code | symbol is attached | subjected to the location which has the same function in each drawing. The following examples are illustrative rather than limiting.

(Whole network block diagram)
FIG. 01 is a block diagram showing the entire network in the present invention. In FIG. 01, a first communication node 10, a second communication node 20, and a mapping notification system 30 that returns the address of the first communication node 10 in response to an inquiry from the communication node are connected to a network 40 such as the Internet. It shows a state of being connected to each other.

Example 1
FIG. 02 shows a block configuration of the second communication node 20 shown in FIG. FIG. 02 shows a storage device 210 including a temporary work storage, a destination designation unit 220, a transmission unit 230, and a physical communication interface 290 for connecting to the network 40.

The storage device 210 includes registered destination information 211 and destination information 212.
The registered destination information 211 is information on destinations registered in advance. The registered destination information 211 may be a table composed of a plurality of destination records. The format per record is shown in FIG.
The destination information 212 may be a table including at least one record shown below. One record includes a static identifier 213 indicating a destination, a reply 214 to be answered, a specified time interval 215, and a destination address 216. The static identifier 213 indicating a destination is a static identifier of the destination. Is memorized.
The reply to be answered 214 stores the reply to be answered from the destination.
The designated time interval 215 stores a designated time interval for polling for each destination.
The destination address 216 stores an address corresponding to the static identifier of the destination obtained from the response from the mapping notification system 30.

  The destination designation unit 220 provides a user with means for designating a communication node for which presence detection is desired. The destination designation unit 220 includes a user interface (not shown). A typical example of a user interface consists of a screen and a keyboard. The destination specifying unit 220 generates destination information 212.

The transmission unit 230 may receive not only the transmission but also the reception. The essence is to confirm reachability to the destination communication node.
The transmission unit 230 includes an address acquisition unit 231, a sign signal transmission unit 232, a counter sign signal reception unit 233, a determination unit 234, a display unit 239, and a timer 240 described below.
The address acquisition unit 231 acquires the address of the destination communication node by querying the mapping notification system for a static identifier related to the first communication node.
The sign signal transmission unit 232 transmits a sign signal to the address acquired by the address acquisition unit 231.
The counter sign signal receiving unit 233 receives a counter sign signal transmitted from another communication node and temporarily stores it.
The determination unit 234 performs reachability confirmation as to whether or not the counter sign signal is transmitted from a desired communication node based on the temporarily stored reply.
The display unit 239 includes a user interface and connects the result of reachability confirmation to the user of the second communication node and the subsequent process performed by the second communication node.
The timer 240 measures time.

FIG. 03 shows a flowchart of the second communication node 20.
In step S202, whether the destination designation unit 220 reads the registered destination information 211 in accordance with an instruction from the user generates the destination information 212 by manual input from the user.

  FIG. 04 shows a screen example in the case of manual input. In FIG. 04, the “static identifier” of the destination is input in the input field 1, “answer to be answered” is input in the input field 2, and the specified time interval is selected from the pull-down menu. Input in the input field 1 is essential. The input field 2 can be omitted when the “static identifier” and the “answer to be answered” are the same. The “reply to be answered” may be a rule as well as a character string from Patent Document 1. The specified time interval may be specified by providing an input field 3 (not shown) instead of a pull-down menu. Also, the specified time interval can be omitted.

Based on these pieces of information, the destination designation unit 220 generates destination information 212. The destination information 212 includes a static identifier 213 indicating the destination, a reply 214 to be answered from the destination, a specified time interval 215, and a destination address 216.
The information input in the input field 1 of the screen example shown in FIG. 04 is copied to the static identifier 213 indicating the destination by the destination specifying unit 220.
If the information entered in the input field 2 in FIG. 04 has contents, the destination designating unit 220 copies it to the reply 214 to be answered from the destination. If no information is input in the input field 2 in FIG. 04, the destination specifying unit 220 copies a static identifier 213 indicating the destination to a reply 214 to be answered from the destination.
The destination designation unit 220 copies the value of the pull-down menu selected by the user to the designated time interval 215. When an input field 3 (not shown) is prepared instead of the pull-down menu, the contents of the input field 3 are copied to the specified time interval 215. The unit may be seconds or time. The bag can be specified once a day. If there is no explicit designation, a default value (not shown) may be copied. Even in this case, unlike the case of IMPP, this default value can be determined by the developer by the user without relying on restrictions from the broker.
Note that the destination address 216 may be empty at this point. As a precaution, the destination address 216 may be initialized at this point. In this way, the destination designation unit 220 generates a record of the destination information 212.
The format of the destination information 212 is shown in FIG. The destination information 212 may be generated prior to processing and disappears upon completion of processing.

  The information input by the user in this way may be stored in the registered destination information 211 in order to save the trouble of input next time. The information stored in the registered destination information 211 is shown as a format in FIG. The format includes at least a static identifier of the destination, and includes a reply to be answered if necessary, and preferably a specified time interval. Other information may be included. From the next time onward, it is sufficient to display the registered destination information 211 as a list and specify a target partner from the list.

After step S204, the process loops up to step S220. An interrupt or the like may be used when exiting the loop.
In step S204, the address acquisition unit 231 makes an inquiry to the mapping notification system 30 with the static identifier 213 indicating the destination.

  In step S <b> 206, the address acquisition unit 231 checks whether there is a response from the mapping notification system 30. If there is a response, the process proceeds to step S208. If there is no response, the process branches to step S218. If there is no response, an alert (not shown) may be given because there is a high possibility that there is a problem with the mapping announcement system 30.

  In step S <b> 208, the address acquisition unit 231 sets the address included in the reply from the mapping notice system in the destination address 216. The address designation unit 220 may be set instead of the address acquisition unit 231.

  In step S <b> 210, the sign signal transmission unit 232 transmits a sign signal to the destination address 216.

  In step S <b> 212, the counter sign signal receiving unit 233 receives a counter sign signal from the first communication node 10. The counter sign signal may not be received.

  In step S214, the determination unit 234 determines whether the reachability to the first communication node 10 is true or not because the received countersign signal 亦 has not received the countersign signal. If the reachability check result is true, the process proceeds to step S216. If false, the process branches to step S218.

  In step S216, the display unit 239 displays that the first communication node 10 is online.

  In step S218, the display unit 239 displays that the first communication node 10 is offline. From Patent Document 1, the display is not necessarily limited to the console, but may be other means.

  In step S220, the timer 240 waits for the time specified in the specified time interval 215, and then starts again from step S204 at the head of this loop. That is, the designated time interval 215 is a polling interval.

(Modification of Example 1)
A modification in which an application-like solution for reducing traffic disclosed in Patent Document 1 is applied to the first embodiment will be described. Compared with Patent Document 1, the decision branch before step S204 is omitted. Unlike Patent Document 1, the present invention does not reduce only DNS traffic. Reducing traffic is especially effective in the case of Polar.

  FIG. 06 shows a block configuration of the second communication node 20 shown in FIG. FIG. 06 shows a storage device 210 including a temporary storage for work, a destination designation unit 220, a transmission unit 230, and a physical communication interface 290 for connecting to the network 40.

The storage device 210 includes registered destination information 211 and destination information 212.
Since the registered destination information 211 is not changed, the description thereof is omitted. Only the changes will be described below.
In the destination information 212, a flag 217 is added to the information shown in FIG.
The flag 217 is used in loop control for reducing traffic, and its meaning is for determining that the second loop is to be turned only when offline.
The format of the destination information 212 is shown in FIG.

The transmission unit 230 has a flag processing unit 235 added to that shown in FIG.
The flag processing unit 235 determines whether it is the first loop or the second loop by looking at the flag 217, and performs loop control. The flag 217 is also switched on / off.

FIG. 07 shows a flowchart of the second communication node 20.
Compared with the case of the first embodiment, only changes will be described below.
In step S202, the destination designating unit 220 turns on the flag 217.

  If NO in step S206 and step S214, the process branches to step S410 instead of step S218.

  In step S410, it is determined whether the flag is on or off. If it is on, the process proceeds to step S218. If it is off, the process branches to step S412.

  In step S412, the flag 217 is set to ON. This will enter the second loop. The destination of the loop is not step S210 but step S204.

  In step S216 and step S218, the process proceeds to step S414 instead of proceeding to step S220.

In step S414, the flag 217 is turned off.
In step S220, the loop destination is changed as compared to the case of the first embodiment. The destination of the loop is not step S204 but step S210.
In summary, traffic can be reduced and the load on the mapping announcement system 30 can be reduced as follows. In the first processing, the mapping notice system 30 is always inquired. Since the destination address 216 is stored after the first processing, the query to the mapping notice system 30 is omitted and this is simply looped (this is referred to as “first loop”). When the address of the first communication node 10 changes, the stored destination address 216 is already old information, so that offline detection is always detected. Therefore, if the inquiry to the mapping notification system 30 is omitted, it cannot be determined that the first communication node 10 is actually offline. Therefore, only when offline detection is performed, the inquiry from the mapping notification system 30 is retried and the reachability confirmation is performed again with the latest destination address 216 (this is called “second loop”).

(Example 2)
In PCT / JP2005 / 011775 (hereinafter referred to as “Patent Document 2”) that has not been disclosed at the time of filing of the present application by the same applicant as the present invention, the status of the communication partner is not just online / offline. A means for detecting information is disclosed. In summary, the first communication node 10 embeds status information as additional information in the countersign signal and carries it, and the second communication node 20 separates the additional information from the countersign signal and detects the status information of the communication partner. That's it.

  FIG. 08 shows a block configuration of the second communication node 20 shown in FIG. FIG. 08 shows a storage device 210 including a temporary storage for work, a destination designation unit 220, a transmission unit 230, and a physical communication interface 290 for connecting to the network 40.

  The storage device 210 includes registered destination information 211 and destination information 212. This is the same as that shown in the first embodiment. Only the changes to the first embodiment will be described below.

The transmitter 230 has an additional information processor 236 added to that shown in FIG.
The additional information processing unit 236 performs processing related to additional information.

FIG. 09 shows a flowchart of the second communication node 20.
Compared with the case of the first embodiment, only changes will be described below.
If YES in the determination branch in step S214, the process proceeds to step S610.

  In step S610, the additional information processing unit 236 determines whether additional information is included in the counter sign signal. If additional information is not included, the process branches to step S216. If additional information is included, the process proceeds to step S612.

  In step S612, the additional information processing unit 236 extracts additional information from the counter sign signal.

  In step S614, the display unit 239 displays additional information. The bag clearly indicates that the first communication node 10 is online and displays additional information. Thereafter, the process proceeds to step S220.

  In step S220, the timer 240 waits for the specified time interval 215 specified by the user, and then loops to step S204. The method for specifying the polling interval is as described in the first embodiment.

(Modification of Example 2)
The modification with respect to Example 2 is shown. The content of the modification is the same as the modification of the first embodiment with respect to the first embodiment. By omitting the inquiry to the mapping notification system 30 at the normal time, the traffic is reduced and the load of the mapping notification system 30 is reduced.

  FIG. 10 shows a block configuration of the second communication node 20 shown in FIG. FIG. 10 shows a storage device 210 including a temporary storage for work, a destination designation unit 220, a transmission unit 230, and a physical communication interface 290 for connecting to the network 40.

The storage device 210 includes registered destination information 211 and destination information 212.
In the destination information 212, a flag 217 is added to the information shown in FIG.
The flag 217 is used in loop control for reducing traffic, and its meaning is for determining that the second loop is to be turned only when offline.

The transmission unit 230 has a flag processing unit 235 added to that shown in FIG.
The flag processing unit 235 determines whether it is the first loop or the second loop by looking at the flag 217, and performs loop control. The flag 217 is also switched on / off.

FIG. 11 shows a flowchart of the second communication node 20.
Compared with the case of the second embodiment, only changes will be described below.
In step S202, the destination designating unit 220 turns on the flag 217.

  If NO in step S206 and step S214, the process branches to step S410 instead of step S218.

  In step S410, it is determined whether the flag is on or off. If it is on, the process proceeds to step S218. If it is off, the process branches to step S412.

  In step S412, the flag 217 is set to ON. This will enter the second loop. The destination of the loop is step S204. As a result, the second loop is made from an inquiry to the mapping announcement system 30, and conversely, in the first loop, the inquiry to the mapping announcement system 30 can be omitted. Can be reduced.

  In step S216, step S218, and step S614, the process proceeds to step S414 instead of proceeding to step S220.

  In step S414, the flag 217 is turned off.

In step S220, the loop destination is changed compared to the case of the second embodiment. The destination of the loop is not step S204 but step S210.

(Example 3)
FIG. 12 shows a block configuration of the second communication node 20 shown in FIG. FIG. 12 shows a storage device 210 including a temporary work storage, a destination designation unit 220, a transmission unit 230, and a physical communication interface 290 for connecting to the network 40.

The storage device 210 includes registered destination information 211 and destination information 212.
An event goal and an action description are added to the format of the registered destination information 211. The format per record is shown in FIG.
In the destination information 212, an event goal 218 and an action description 219 are added to the information shown in FIG.
The event goal 218 is for matching additional information.
The action description 219 describes a process to be executed when the additional information matches the event goal.

In the transmission unit 230, an event matching unit 237 and an action unit 238 are added to those shown in FIG.
The event matching unit 237 determines whether or not the event goal 218 matches the received additional information.
The action unit 238 executes the process described in the action description 219.

FIG. 13 shows a flowchart of the second communication node 20.
In step S202, when the user manually inputs the destination specification unit 220 before generating the destination information 212, the event goal and the description of the action are input fields not shown in the input screen shown in FIG. 4 and an input field 5 (not shown) are prepared and input.
The destination designation unit 220 copies the content of the input field 4 input in this way to the event goal 218 and copies the content of the input field 5 to the action description 219.
Of course, similar information may be stored in the registered destination information 211 for the next and subsequent times. In addition, when the same contents are already stored in the registered destination information 211, the contents of the registered destination information 211 may be read and replaced with manual input. In this way, the destination designation unit 220 generates the destination information 212. The action description 219 may be a method of calling a process.

Compared with the case of the second embodiment, only changes will be described below.
In step S612, after the additional information processing unit 236 extracts additional information from the counter sign signal, the process proceeds to step S810 instead of step S614.

  In step S810, the event matching unit 237 determines whether or not the extracted additional information matches the event goal 218. The matching may have a width. If they match, the process proceeds to step S812. If they do not match, step S812 is skipped and the process proceeds to step S614.

  In step S812, the action unit 238 executes the process described in the action description 219. It should be noted that, depending on the description of the action description 219, a break may be made at the end of the action to exit the process.

  Thereafter, the process proceeds to step S614 and step S220 as in the second embodiment.

  In step S220, the timer 240 waits for the specified time interval 215 specified by the user, and then loops to step S204. The method for specifying the polling interval is as described in the second embodiment.

(Modification of Example 3)
The modification with respect to Example 3 is shown. The content of the modification is the same as the modification of the first embodiment with respect to the first embodiment. By omitting the inquiry to the mapping notification system 30 at the normal time, the traffic is reduced and the load of the mapping notification system 30 is reduced.

  FIG. 14 shows a block configuration of the second communication node 20 shown in FIG. FIG. 14 shows a storage device 210 including temporary storage for work, a destination designation unit 220, a transmission unit 230, and a physical communication interface 290 for connecting to the network 40.

The storage device 210 includes registered destination information 211 and destination information 212.
In the destination information 212, a flag 217 is added to the information shown in FIG.
The flag 217 is used in loop control for reducing traffic, and its meaning is for determining that the second loop is to be turned only when offline.

The transmission unit 230 has a flag processing unit 235 added to that shown in FIG.
The flag processing unit 235 determines whether it is the first loop or the second loop by looking at the flag 217, and performs loop control. The flag 217 is also switched on / off.

FIG. 15 shows a flowchart of the second communication node 20.
Compared with the case of the third embodiment, only changes will be described below.
In step S202, the destination designating unit 220 turns on the flag 217.

  If NO in step S206 and step S214, the process branches to step S410 instead of step S218.

  In step S410, it is determined whether the flag is on or off. If it is on, the process proceeds to step S218. If it is off, the process branches to step S412.

  In step S412, the flag 217 is set to ON. This will enter the second loop. The destination of the loop is step S204. As a result, the second loop is made from an inquiry to the mapping announcement system 30, and conversely, in the first loop, the inquiry to the mapping announcement system 30 can be omitted. Can be reduced.

  In step S216, step S218, and step S614, the process proceeds to step S414 instead of proceeding to step S220.

  In step S414, the flag 217 is turned off.

In step S220, the loop destination is changed compared to the case of the third embodiment. The destination of the loop is not step S204 but step S210.

(Practical application)
Using Example 3, a scheduled action notification / target achievement notification will be realized.
As an example, when the second communication node 20 detects that the first communication node 10 has moved and reached the destination, the red light is turned. This is shown in FIG.

It is assumed that the first communication node 10 carries the GPS sentence shown in FIG. 17 as additional information included in the countersign signal.
In the second communication node 20, additional information desired to be carried from the first communication node 10 at the goal point in the same format as the GPS sentence shown in FIG. 17 is stored in the event goal 218. It is assumed that the action description 219 describes turning a red light that is an external device viewed from the second communication node 20 via an interface of the second communication node 20 (not shown).

  When the first communication node 10 moves from the 10-a point shown in FIG. 16 to the 10-b point, the second communication node 20 continues polling, and from this, the countersign signal carrying additional information, When the second communication node 20 detects that the first communication node 10 has reached the goal point, the second communication node 20 can turn on the red light according to the third embodiment.

Here, the second communication node 20 explicitly notifies the human arrival by turning the red light when the first communication node 10 has moved. However, the second communication node 20 can be applied to all uses including automation processing. Of course, at this point, a voice call may be made as in the conventional case.
For example, in this example, the first communication node 10 may not know the geographical position of the own node. This is an advantage. For example, when the first communication node 10 has a communication function but many functions cannot be packed due to many restrictions on hardware, the function is used instead of the first communication node 10. Can be borne by the second communication node 20.

(Musubi)
In the following, comparison with IMPP will be attempted.
Common points with IMPP.
Presence detection.

Differences from IMPP.
1. Watchers and presentities need not be equivalent.
In IMPP, both communicating ends switch roles of watcher and presentity. That is, each other detects the state of the communication partner. In the present invention, the second communication node 20 detects the state of the first communication node 10. However, if the same thing is done on the first communication node 10 side, they can be detected with each other. The inventor believes that it is not essential to detect each other at both ends (that is, it is established only in one direction), which contributes to scalability.
2. Do not log in.
Unlike IMPP, this proposal does not display whether the communication partner is offline or online when logging in. Of course, it is not essential to pre-register the communication partner (it is good to pre-register for the convenience of the user).
3. No restrictions on polling interval from broker.
As shown in the effect. It is not always necessary to detect presence at the same timing as keep alive. When real-time capability is required, real-time processing can be easily performed by polling at an arbitrary short time interval.
4). Subsequent communications may not be IM.
From the above, the watcher and the presentity are completely separated, and no login is required. That is, unlike the presence service realized by IMPP, it proposes an unprecedented way of presence detection.

It is a whole network block diagram. 3 is a block diagram of a second communication node 20 according to Embodiment 1. FIG. 4 is a flowchart of the second communication node 20 according to the first embodiment. It is an example of an input screen. Record format. It is a block diagram of the 2nd communication node 20 concerning Example 1 modification. It is a flowchart of the 2nd communication node 20 which concerns on Example 1 modification. FIG. 6 is a block diagram of a second communication node 20 according to the second embodiment. 10 is a flowchart of the second communication node 20 according to the second embodiment. It is a block diagram of the 2nd communication node 20 which concerns on Example 2 modification. It is a flowchart of the 2nd communication node 20 which concerns on Example 2 modification. FIG. 10 is a block diagram of a second communication node 20 according to the third embodiment. 10 is a flowchart of the second communication node 20 according to the third embodiment. It is a block diagram of the 2nd communication node 20 which concerns on Example 3 modification. It is a flowchart of the 2nd communication node 20 which concerns on Example 3 modification. It is an image figure of practical application. It is an example of a sentence of GPS. It is a figure which shows a prior art.

Explanation of symbols

10 First communication node
20 Second communication node
30 Mapping announcement system
40 mesh

20 Second communication node (S)
210 Storage device 210
211 Registered destination information 211
212 Destination information 212
213 Static identifier 213 indicating the destination
214 Replies to be answered from the destination 214
215 Specified time interval 215
216 Address 216
217 flag 217
218 Event Goal 218
219 Action Description 219
220 Destination specifying unit 220 (record generation unit for each destination)
230 Transmitter 230 (reachability confirmation unit)
231 Address acquisition unit 231
232 Sign signal transmission unit 232
233 Counter sign signal receiver 233
234 determination unit 234
235 Flag processing unit 235
236 Additional information processing unit 236
237 Event Matching Section 237
238 Action part 238
239 Display 239
240 Timer 240
290 Communication interface

Claims (1)

In a storage and switching network in which a destination is discovered by associating a static identifier with a dynamic address, if the correctness of reachability is not confirmed for a certain period of time, the communication node for which reachability is confirmed A method of reducing misperception in a destination discovery process by not responding to a countersign.