JP2010288101A - Emergency notification method and system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an emergency notification method which can send an emergency quick report surely and real-time when an emergency occurs, and always keeps a distributable state, and to provide an emergency notification system in which a reception terminal can be installed simply, and is easy to use for anyone. <P>SOLUTION: The life and death confirmation signal and DDNS data of a connectionless protocol format are distributed in a scheduled time from a center server to each reception terminal, the reception terminal sends a reply signal to the center server responding to the life and death confirmation signal, thereby the center server determines the reception terminal which sends the reply signal from each terminal management number. When an emergency occurs, the center server receives the emergency quick report, and distributes quick report data of the connectionless protocol format to each reception terminal. If authentication confirmation data accords with a reception authentication code, the reception terminal receives the quick report data and sends back the reply signal with a terminal management number to the center server. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to an emergency call method in which an emergency call can be transmitted reliably and in real time in the event of an emergency such as an earthquake, and a distributable state is always established. It relates to an emergency call system.

  As an example of an emergency call, an emergency earthquake bulletin is the most common. With this earthquake early warning, the occurrence of an earthquake is detected quickly by observing the P wave (primary wave), which is a weak longitudinal wave that arrives relatively early, and the S wave (secondary wave) that is the main motion of the earthquake arrives. This is an attempt to minimize physical and human damage caused by S waves by reporting to the residents of S wave arrival areas. The earthquake early warning technology can identify the magnitude and epicenter of an earthquake by capturing P waves by constant observation and analyzing their characteristics. The Earthquake Early Warning technology has built an epicenter determination system that identifies the magnitude and location of an earthquake based on information from an earthquake observation network such as a multifunction seismometer owned by the Japan Meteorological Agency.

  The earthquake early warning is important in carrying out disaster prevention activities, and is expected to be widely spread for cost reduction by linking it with systems such as home security and information appliances. In recent earthquake information application methods, for example, Patent Documents 1 to 4 propose a device or system including a mobile terminal such as a mobile phone that receives an earthquake early warning. Has built a platform that includes the distribution of emergency earthquake alerts, data owners, information processing / providers, network / broadcast operators, and various disaster prevention system administrators.

  In the above application method, the earthquake early warning data is distributed from the server using the Internet line network or the dedicated line network. However, when the number of the breaking point distribution destination reaches several thousand orders, the transmission level is TCP / IP ( When push communication is performed using a normal connection-type protocol format such as Transmission Control Protocol / Internet Protocol), there is a time lag of several seconds in the transmission data at the distribution destination, and some distribution destinations cannot receive emergency earthquake early warnings urgently Occurs. In addition, these application methods are convenient because they send emergency earthquake bulletins to mobile terminals, etc., but they are used in a manner that is not used once a year because of the occurrence of moderate or greater earthquakes. Therefore, if it is not always confirmed that the earthquake notification system is actually operating, when the earthquake actually occurs, it may happen that the system does not operate and cannot be delivered.

JP 2005-283491 A JP 2005-295290 A JP 2006-145234 A JP 2006-148222 A JP 2005-326149 A JP 2007-110302 A

  In order to reduce the time lag of data distribution in push communication, it is preferable that the transmission level is distributed by a connectionless protocol format such as UDP / IP (User Datagram Protocol / Internet Protocol) format. Even if a packet is lost, it is not retransmitted, and it is not guaranteed that data is reliably delivered to all terminals. Such uncertain communication procedures cannot be used for distribution of earthquake early warnings that require strong transmission. In order to compensate for an uncertain communication procedure using the connectionless protocol format, Patent Document 6 includes two servers: a server that reliably communicates in the TCP / IP format and a server that communicates at high speed in the UDP / IP format. Configure emergency call system. In Patent Document 6, a reliable and high-speed communication procedure is established by transmitting to a delivery destination at a high speed in a high-speed UDP / IP format and communicating from the delivery destination in a reliable TCP / IP format.

  In Patent Document 6, responses from a number of distribution destinations are transmitted in a low-speed TCP / IP format. For example, earthquakes in the same area are short, such as a swarm earthquake off Izu Peninsula and Ito-Kawana that occurred in 2006. If it occurs frequently in time, the early warning of the subsequent earthquake may be delayed, and since the operation of the emergency call system has not been confirmed at all times, the system may not be able to deliver when an earthquake actually occurs It can happen. In Patent Document 6, the emergency call system distribution server requires at least two servers, a TCP / IP format communication server and a UDP / IP format communication server, so this emergency call system is relatively expensive. It becomes a system. Further, in the emergency call system of Patent Document 6, if a hacker sends fake earthquake data to a communication network for a pleasant crime, each earthquake alarm device receives the fake earthquake data as it is and receives an earthquake warning. Will be confused by society with false information.

  The present invention has been proposed in order to improve the above-mentioned problems related to the conventional emergency earthquake system and to distribute emergency information reliably, and includes preliminary data from the center server and response signals from each receiving terminal ( Ack signal) is transmitted in substantially connectionless protocol format, and the purpose is to provide an emergency notification method and system in which emergency information can be completed in a short period of time even when the number of destinations for breaking news is thousands or more. Yes. Another object of the present invention is to provide an emergency notification method and system in which the breaking data is not changed or lost even when the breaking data is transmitted at a high speed in a connectionless protocol format, and the distributable state is always established. It is to be.

  Another object of the present invention is that if the reception authentication code stored in the receiving terminal matches the authentication confirmation data included in the breaking data, the receiving terminal receives the breaking data, and the receiving terminal is false. It is to provide an emergency call method that can eliminate the reception of preliminary data. Another object of the present invention is to always confirm that the system is in a distributable state by sending a life / death confirmation signal transmitted from the center server at regular intervals, and to accurately adjust the time of the receiving terminal. It is to provide an emergency call method. Another object of the present invention is to provide an emergency notification method in which the center server can always accurately recognize the IP address of the receiving terminal even if the global IP address of the receiving terminal is dynamic. Still another object of the present invention is to provide an emergency call system that reduces the burden on a receiving terminal by configuring the center server as a set of at least a receiving server and a calculation distribution server and enabling high-speed calculation by the calculation distribution server. Is to provide.

  The emergency notification method according to the present invention distributes emergency information in real time from a center server to a plurality of receiving terminals via a communication network. In this emergency call method, a connectionless protocol format alive confirmation signal is periodically distributed from the center server to each receiving terminal, and in response to this alive confirmation signal, the receiving terminal sends a response signal with a terminal management number to the center server. The center server determines the receiving terminal that has returned the response signal from the IP head unit, and redistributes the same alive confirmation signal for the receiving terminal that has not returned the response signal. Is always established. In the event of an emergency, the center server receives emergency bulletins and distributes bulletin data in connectionless protocol format to each receiving terminal. By returning the response signal, the center server determines the receiving terminal that has returned the response signal from its IP head unit, and retransmits the same breaking data for the receiving terminal that has not returned the response signal, thereby urgent information. Make sure to report.

  In another emergency call method according to the present invention, DDNS (Dynamic Domain Name System) data with a terminal management number in a connectionless protocol format is periodically transmitted from each receiving terminal to the center server, and this DDNS data is transmitted. On the other hand, the center server determines each receiving terminal from the IP head part of the data, and the center server returns a DDNS response signal to each receiving terminal. In the event of an emergency, the center server receives emergency bulletins and distributes bulletin data in connectionless protocol format to each receiving terminal. By returning the response signal, the center server determines the receiving terminal that has returned the response signal from its IP head unit, and retransmits the same breaking data for the receiving terminal that has not returned the response signal, thereby urgent information. Make sure to report.

  In the emergency call method according to the present invention, a DDNS response signal or a life / death confirmation signal with a reception authentication code is transmitted from the center server to each receiving terminal, the receiving terminal stores a plurality of the reception authentication codes, and the center server When the emergency bulletin is received, the bulletin data in which the data length including the header part and the authentication confirmation data is stored in one packet is distributed to each receiving terminal, and this authentication confirmation data matches the reception authentication code stored in the receiving terminal. For example, it is preferable that the receiving terminal receives the preliminary data. In particular, if the authentication confirmation data included in the breaking news data distributed in the event of an emergency situation matches any of the past 2-5 generations of reception authentication codes stored in the receiving terminal, the emergency notification signal is correct. Each receiver terminal is authorized and receives the preliminary data. Further, if the response signal is not returned from the receiving terminal even if the same alive confirmation signal is transmitted a plurality of times, the center server counts the number of distribution interruptions to the receiving terminal and returns to the distribution state. On the other hand, if the receiving terminal does not return a response signal even if the early warning data, which is the same emergency early warning, is sent multiple times from the center server, it is preferable to stop sending the early warning data and return to the standby state. .

  In the emergency notification method according to the present invention, a timeless signal in a connectionless protocol format is distributed on a regular basis from the center server to each receiving terminal, and the receiving terminal returns a response signal to the center server in response to this timely signal, Each receiving terminal can adjust the time by receiving the time signal data of the time signal. Typically, emergency information is emergency earthquake information, and this emergency earthquake information is created based on emergency earthquake bulletins distributed from the Japan Meteorological Agency and the Meteorological Operations Support Center as needed. In addition, the receiving terminal requests port assignment to the router at regular intervals to update the port number. When port assignment is rejected, UPnP ( It is preferable to operate so as to reset the private address and port number acquired by the Universal Plug and Play operation and request resetting of the private address and port number.

  In the emergency call system according to the present invention, a center server that transmits emergency information in real time via a communication line network, a plurality of routers connected to the center server via a communication line network, and connected to the router And at least one receiving terminal. This center server includes a receiving server that creates earthquake authentication data at regular intervals and receives emergency bulletins, and an arithmetic distribution server that calculates the seismic intensity and distribution order of breaking earthquakes at the location of each receiving terminal at high speed. Including. In the event of an emergency situation, the calculation distribution server creates breaking data in which the data length including the header is stored in one packet from the breaking information, and distributes the breaking data to each receiving terminal in a connectionless protocol format. When the receiving terminal returns a response signal in the connectionless protocol format to the center server, the center server determines the receiving terminal that has returned the response signal from its IP head unit.

  In the emergency call system of the present invention, the center server includes a DDNS server, records the global IP addresses of all receiving terminals in the DDNS server, and associates the device ID, global IP address, and port number of each receiving terminal. It is preferable to update the global IP address from the DDNS server to the calculation distribution server. In addition, a call button or the like is wirelessly connected to the receiving terminal, and when the receiving terminal receives a signal from the call button or the like, the mobile phone or the like registered in the center server and connected via the communication network is connected to the receiving terminal. It is preferable that bulletin data, a call button signal, and the like are delivered from the center server by e-mail.

  In the emergency call method according to the present invention, the bulletin data from the center server is transmitted in the connectionless protocol format, and the response signal from each receiving terminal that accepts the reception of the bulletin data is transmitted in the connectionless protocol format or similar to this. Send in the form of In the emergency notification method of the present invention, even if there are thousands to tens of thousands of breaking news distribution destinations, one emergency earthquake notification can be completed in just a few seconds, and even if there is a swarm, the subsequent earthquake notification is delayed. Does not occur. In the emergency notification method of the present invention, when the breaking news data is transmitted in the connectionless type protocol format, the breaking data has a data length including the header of 1 in order to avoid the possibility that the breaking data is changed or lost. The program is designed to fit within a packet, for example, 100 bytes.

  In the emergency notification method according to the present invention, the reception authentication code included in the DDNS response signal or the life / death confirmation signal received by the receiving terminal at regular time intervals is stored, and when the early warning data of the emergency earthquake notification is transmitted. The authentication confirmation data included in the preliminary data is compared with the reception authentication code. As a result, when the authentication confirmation data matches the reception authentication code, the receiving terminal receives the preliminary data, and when the two do not match, the receiving terminal rejects reception of the preliminary data. As a result, even if a hacker or the like sends fake breaking news data to the communication line network, each receiving terminal refuses to receive the fake breaking news data, so a false earthquake warning may be issued. It is possible to prevent social disruption due to false information.

  The emergency notification method according to the present invention constantly confirms that the emergency notification system is in a distributable state by transmitting a life / death confirmation signal transmitted from the center server at regular intervals. For example, in a usage mode in which there is no actual occurrence of a moderate or greater earthquake such as seismic intensity 3 once a year, individual distribution destinations receive a life and death confirmation signal on a regular basis, Prevent the emergency call system from operating when an earthquake actually occurs.

  In the emergency call method according to the present invention, the receiving terminal updates the port number at regular time intervals, resets the private address and port number acquired by the UPnP operation as needed, and resets the private address and port number. This prevents the receiving terminal from becoming inoperable in a constant connection. In addition, the center server periodically notifies the receiving terminal of the update of the global IP address by returning a DDNS response signal. Therefore, each receiving terminal can reliably receive an emergency call even if its global IP address is not a relatively expensive fixed address but a relatively inexpensive static address.

  The emergency call system according to the present invention comprises a center server as a set of at least a receiving server and a calculation distribution server, and further includes a DDNS server, and the calculation distribution server is capable of high performance and high speed calculation. In this emergency call system, it is possible to use a low-priced one by reducing the burden on the receiving terminal without performing load distribution without calculating at each receiving terminal by performing high-speed calculation in the calculation distribution server. As a whole, it becomes cheaper. This emergency call system does not need to replace each receiving terminal or change its calculation program when the system calculation formula is improved, and the improvement is completed only by the center server. it can.

It is explanatory drawing which shows an example of the system configuration | structure in the emergency call system which concerns on this invention. It is a table which shows the user information database of a center server. It is a figure which illustrates the data content of the emergency earthquake information transmitted from an earthquake information calculating part. It is a data frame figure which shows the data structure of the bulletin data delivered from a center server to each receiving terminal. It is a map which shows the epicenter position regarding the emergency earthquake information of FIG. It is explanatory drawing which shows an example of the delivery order of a center server. It is a figure which shows the example of a screen display of the earthquake information in a receiving terminal. It is a figure which shows an example of the earthquake warning in a receiving terminal. It is explanatory drawing which shows roughly the report sequence between a center server and a receiving terminal. 5 is a flowchart schematically showing UPnP operation in a receiving terminal. It is a flowchart which shows roughly the processing operation of a center server.

  The emergency call system according to the present invention is a central disaster prevention radio broadcasted by the Cabinet Office from the official residence (Countermeasures Headquarters) regarding information transmission for the protection of the public in armed attacks in addition to the earthquake early warning from the Meteorological Agency described below. Applicable to. Moreover, it is applicable also to the fire-fighting disaster prevention radio | wireless which a fire department distributes about a comparatively small system.

  DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described in detail with reference to the drawings. An emergency call system according to the present invention, as an example, connects a router 7 to an individual distribution destination in order to connect the center server 1 to an individual distribution destination 5 via a communication line network 3. At least one receiving terminal 8 is LAN-connected to the router. In FIG. 1, the communication line network 3 is normally an always-connected Internet line, and a dedicated communication line network such as a virtual closed network, an optical communication network, or a digital communication network may be used. The communication line network 3 is specifically an optical access network, an IP-VPN (Vertual Private Network), or the like, and is the same or different line network as the dedicated line 18.

  In this emergency call system, the earthquake information calculation unit 2 exists in the Japan Meteorological Agency and the Meteorological Operations Support Center, and detects the occurrence of an earthquake, estimates the magnitude / position / occurrence time of the earthquake, and distributes the results as “emergency earthquake early warning” as needed. . This earthquake early warning is sent to the data center of the advanced user via the dedicated line 18. In this data center, a center server 1 that can withstand natural disasters such as power outages and earthquakes is installed, and this server is managed 24 hours a day. It is possible.

  In FIG. 1, the center server 1 basically comprises a receiving server 12, a calculation distribution server 14 and a DDNS server 16, and if the basic configuration matches, the calculation distribution server 14 is separated into a calculation server and a distribution server. Alternatively, a management server or a dedicated data server may be installed separately, and the DDNS server 16 may be arranged outside the basic configuration. Further, a server for the user information database 17 (FIG. 2) may be installed in the center server 1, or the user information database 17 may be constructed by being distributed to the server 12 or 14 or both.

  This emergency call system is a center server calculation method using a high-speed processing calculation / delivery server 14, and the receiving terminal 8 normally does not perform forecast calculation. When the forecast calculation is performed at the receiving terminal 8, load distribution is possible. However, when the calculation formula of the system is improved, it is necessary to replace each receiving terminal or change the calculation program of each receiving terminal. There is a possibility that the distribution of the emergency earthquake information is delayed due to the work of distributing the change information to each receiving terminal. On the other hand, if the calculation method in the center server 1 is improved, if the calculation formula of the high-speed calculation server is improved when the calculation formula is improved, the improvement to all the receiving terminals is completed. Can be implemented quickly. Further, since the distribution is limited to only the change data required by the receiving terminal 8, the delay due to the change data distribution can be extremely reduced.

  In this emergency call system, the receiving terminal 8 includes a CPU, a memory, and the like, but does not perform a forecast calculation, so is a relatively low-speed process, and one packet is 100 bytes. The router 7 is usually a commercially available product, and a model may be selected according to the scale of the individual distribution destination 5, and a commercially available personal computer may be used as the receiving terminal 8. The receiving terminal 8 is dynamically assigned an IP address (private address) by the router 7, and this IP address is dynamically registered in the DDNS server 16 together with its device ID and port number. The DDNS server 16 updates the global IP address dynamically assigned in the always-connected communication network 3 by registering it every time it is changed.

  In the emergency call method according to the present invention, the DDNS data and response signal from each receiving terminal 8, the DDNS response signal from the center server 1, the alive confirmation signal and the breaking news data (for example, earthquake data) are all connectionless protocols. The format is transmitted, and this format is usually a UDP / IP format. The UDP method does not establish a virtual communication line between the transmission side and the reception side as compared with the connection-type protocol format such as the TCP method, so the transfer speed is high, and thousands of individual distribution destinations 5 are required. It is possible to broadcast simultaneously within a few seconds, even within tens of thousands of cases within a second. On the other hand, the UDP method is less reliable than the TCP method, and when a plurality of packets are sent, the order is changed or a part of the packets is easily lost. In the emergency notification method of the present invention, in order to avoid the disadvantages of the UDP method, the center server 1 sends back a response signal to the center terminal 1 in response to the transmission of the breaking news data and the life / death confirmation signal. The data reception of the machine 8 is confirmed, and all transmission / reception data is stored within one packet.

  Referring to FIG. 4 for the data format of the UDP system, the data frame includes a header and a data area, and the header includes an Ethernet (registered trademark) header section 64, an IP header section 66, and a UDP header section 68. The same applies to UDP data. The portion excluding the Ethernet header portion 64 is read into the application, and the center server 1 recognizes the global IP address of the source receiving terminal 8 from the source IP address and destination IP address in the IP header portion 66, and UDP The port number of the receiving terminal 8 can be recognized from the source port number and the destination port number in the header portion 68. In the data area, the data head 39 is 1 byte, which determines the type of transmission / reception data. In general, the response signal from the receiving terminal 8 for the preliminary data or the life / death confirmation signal is in the UDP / IP format having only the data head 39, thereby shortening the response time.

  In the emergency call method of the present invention, if the emergency information is earthquake information, the breaking data is earthquake data, so that the earthquake data can be accurately distributed without delay from the center server 1 to the receiving terminal 8 at regular intervals, that is, at regular intervals. An emergency call system can be distributed by transmitting a life / death confirmation signal (for example, 1 minute, 10 minutes or several times a day) and recognizing that the reception terminal 8 has received this life / death confirmation signal. Always confirm that it is in a state. The transmission of the alive confirmation signal is set so that the transmission time is shifted so that there is no time lag in the distribution of the earthquake data from the center server 1 when it overlaps with the reset of the receiving terminal 8 or the like. .

  The center server 1 always establishes a distributable state by retransmitting the same alive confirmation signal several times for the receiving terminal 8 that has not returned a response signal within a waiting time (for example, 100 msec), or the same earthquake Achieve reliable and continuous reporting of earthquake information by resending data. However, if the center server 1 does not send back a response signal even if the same alive confirmation signal is transmitted a plurality of times, the center server 1 stores the unsuccessful distribution and manages the terminal, for example. The user is warned by e-mail or a warning is displayed on the receiving terminal 8 or an alarm is notified, and then the state is returned to the distributable state (see FIG. 11). On the other hand, if the receiving terminal 8 does not send back a response signal even if the earthquake data, which is the same earthquake early warning, is transmitted a plurality of times, for example, the distribution stop state is made after recording the distribution stop of the center server 1 or the like. Return (see FIG. 11). If the response signal can be received after the return, it is considered that the communication has been restored, and the record of the delivery failure is cleared. When the receiving terminal 8 fails to receive the alive confirmation signal or the DDNS response signal from the center server 1 within a predetermined time, the receiving terminal 8 may perform warning display or alarm notification by itself to prompt the terminal administrator to check.

  Each life and death confirmation signal is added with an earthquake authentication code of several bytes in the data area, and the earthquake authentication code is created by adding a random number in order to ensure confidentiality. When receiving the life / death confirmation signal, each receiving terminal 8 returns a response signal to the center server 1 and stores the earthquake authentication code in the life / death confirmation signal. This earthquake authentication code is normally stored in the receiving terminal 8 for the past 2 to 5 generations, and is deleted from the memory when the generations after that are reached. On the other hand, when the center server 1 receives the UDP response signal, the center server 1 recognizes the global IP address and port number of the receiving terminal 8 from the header, and the user information database 17 registered in the server (FIG. 2). To identify the device ID of the receiving terminal 8.

  This earthquake authentication code may be added to the DDNS response signal from the center server 1 for the transmission of DDNS data from the receiving terminal 8 (see Example 2). In this case, the earthquake authentication code is not added to the life / death confirmation signal.

  Transmission of DDNS data from the receiving terminal 8 is started upon activation, which is transmitted on a regular basis (for example, 1 minute, 10 minutes, several times a day), and is 1 minute interval for business use. The transmission of the DDNS response signal accompanying this is preferable because the IP address of the receiving terminal 8 is updated more quickly with the DDNS response signal as the transmission interval is shorter. The DDNS data is data to which individual terminal management numbers (for example, device IDs) are added, and the center server 1 that has received this DDNS data receives the DDNS server 16 from the source global in the IP header portion of the head in the data. The IP address and device ID are registered in association with each other.

  The earthquake data 22 (see FIG. 4) of the earthquake early warning distributed from the center server 1 is a UDP method, so the transfer speed is fast, and in order to prevent data error and loss during transmission, the total is about 80 bytes and 100 bytes. The following is included, even if the header and data area are included. In the data frame of the earthquake data 22, as illustrated in FIG. 4, the data head 39, the earthquake ID 40, the occurrence time 42, the predicted seismic intensity scale 44, etc. are entered in the data area, and at least one authentication confirmation code 48- 52 is added. In FIG. 4, the three authentication confirmation codes 48 to 52 correspond to, for example, the earthquake authentication code added to the latest life / death confirmation signal or the DDNS response signal, and the earthquake authentication codes of the past several generations and life / death confirmation signals. To do. The plurality of authentication confirmation data added to the earthquake data 22 is compared with the earthquake authentication codes of the past 2 to 5 generations stored in the receiving terminal 8, and if they match at least one of the earthquake authentication codes, the earthquake The receiving terminal recognizes that the report is correct and receives the earthquake data 22.

  In addition, the center server 1 distributes a timeless signal of a connectionless protocol UDP method to each receiving terminal 8 at a fixed time (for example, every day at noon) and receives the time signal data of the time signal as desired. Thus, the receiving terminal 8 can adjust the time once a day, and allows the user of the receiving terminal 8 to recognize that the line state is normal. Each receiving terminal 8 may return a response signal to the time signal in the UDP method, as desired. This time signal can be replaced by a life / death confirmation signal if time signal data is added to any one of the life / death confirmation signals.

  In this emergency call method, a relatively inexpensive dynamic address is used as a global IP address for transmission / reception between the center server 1 and the receiving terminal 8, and a relatively inexpensive dynamic address is used. A private IP address is assigned. The receiving terminal 8 normally operates according to the UPnP procedure, and enters a communication state with the router when a predetermined time elapses with the set private IP address and port number. If this communication is successful, the router 7 is requested to open the port again, and the communication port number is reset. The reason why the receiving terminal 8 repeats the port assignment request is to cope with a phenomenon in which the port number that should have been registered in the router 7 is lost or closed at the time of constant connection.

  If the communication with the router 7 is unsuccessful, the receiving terminal 8 resets the current setting, and at the same time, repeats the initial setting for the router 7 and resets the private address and port number. Receiving terminal 8 repeats resetting of settings by router 7 when the router 7 is always connected, the router 7 restarts without permission, the private IP address changes, or some routers reject continuous port assignment requests This is to cope with the phenomenon.

  The receiving terminal 8 may be set to be reset immediately after one unsuccessful communication with the router 7 or to be reset after repeating the communication with the router 7 several times. The receiving terminal 8 may be reset every certain time (for example, once per hour, once a day), and the router 7 may reset the private address and communication port number on a regular basis. At this time, the UPnP operation mode of the receiving terminal 8 can be changed according to the router 7, and in some of the routers 7 having a slow UPnP operation, transmission of a life / death confirmation signal transmitted from the center server 1 on a regular basis. It is preferable to execute by shifting the time zone so as not to overlap with the time. The communication port number registered in the router 7 may interfere with the port numbers of other network devices, and the communication port number can be changed to avoid such a situation.

  Next, the present invention will be described based on examples, but the present invention is not limited to the examples. FIG. 1 schematically shows an example of an emergency call system constituted by a center server 1 for high-speed processing. The emergency call system includes an earthquake information calculation unit 2 that collects and calculates data from an earthquake observation network in the Japan Meteorological Agency and the Meteorological Operations Support Center, and a center server that continuously receives emergency earthquake information 20 (FIG. 3) from the calculation unit. 1, a router 7 of an individual distribution destination 5 connected via an Internet line which is a communication line network 3, and at least one receiving terminal 8 connected to the router 7 by a LAN at the distribution destination. In an apartment house, a router 7 may be installed as a shared facility, and a receiving terminal 8 may be attached to each house and connected by LAN.

  The earthquake information calculation unit 2 and the center server 1 installed in the Japan Meteorological Agency or the disaster prevention / reduction disaster information center usually communicate with each other via the Internet line of the dedicated network 18. The information calculation unit 2 determines an epicenter based on information from an earthquake observation network constituted by a multi-function seismometer or the like. Since this multifunction seismometer is usually installed on the ground surface, its installation is relatively easy and a high-density seismic observation network is constructed. Data from this observation network is transmitted to the receiving / delivering server 10 of the earthquake information calculation unit 2, and an earthquake ID and an occurrence time are assigned to the receiving / distributing server, and the location of the epicenter, the depth of the epicenter, the magnitude of the earthquake are calculated. The emergency earthquake information 20 (FIG. 3) is created.

  As shown in FIG. 1, the center server 1 is composed of a receiving server 12, a computation distribution server 14, and a DDNS server 16, and a user information database 17 (FIG. 2) is constructed by being distributed to the server 12 or 14 or both. To do. The servers 12, 14, and 16 are connected to each other and transmit / receive data to / from each other. The DDNS server 16 records the global IP addresses of all receiving terminals 8 using the entire system as a service area, associates the device ID and port number of each receiving terminal with the global IP address, and calculates and distributes the computation distribution server 14. Contact the global IP address update.

  The receiving server 12 in the center server 1 continuously receives the emergency earthquake information 20 from the earthquake information calculating unit by connecting to the receiving / delivering server 10 of the earthquake information calculating unit 2 through the Internet line of the dedicated line network 18. At the same time, the update IP information from the DDNS server 16 is received. In the receiving server 12, in order to ensure the secrecy of the earthquake data 22 (FIG. 4) delivered to each receiving terminal 8, a 2-byte earthquake authentication code is created by adding a random number, and this 2-byte code is generated by the UDP. It is added to the life / death confirmation signal of the system and delivered to each receiving terminal 8 on a regular basis. In addition, the receiving server 12 distributes a connectionless protocol UDP time signal to each receiving terminal 8 at a fixed time (for example, every day at noon).

  The computation distribution server 14 in the center server 1 computes and analyzes the emergency earthquake information 20 received by the reception server 12, and obtains the obtained earthquake data 22 (FIG. 4) via the communication network 3 by the UDP method for the individual distribution destination 5. The router 7 is further distributed to each receiving terminal 8. For example, the calculation distribution server 14 receives the emergency earthquake information 20 and calculates the distance R from the epicenter position 24 (see FIG. 5) included in the emergency earthquake information and the positions of the distribution destinations 5a to 5e (see FIG. 6). Based on this distance R and the earthquake magnitude 26, the provisional seismic intensity of each of the distribution destinations 5a to 5e is calculated. In FIG. 6, the seismic data 22 is distributed to the neighboring distribution destinations 5b and 5c where the provisional seismic intensity is equal to or larger than a predetermined scale in the order of seismic intensity or the earliest arrival of the S wave. The distribution of the earthquake data 22 to the distribution destinations 5a, 5d, and 5e is stopped.

  In the calculation distribution server 14, the predicted seismic intensity 28 (see FIG. 7) of the specific distribution destination 5 is calculated based on the seismic intensity 26 included in the emergency earthquake information 20 and the seismic depth 30 and the epicenter position 24 and the distribution destination 5. Calculation and analysis taking into account the distance attenuation due to the propagation distance to the position. At this time, it is only necessary to consider the ground amplification factor specific to the area between the propagation distances. The ground amplification factor is a value that represents the degree to which the acceleration of earthquake vibration is increased or decreased by the state of the ground near the ground surface. is there. When considering the ground amplification factor, it is stored in advance in a database (not shown) as a value unique to each region in the country. Furthermore, from the propagation distance and the earthquake magnitude 26, the predicted seismic intensity 28 of each distribution destination 5 is calculated, and the grace time 32 (see FIG. 7) until the S wave of the earthquake reaches each distribution destination 5 is calculated.

  In the individual distribution destination 5, a router 7 and a plurality of receiving terminals 8 are installed. The receiving terminal 8 is LAN-connected to the router 7 at the individual distribution destination 5, and receives the calculated and analyzed earthquake data 22 by the UDP method via the router. When the receiving terminal 8 includes a liquid crystal display unit, when the earthquake data 22 is received, an earthquake information warning screen 34 as shown in FIG. 7 is displayed. The receiving terminal 8 includes a voice synthesis board (not shown), and the voice synthesis board is wired to a speaker output terminal via a voice output transformer. When receiving the earthquake data 22, the receiving terminal 8 outputs an operation signal from its output terminal, thereby switching the intercom integrated panel to the simultaneous broadcasting state and connecting it to each residential interphone in each dwelling unit. It is also possible to send an emergency earthquake warning voice guidance signal to the aircraft.

  When receiving the earthquake data 22, the receiving terminal 8 utters an earthquake alarm 36 as shown in FIG. 8 according to the grace time. For example, if the grace time is 30 seconds or more, it repeats three times “Earthquake occurred” next to the electronic sound. When the grace time reaches 10 to 30 seconds, it repeats three times, “Earthquake will come soon” after the electronic sound. When the grace time is less than 10 seconds, it repeats until a shaking occurs saying “An earthquake will come soon” following the electronic sound. This alarm can be handled in multiple languages such as English, Chinese and Korean in addition to Japanese.

  If desired, the call terminal 38 can be connected to the receiving terminal 8 by a special radio as shown in FIG. 1. Although not shown, a fire alarm, a door open sensor, etc. A control signal such as elevator control may be output from the center server 1 by wireless connection or connection to an elevator stop sensor. When the receiving terminal 8 receives a data transmission command from the call button 38, it transmits a transmission request signal to the center server 1. Upon receiving the transmission request signal, the center server 1 transmits a registered electronic message to a mail address of a mobile phone registered in advance (see FIG. 9).

  Next, the operation of the emergency notification system will be described with reference to FIG. 9, and FIG. 9 schematically shows a notification sequence of the center server 1, the router 7, and the receiving terminal 8. The center server 1 performs initial settings at the time of activation in S10. When the receiving terminal 8 is LAN-connected to the router 7 and the power is turned on, network parameters are automatically set by DHCP (Dynamic Host Configuration Protocol) in S11. Normally, the router 7 connects the receiving terminal 8 to the receiving terminal 8 in S12. An IP address (private address) and a port number are dynamically assigned, and the receiving terminal 8 acquires an IP address in S13.

  In S14 to S16, the receiving terminal 8 operates in accordance with the UPnP procedure, and repeats the port assignment request to the router 7. FIG. 10 schematically shows the UPnP operation in the receiving terminal 8. In FIG. 10, after obtaining the private address in S13, the receiving terminal 8 requests the router 7 to open the port in S100, and sets the communication port number in S101. This port setting is maintained for a certain time (for example, 1 minute) in S14, and when the certain time elapses, a communication state with the router 7 is entered in S16. If this communication is successful, the router 7 is requested to open the port again, the communication port number is reset in S101, and thereafter this operation is repeated at regular intervals.

  If the receiving terminal 8 cannot communicate with the router 7 in S16, the setting by the router 7 is reset in S102, the process returns to S11, the initial setting is repeated, and the private address and port number are reset. In FIG. 10, although the router reset is immediately performed due to unsuccessful communication with the router 7 in S16, it may be set to be reset after repeating the communication with the router 7 several times, or the receiving terminal 8 You may set so that it may reset every fixed time (for example, once a day).

  The UPnP operation mode of the receiving terminal 8 can be changed according to the router 7. Some routers 7 have a slow UPnP operation, and a time lag may occur between the reset and the reconfiguration. In order to avoid such a situation, a mode change of the UPnP operation is provided. That is, it takes several seconds during this resetting request operation, but there is a period during which the life / death confirmation signal from the center server 1 cannot be received, so that it does not overlap with the transmission time of the life / death confirmation signal transmitted from the center server on a regular basis. It is preferable to execute by shifting the time zone.

  When the receiving terminal 8 is activated, the DDNS data with the terminal management number (for example, device ID) in the UDP / IP format is transmitted from the receiving terminal to the center server 1 via the router 7 in S21. In step S22, the center server 1 returns a UDP / IP format DDNS response signal to the receiving terminal 8. This DDNS response signal is a data frame whose data area is only the data head.

  Upon reception of the DDNS data, the DDNS server 16 in the center server 1 registers the global IP address, device ID, and port number of each receiving terminal 8 in association with each other from the received UDP IP head unit and device ID. This DDNS data is transmitted at regular intervals (for example, 10 minutes) even after each receiving terminal 8 is activated, and the dynamic IP address and port number are updated by the DDNS server 16.

  As shown in FIG. 9, the center server 1 delivers a life / death confirmation signal to each receiving terminal 8 at once in 10 minutes. This life and death confirmation signal is in the UDP / IP format, and a 2-byte earthquake authentication code is added. On the other hand, when receiving the life / death confirmation signal in the UDP / IP format in S32, each receiving terminal 8 returns a response signal in the UDP / IP format to the center server 1 in S33, and the center server 1 sends this response signal to S34. Receive at. This response signal is a data frame whose data area is only the data head.

  The center server 1 receives the response signal from each receiving terminal 8 in S34 after simultaneous delivery of the life / death confirmation signal in S31, and receives the life / death confirmation signal from the IP header portion of the response signal. Confirm. The processing operation for each receiving terminal 8 in the center server 1 is shown in a flowchart in FIG. In FIG. 11, a redistributable state is always established for each receiving terminal 8 by retransmitting the same alive confirmation signal in S35 for the receiving terminal 8 that has not returned a response signal. This seismic standby state, which is a deliverable state, continues for 10 minutes in S37, and repeats delivering the life / death confirmation signal again after 10 minutes have elapsed.

  In the receiving terminal 8, if the response signal is not returned even if the same alive confirmation signal is transmitted a predetermined number of times (for example, 3 times), the disconnection is notified to the center server 1 or the like in S36, and then the return is made. The line 60 is returned to the ready state for distribution. Notification of distribution interruption is sent from the center server 1 to the user of the receiving terminal 8, mailed to the user of the receiving terminal 8, or the display LED provided on the receiving terminal is turned on or warned. A user may be notified with a sound. If the receiving terminal 8 remains incapable of receiving even after such measures are taken several times, distribution to the receiving terminal is stopped. In the receiving terminal 8, if the life / death confirmation signal or the DDNS response signal from the center server 1 cannot be received within a predetermined time, it is possible to prompt the terminal administrator to perform an inspection by performing a warning display or an alarm notification. is there.

  The center server 1 receives emergency earthquake information 20 from the earthquake information calculation unit 2 when an earthquake occurs, and creates earthquake data 22 in the UDP / IP format as shown in FIG. The data frame of the earthquake data 22 is composed of, for example, an Ethernet header portion 64, an IP header portion 66, and a UDP header portion 68. The data area includes a data head 39, an earthquake ID 40, an occurrence time 42, and the receiving terminal 8. A predicted seismic intensity scale 44 corresponding to the position of the delivery destination 5 and a time 46 until the earthquake arrival are entered, and three authentication confirmation codes 48, 50, 52 of 2 bytes are further added. The earthquake data 22 is 100 bytes or less in total even if a 40-byte header is added, and the data frame is contained in one packet. The authentication confirmation codes 48, 50, and 52 correspond to the earthquake authentication code added to the latest life and death confirmation signal, and the earthquake authentication codes added to the past two generations and the life and death confirmation signal.

  When the center server 1 distributes the earthquake data to the receiving terminals 8 in S51, the authentication confirmation data 48, 50, 52 included in the earthquake data 22 is stored in the receiving terminal 8 in the receiving terminal 8. Compare with the 3rd generation earthquake certification code. As a result, if the authentication confirmation data 48, 50, 52 matches at least one of the earthquake authentication codes, it is determined that the earthquake notification signal is correct, and the receiving terminal 8 receives the earthquake data 22 in S52. In the receiving terminal 8, if the authentication confirmation data 48, 50, 52 does not match any of the past three generations of earthquake authentication codes, it is determined as false earthquake data and the reception is rejected.

  If the center server 1 distributes the earthquake data to the receiving terminals 8 all at once, and each receiving terminal 8 recognizes that this is the genuine earthquake data 22 and receives it in S52, the UDP / An IP format response signal is returned, and the center server 1 receives this response signal in S54. This response signal is a data frame whose data area is only the data head. Since the response signal is simple with only the data head, the response time of the entire emergency call system is shortened.

  The center server 1 receives the response signal from each receiving terminal 8 after simultaneous distribution of the earthquake data 22, and determines the receiving terminal 8 that has received this earthquake data from the IP header portion of the response signal. In FIG. 11, the same earthquake data 22 is retransmitted in S55 for the receiving terminal 8 that has not returned this response signal, so that it is reliably transmitted to each receiving terminal 8. If the response signal is not returned for the receiving terminal 8 even if the same seismic data 22 is transmitted a predetermined number of times (for example, 3 times), the transmission of the seismic data 22 is stopped, and the center server 1 or the like is sent to S56. After recording the stop of distribution, it returns to the state where distribution is possible through the return line 62.

  Further, in S40, the center server 1 simultaneously distributes the time signal signal in the UDP / IP format to each receiving terminal 8 at noon every day, and the receiving terminal 8 receives the time signal data of this time signal in S42. Each receiving terminal 8 returns a response signal for the time signal in UDP / IP format in S43 as desired, and the center server 1 receives this time signal in S44 from the IP header portion of the response signal. The receiving terminal 8 is determined.

  When the call button 38 is pressed and the receiving terminal 8 receives a data transmission command when the call button 38 shown in FIG. 1 is connected by special radio, the receiving terminal 8 receives the data transmission command to the center server 1 in S61. A transmission request signal is transmitted by the UDP method. Next, in S62, when the center server 1 receives this transmission request signal, in S63, the center server 1 transmits a registered electronic message to the mail address of the mobile phone registered in advance. This mail delivery is appropriately selected from the registered emergency contact texts. If this is emergency earthquake information, an earthquake information warning screen 34 as shown in FIG. 7 is displayed on the mobile phone.

  In the modified example of the present invention, the description omitted is substantially the same as that of the first embodiment. Each receiving terminal 8 transmits DDNS data with a terminal management number (for example, a device ID) in the UDP / IP format to the center server 1 via the router 7 at the time of activation, and the center server 1 responds to this transmission in S22. A UDP / IP format DDNS response signal is returned to the receiving terminal 8. This DDNS data is frequently transmitted regularly (for example, for 1 minute or 10 minutes) after the activation of each receiving terminal 8, and the center server 1 responds to the transmission in the UDP / IP format to the receiving terminal 8. A DDNS response signal is returned. This DDNS response signal adds a 2-byte earthquake authentication code in the data area.

  Upon reception of the DDNS data, the DDNS server 16 in the center server 1 registers the global IP address, device ID, and port number of each receiving terminal 8 in association with each other from the received UDP IP head unit and device ID. On the other hand, the receiving terminal 8 can store the dynamic IP address when it is updated by receiving the DDNS response signal. Since each receiving terminal 8 frequently receives DDNS data, when the dynamic IP address is updated by the DDNS server 16, the IP address can be updated without delay.

  Further, the center server 1 distributes the life / death confirmation signal to each receiving terminal 8 at a fixed time (for example, several times a day). This life / death confirmation signal is in the UDP / IP format, and is basically a data frame whose data area is only the data head. On the other hand, each receiving terminal 8 returns a response signal in the UDP / IP format to the center server 1 upon receipt of this alive confirmation signal. This response signal is a data frame whose data area is only the data head. The center server 1 receives the response signal from each receiving terminal 8 after simultaneous delivery of the alive confirmation signal, and determines the receiving terminal 8 that has received the alive confirmation signal from the IP header portion of the response signal.

  When the center server 1 distributes the earthquake data to the receiving terminals 8 at the same time, the receiving terminal 8 stores the authentication confirmation data 48, 50, 52 (FIG. 4) included in the earthquake data 22 in the receiving terminal. Compare with the past three generations of earthquake certification codes. These earthquake authentication codes are added to the DDNS response signal returned from the center server 1. As a result, if the authentication confirmation data 48, 50, 52 matches at least one of the earthquake authentication codes, it is determined that the earthquake notification signal is correct, and the receiving terminal 8 receives the earthquake data 22. In the receiving terminal 8, if the authentication confirmation data 48, 50, 52 does not match any of the past three generations of earthquake authentication codes, it is determined as false earthquake data and the reception is rejected.

DESCRIPTION OF SYMBOLS 1 Center server 2 Earthquake information calculating part 3 Dedicated communication network 5 Individual delivery destination 7 Router 8 Receiving terminal 12 Reception server 14 Computation delivery server 16 DDNS server 17 User information database 20 Emergency earthquake information 22 Earthquake data 24 Earthquake source position 34 Warning screen 36 Earthquake warning

Claims (12)

  An emergency notification method that distributes emergency information in real time from a center server to multiple receiving terminals via a communication network, and a connectionless protocol-style alive confirmation signal is sent to the receiving terminals from the center server on a regular basis. To the center server, the receiving terminal returns the response signal with the terminal management number to the center server to determine the receiving terminal to which the center server has returned the response signal from the IP head unit. For the receiving terminal that did not send back a response signal, the same alive confirmation signal is re-sent to establish the delivery status at all times. In the event of an emergency, the center server receives an emergency bulletin, and a connectionless protocol format Is distributed to each receiving terminal, and the receiving terminal connects to the center server for this breaking data. By sending back a response signal in the formless protocol format, the center server determines from the IP head part the receiving terminal that has returned the response signal, and retransmits the same preliminary data for the receiving terminal that has not returned the response signal. This is an emergency notification method that ensures that emergency information is reported.   An emergency notification method for delivering emergency information in real time from a center server to a plurality of receiving terminals via a communication line network, wherein the DNS data with terminal management number is in a connectionless protocol format from each receiving terminal to the center server. The center server determines each receiving terminal from the IP head part of the data for the transmission of this DDNS data, and the center server returns a DDNS response signal to each receiving terminal. In the event of an emergency, the center server receives emergency bulletins and distributes bulletin data in connectionless protocol format to each receiving terminal, and the receiving terminal sends connection data to the center server in response to this bulletin data By sending back the response signal, the center server returns the response signal to the receiving terminal. Determined from the IP head, emergency call method for reporting emergency information reliably to retransmit the same bulletin data for the receiving terminal that did not return a response signal.   A DDNS response signal or a life / death confirmation signal with a reception authentication code is transmitted from the center server to each receiving terminal, and a plurality of reception authentication codes are stored in the receiving terminal. When breaking data containing a data length including authentication confirmation data in one packet is distributed to each receiving terminal and this authentication confirmation data matches the reception authentication code stored in the receiving terminal, the receiving terminal receives this breaking data. The emergency call method according to claim 1, wherein the emergency notification method is received.   If the authentication confirmation data included in the bulletin data distributed in the event of an emergency situation matches any of the past 2-5 generations of reception authentication codes stored in the receiving terminal, the emergency notification signal is recognized as correct. 4. The emergency call method according to claim 3, wherein each receiving terminal receives the breaking data.   If the center server does not return a response signal from the receiving terminal even if it transmits the same alive confirmation signal multiple times, it counts the number of distribution interruptions to the receiving terminal and returns to the distribution state. If the receiving terminal does not send back a response signal even if the early warning data, which is the same emergency early warning, is transmitted a plurality of times from the center server, the center server stops sending the early warning data and returns to the standby state. The emergency call method according to claim 1 or 2.   A time signal in connectionless protocol format is distributed from the center server to each receiving terminal on a regular basis, and the receiving terminal returns a response signal to the center server in response to this time signal, and each receiving terminal receives the time signal of the time signal. The emergency call method according to claim 1 or 2, wherein time adjustment is possible by receiving data.   The emergency notification method according to claim 1 or 2, wherein the emergency information is emergency earthquake information, and the emergency earthquake information is created based on an emergency earthquake bulletin distributed as needed from the Japan Meteorological Agency and the Meteorological Operations Support Center.   The receiving terminal requests port assignment to the router at regular intervals, the port number is updated, and when port assignment is rejected, it is acquired at the same time as the rejection or by UPnP operation at regular intervals. The emergency call method according to claim 1 or 2, wherein the emergency call method operates to reset the private address and port number, and to request resetting of the private address and port number.   A center server for transmitting emergency information in real time via a communication line network; a plurality of routers connected to the center server via a communication line network; and at least one receiving terminal connected to the router; The center server creates earthquake authentication data at regular intervals and receives emergency early warnings, and performs high-speed computations such as seismic intensity and distribution order of early earthquakes at the location of each receiving terminal. In the event of an emergency situation, the calculation and distribution server creates breaking data in which the data length including the header is stored in one packet, and sends this breaking data to each receiving terminal in a connectionless protocol format. The receiver terminal sends a response signal in the connectionless protocol format to the center server in response to the preliminary data. The Rukoto center emergency call system server to determine the receiver terminal returns a response signal from the IP head.   The center server includes a DDNS server, which records the global IP address of all receiving terminals, associates the device ID of each receiving terminal with the global IP address and port number, and distributes the computation from the DDNS server. The emergency call system according to claim 9, wherein a global IP address update is notified to a server.     A call button or the like is wirelessly connected to the receiving terminal, and when the receiving terminal receives a signal from the call button or the like, the center server is connected to a mobile phone or the like registered in the center server and connected via a communication line network. 10. The emergency call system according to claim 9, wherein the bulletin data, the call button signal, and the like are delivered by mail.   The emergency notification system according to claim 9, wherein the center server selects a distribution order of the breaking news data to the receiving terminal.

Images