“Saving Precious Seconds”—A Novel Approach to Implementing a Low-Cost Earthquake Early Warning System with Node-Level Detection and Alert Generation

Abstract

This paper presents findings from ongoing research that explores the ability to use Micro-Electromechanical Systems (MEMS)-based technologies and various digital communication protocols for earthquake early warning (EEW). The paper proposes a step-by-step guide to developing a unique EEW network architecture driven by a Software-Defined Wide Area Network (SD-WAN)-based hole-punching technology consisting of MEMS-based, low-cost accelerometers hosted by the general public. In contrast with most centralised cloud-based approaches, a node-level decentralised data-processing is used to generate warnings with the support of a modified Propagation of Local Undamped Motion (PLUM)-based EEW algorithm. With several hypothetical earthquake scenarios, experiments were conducted to evaluate the system latencies of the proposed decentralised EEW architecture and its performance was compared with traditional centralised EEW architecture. The results from sixty simulations show that the SD-WAN-based hole-punching architecture supported by the Transmission Control Protocol (TCP) creates the optimum alerting conditions. Furthermore, the results provide clear evidence to show that the decentralised EEW system architecture can outperform the centralised EEW architecture and can save valuable seconds when generating EEW, leading to a longer warning time for the end-user. This paper contributes to the EEW literature by proposing a novel EEW network architecture.

1. Introduction

With increasing population and urbanisation across the globe, large earthquakes have become a significant threat to human life and infrastructure, especially for places closer to active earthquake faults [1]. In this context, interest in issuing earthquake early warnings (EEWs) is increasing globally, and research has found significant benefits of having EEW systems to warn the public [2]. EEW can be a beneficial tool for warning people when an earthquake occurs. EEW can warn people in areas where the anticipated ground-shaking due to an earthquake could cause harm or destruction [3]. Depending on the size and depth of the earthquake and the number and type of sensors used to build the EEW system, the warning window can range from a few seconds to tens of seconds. Research revealed that even a 20–30 s warning lead-time could allow people to take simple protective actions such as drop–cover–hold and mentally prepare themselves for an impending earthquake [4,5,6]. Even a couple of seconds could be extremely useful, as they can provide enough time for automated systems to initiate precautionary emergency measures, such as stopping trains to minimise potential derailment, the appropriate shutting-off of gas distribution valves to reduce fire risk, and the orderly switching-off of large, heavy machinery to minimise potential losses [1].

Ongoing technological innovations in earthquake-monitoring tools, telecommunication, earthquake-detection algorithms, and processing capabilities have created new opportunities to develop EEW systems and provide opportunities for further enhancements [7]. At present, EEW systems are operational in several countries and territories worldwide [8]. Although these systems are robust, implementing them can be complex and expensive. The ShakeAlert EEW system in the USA took 15 years to create and is currently deployed in only three states: California, Oregon, and Washington. The deployment costs nearly 100 million USD and requires nearly 39 million USD annually to operate [9]. The cost of deploying an EEW system includes the expenditure of deploying a large number of state-of-the-art seismometers across a vast land mass, which could be economically unviable for many countries and territories [10].

In contrast with expensive high-end solutions, low-cost alternative technological solutions are emerging to create cost-effective EEW systems. Low-cost solutions involve using Internet of Things (IoT) technologies driven by micro-electromechanical systems’ (MEMS)-based sensors [11]. Multiple studies, such as those in Sichuan-Yunnan, California, and Taiwan [12,13,14], have shown the viability and capabilities of MEMS-based sensor networks to provide EEW. Furthermore, with technological advancements, MEMS-based sensors are now embedded with considerable computational and data-processing capabilities, creating opportunities to further innovate and improve EEW systems [11].

Traditionally, the computation and data-processing of EEW systems are carried out at a central location [15]. Data-processing at a central location provides a better control and consistency in data processing; however, it also creates significant bottlenecks and limitations [16]. EEW solutions across the world have recognised the limitations and challenges of centralised processing and invested in redundancy solutions for data transportation and processing [9]. For example, in the US, the Advanced National Seismic System (ANSS) is equipped with three centralised processing units [9]. However, creating such redundancies increase the costs associated with the EEW systems.

In contrast to traditional EEW systems, in this paper, we present a novel approach of using decentralised data processing to generate warnings using a low-cost, MEMS-based sensor network. The paper provides evidence of the performance of this novel approach using data from an experimental network established in Aotearoa New Zealand (NZ).

With the aim of proposing a network architecture that is suitable for an EEW system consisting of MEMS-based, low-cost, ground motion detection sensors and driven by decentralised processing, the remaining sections of this paper are structured to provide the EEW background, including the research gap that this paper tries to address (Section 2), the method used (Section 3), its implementation and results (Section 4), discussion (Section 5), and finally the conclusions of the study (Section 6).

2. Background on Earthquake Early Warning (EEW) Systems

Two basic concepts enable EEW systems. Firstly, information travelling over communication networks moves faster than seismic waves: P-waves (primary or pressure waves) and S-waves (secondary or shear waves) and, secondly, the S-waves produce the most damaging energy in earthquakes, and these arrive later than P-waves [15]. With these concepts, EEW systems use a network of sensors distributed in a geographical area to detect earthquakes and transmit information and warnings in real-time.

Several countries and territories (Japan, Taiwan, Mexico, West Coast USA, etc.) have already implemented EEW systems that can warn the public about oncoming earthquakes for up to tens of seconds before ground-shaking occurs [11]. However, at present, NZ does not have an official, nationwide EEW system [6]. GNS Science—NZ’s geological survey, through the GeoNet project, is the official source of earthquake information [6]. GeoNet comprises high-end geophysical instruments, automated software applications, and skilled staff to provide rapid information about earthquakes [17]. GeoNet’s current instrument density takes around 60 s to compute a robust earthquake location, and thus is only capable of disseminating information through its website and a mobile phone app after the earthquake occurs [6]. GeoNet, as of writing, is not issuing EEW to the public. However, several other parties are providing EEW services in NZ. In April 2021, Google launched an EEW service to Android-based smartphone users in NZ [18]. This technology uses MEMS sensors embedded in Android phones to detect earthquakes. However, very little information on the Android EEW service is available in the public domain. This is not considered an official emergency alert service in NZ [19]. Aside from Google, other commercial providers offer private in-house EEW services to clients, but these services are unavailable to the general public [6].

Despite the lack of an official EEW system that warns the public, a 2019 survey of the NZ public showed that more than 90% support the use of EEW in NZ [5]. However, the significantly high implementation and operating costs of a countrywide EEW system leads to the question of its economic viability to deploy such a system in a country such as NZ, which has a population of only about 5 million. Hence, there is a need to further explore the development of viable EEW options for NZ [5].

The cost-effectiveness, implementation and maintenance of an EEW system is technologically complex. For example, Japan’s EEW system was relatively successful during the 2011 Tohoku earthquake (Mw 9.0); however, the system encountered problems with aftershocks and issued too many warnings, including false alarms [20]. Due to blackout and communication failures, the lack of data from seismometers in disaster areas contributed to the false alarms [20]. A dense network of seismometers is crucial when there are significant lateral variations in the intensity of ground shaking [21]. There are also several other non-technical challenges, such as the minimal time remaining to issue a warning after processing data, public engagement and trust, and a lack of understanding of people’s behaviour during earthquakes [22]. From the above-mentioned challenges, the large costs associated with the implementation of EEW have motivated researchers to further explore the feasibility of implementing low-cost EEW solutions.

2.1. Current State-of-the-Art of Low-Cost EEW Solutions

The United States Geological Survey (USGS) classifies modern seismometers as a data acquisition system (DAS), including the seismic sensor, data acquisition unit, and supporting communication hardware. Based on their performance, DAS are categorised into Class A, B, C, and D instruments [23]. Class A instruments are near state-of-the-art seismometers, while MEMS-based sensors such as Raspberry Shake (RS) are identified as Class C instruments [23,24]. Low-cost EEW solutions, such as those using IoT technologies driven by Class C, MEMS-based sensors, are emerging to bridge the economic and technological gaps [25].

Over the last ten years, advances in MEMS-based technologies have driven down the costs of ground motion sensors [26], while traditional seismic sensors cost tens of thousands of dollars [27]. Declining sensor costs and internet ubiquity are the main drivers of IoT technology [27,28]. The ubiquity of internet connection allows for the implementation of interconnected networks. With the enhanced cloud services, a high amount of sensor data can now be processed to generate warnings and alerts. The growth in this technological advancement should make our cities safer [29].

Such IoT technologies include several low-cost, MEMS-based earthquake sensor devices such as RS [30], P-Alert [14], and Grillo [11,31], each of which is capable of providing complementary and alternative earthquake detection and warning solutions. These low-cost MEMS, with a maximum resolution of 16-bits, can detect earthquakes tens of kilometres away [13]. Dense networks of these low-cost Class-C MEMS accelerometers have been used in seismological investigations, structural health monitoring, and EEW applications [12,13,32]. The P-Alert network in Taiwan, for example, uses a dense array of MEMS accelerometers that form a network of mini-arrays to record from moderate to large strong-motion events [11,14]. P-Alert technology is also used to monitor the Himalayan fault in India and the Apennines Fault in Italy [33,34]. These sensors are vertically mounted on building walls to study how the sensor and structure interactions between the acquired acceleration data can aid in the production of high-quality shake maps. In addition to this, as one of the work packages of the TURNkey European Union project, the University of Iceland has implemented an EEW sensor network using low-cost, MEMS-based RS sensors, where the processing of ground motion data is conducted at a central location [35]. Similarly, the researchers who conducted an EEW project, namely, Community Seismic Network, have designed a sensor package consisting of a three-axis Class-C MEMS accelerometer; these sensor packages are located in buildings, and data processing is carried out centrally at a cloud-based server to provide warnings [36].

The MEMS-based sensor networks are emerging as a solution to several EEW challenges inherent in the architecture of EEW networks [37]. Two key challenges for EEW systems are: (i) when earthquakes occur at the edge or outside the seismic network, and (ii) where the sensor density of the network is lower, thus compromising the required azimuthal coverage [27]. In such situations, it is common for EEW systems to have poor earthquake location estimates and significant alert delays due to their restricted azimuthal coverage and the time needed for the wavefront to reach the required number of sensors and generate an alert [27]. The array-based approach consisting of MEMS-based accelerometers has demonstrated improvements in EEW capabilities; this can be seen in cases such as those in Southern California [13], Northern India [38], Central Italy [39], Taiwan [25,40] and the Sichuan-Yunnan Province [12].

Off-the-shelf sensors similar to those seen in smartphones are also available as scalable opportunistic sensor nodes [41]. Phone-based sensing is possible because almost all smartphones are equipped with MEMS-based accelerometers. These motion sensors can be programmed to work as seismometers, detecting the shaking generated by earthquakes. Although using smartphones is an interesting opportunity, it poses challenges in the production of reliable EEW signals [42]. Additionally, using smartphones only for EEW purposes will not be cost-effective, as smartphones come with powerful CPUs, plentiful memory, and other auxiliary sensors [43]. Lee and colleagues [43] proposed a stand-alone earthquake detection and alerting device for homes in South Korea that can send alerts to nearby devices (e.g., smartphones and TV). As an alternative to a smartphone-based network or stand-alone device, Boxberger and colleagues have proposed an innovative instrumental design called a multi-parameter wireless sensing system that utilises and incorporates off-the-shelf components to analyse ground motion data and issue EEW [44]. Another system, run by Grillo—an independent, private-sector EEW network—uses MEMS accelerometers operating as an IoT and cloud platform, successfully providing earthquake alerts in several high-intensity earthquakes in Mexico [11,31]. Further, in 2012, Fischer and colleagues [15] reported on the testing of a wireless decentralised WLAN-based mesh network for detecting earthquakes using custom-made, low-cost sensors [45]. This is the only research found in the literature which has clearly taken an approach to detect and process data at the node-level. In this project, the approach adopted for communication between sensors limits the distance between the sensor nodes, and is in the range of 200–1000 m. Although the authors claimed that the sensors are low-cost, there is no indication of the actual cost of developing a sensor. With the limitation that two sensing nodes have to be installed very close to each other, this type of EEW system may require a significantly larger number of sensors in a real-life scenario, which may offset its benefits.

Other promising IoT-enabled solutions that are readily available to citizens include BRINCO and BRCK [46]. BRINCO is the first IoT-enabled alarm that can warn users in the personal-aware mode; it sends ground motion data to a private cloud-based data centre and assimilates the information with other seismic networks [46]. BRCK is a versatile IoT-enabled device for use in areas with poor infrastructure, as it can utilise 2G communication, which is ideal for deployment in disaster zones [46]. Such IoT-enabled solutions are integrated with a cloud service for back-end analytics using machine learning and artificial intelligence techniques [46]. While the above low-cost EEW approaches started to show promising results, the affordability of such systems has encouraged the development of systems with increased community participation and engagement.

There are initiatives exploring community and participatory seismic sensing (i.e., citizen science techniques) to improve seismology and EEW [47]. For example, a prototype MacBook-based EEW system called MacSeisApp utilises the sudden motion sensors in people’s laptops to detect seismic activities; it utilises Apple’s Push Notifications via a dedicated server to produce the earthquake notification [48]. The Quake-Catcher Network offers a similar architecture to Apple—a distributed computing seismic network that uses low-cost accelerometers that connect to laptops to record earthquakes [49,50]. Quake-Catcher sensors are installed in the premises of volunteer host participants (e.g., schools, homes, and businesses); these participant sensor hosts exist throughout the world in Chile, Mexico, Taiwan, New Zealand, and other countries [49,50]. Low-cost, MEMS-based networks such as Quake-Catcher could potentially be integrated as complementary systems to traditional seismic networks [50].

An innovative, real-time, citizen-engaged network of mobiles phones was implemented by Zambrano and colleagues [51], considering the coupling features of the geographical zone and time and spatial analysis with crowdsourced data. It offered a precise and customisable architecture for the improvement in the delivery of notifications in and around the epicentre, and demonstrated a reduction in the number of false alarms [51]. Further, in 2015, Minson and colleagues [52] constructed a smartphone-based EEW and conducted an evaluation through controlled tests using simulated data for an Mw 7.0 Hayward fault earthquake in California and actual data from the Mw 9.0 Tohoku earthquake. With embedded MEMS-based motion sensors, smartphones have become a potential tool for consideration in the development of crowdsourced EEW applications. An ongoing, low-cost, crowdsourced, smartphone app-based EEW solution is the MyShake Platform; since its release in February 2016, more than 300,000 people globally have downloaded the app, providing EEW networks in different parts of the world within a short period of time [53]. Similarly, a network of 82 smartphones fixated in buildings in Costa Rica proposed an EEW with a significantly lower cost than a scientific-grade network [41]. Another crowdsourced EEW system is the SeismoCloud App, which shows promise in delivering EEW to users in a region [54]. In addition, in April 2021, Google launched an earthquake alert service to its Android phone users in NZ and Greece [18]. For the Android alerting services, when a phone detects an earthquake, it sends data, including the location details, for processing at a centralised server, and confirms them with shaking detected from hundreds of phones [18].

The above-described EEW solutions incorporate low-cost alternatives by using off-the-shelf components and devices, while some of the solutions have incorporated community and participatory seismic sensing. These low-cost solutions showcased their capability to accomplish complex information-processing activities at the sensor node-level, providing an opportunity to create networks that are driven by robust and faster communications and network topologies [55,56].

2.2. Research Gap

Modern IoT networks often operate in a three-layer architecture consisting of the cloud layer, fog layer, and edge layer [57]. Generally, the cloud layer contains a collection of servers capable of high-performance processing and storage, whereas the fog layer is often identified as an intermediate layer capable of reducing the workload of the devices at the cloud and edge layers [57]. The edge layer often contains devices such as sensor nodes, which are capable of acquiring data. Figure 1 shows these layers as applied to three different architectures.

As shown in Figure 1a, traditionally, IoT-based networks consist of a large number of sensor nodes at the edge layer, which transmit the sensed data to servers located at the cloud layer for processing and storage. In the literature, this type of IoT sensor network is defined as a centralised IoT network [58]. However, with the development of smart devices with enhanced data processing and storage capabilities for a lesser cost, data processing and storage have shifted from the cloud layer to the fog and the edge layers. This type of network is identified as a decentralised IoT network [58]. When it comes to decentralised IoT networks, the processing that occurs at the cloud and other layers can vary depending on the context of the application and the capabilities and capacities of the devices used at the fog and edge layers. For example, some networks use devices attached to both fog and edge layers, or devices attached to all three layers (Figure 1b), whereas some architectures are capable of accomplishing their entire processing or storage needs only at the edge-layer devices, such as sensor nodes (Figure 1c). Enhanced performance of both the fog and edge layer devices have created opportunities for decentralised processing and storage more realistic with the ability to achieve lower latencies, lower operational costs and increased network redundancy. However, when it comes to EEW networks, whether it is high-end sensor networks or low-cost MEMS-based networks, data processing in EEW systems was traditionally carried out at the cloud layer, and the warning sent out as push notifications to the end-users [41,59]. Data-processing at a central location provides the advantage of better control in the detection, collection and processing of data during a disaster and immediately afterwards [16]. However, processing data centrally also creates several technological bottlenecks and limitations. One of the main limitations is the risk of disruption in data collection to a central location due to the impacts on the telecommunication infrastructure after a big earthquake [60]. Data-processing centres, intermediate data-collection centres, and infrastructures to transport data may be severely disrupted or destroyed after an earthquake [61]. Unavailability of the central processing capability due to the loss of connectivity may hinder the issuing of time-critical warnings to end-users. EEW systems have recognised the limitations of centralised processing and, therefore, invested in redundancy solutions for data transportation and processing [9].

Modern-day, MEMS-based, ground motion detection sensors have significant processing capabilities, and they possess the ability to run ground motion algorithms and data-processing at the sensor node itself [11]. Improvements in technological capabilities have created an opportunity to explore how these sensors can be utilised to reduce the amount of centralised processing for ground motion data and the possibility of generating node-level alerts that are sharable among the sensor nodes and other connected devices. This approach could reduce the cost of earthquake solutions. A node-level approach may also increase the resilience of systems as it provides the possibility of alerting end-users at regional and local levels, despite infrastructure failures occurring in parts of the system. However, at present, most of the MEMS-based EEW systems either work as isolated private solutions or are inhibited by telecommunication latencies and centralised processing bottlenecks [11]. Except for the experimental EEW system based on custom-made sensors by Fischer and colleagues [15], there is limited evidence in the existing literature regarding detecting and issuing alerts in a more decentralised manner, where detection algorithms are run at the node-level of a MEMS-based sensor network to become self-configurable and self-healing. The approach proposed by Fischer and colleagues [15] seems capable of detecting earthquakes and processing data mostly at the node-level. However, there is no clear discussion regarding the robustness of the system, with only limited testing and evaluation having been completed. Further, they did not attempt to compare the performance of their approach with the traditional centralised EEW networks [15].

3. Methods

With the above-mentioned gaps in the EEW literature, we propose a fully decentralised, community-engaged, MEMS-based, EEW sensor network architecture. Similar to Figure 1c, the proposed architecture processes ground motion data exclusively at the edge layer using the sensors. This paper focuses on designing the above-defined EEW sensor network and discusses its step-by-step development. The proposed architecture fully operates at the edge layer, consisting of low-cost MEMS-based sensors capable of successfully running a reliable earthquake detection algorithm within the sensor node and securely exchanging ground motion and earthquake alert data with other nodes. These MEMS-based sensors are hosted and operated by individual citizens and community groups in NZ, where the sensors are installed in a private home, or a property owned by a particular community or a group.

The implementation of an appropriate and feasible community-based MEMS sensor network started with: (1) exploring different wide area network (WAN) topologies, followed by (2) selecting a software-defined WAN (SD-WAN) solution for a community-engaged EEW sensor network, (3) selecting appropriate sensors, and finally (4) selecting an appropriate EEW algorithm.

3.1. Explore Appropriate WAN Topology

Establishing secure communication links between the sensors installed in (1) different private local area networks, (2) supported by various internet service providers, and (3) located in different geographical locations is a key challenge in building a community-led low-cost sensor network. Therefore, it is important to investigate the available WAN technologies as possible solutions. Ideally, the WAN topology should support the building of a sensor network where the sensors are owned and hosted by the community members. The securely connected MEMS-based sensors communicate with each other to exchange data while installed at different geographical locations attached to private household computer networks. The following subsections explore potential WAN approaches that are suitable for implementation of the proposed EEW network.

3.1.1. Virtual Private Networks (VPN)

When it comes to exploring WAN approaches, Virtual Private Network (VPN) is one of the well-known, capable of creating secure networks, connecting devices in geographically dispersed locations attached to privately owned networks [62]. While VPNs are popular among business organisations, they are resource-intense and complex to set up and implement [63]. These issues are particularly relevant when designing and implementing citizen science or crowdsourced network, which consists of low-cost, MEMS-based sensors where end-users do not belong to a particular organisation or consortium. The end-users of this type of system are going to be members of the general public. However, they do not have any direct relationship or collaboration with each other, except that their host devices are connected and communicate with each other to form a network of ground-motion sensors to provide a public service by generating warnings. Therefore, VPN may not be suitable for building a community-engaged, MEMS-based EEW network, given the associated complexities in ownership and costs. However, another option to explore is the SD-WAN as an appropriate networking method to develop the proposed, community-engaged network.

3.1.2. Software-Defined WAN (SD-WAN)

SD-WAN is a virtual software-based WAN management approach. SD-WAN benefits include: (a) cost or price advantages with freedom of transportation across different communication infrastructure and technologies, (b) ability to enhance the performance of the applications and their agility, (c) appropriateness for software-as-a-service and cloud-based applications and (d) easy-to-operate, automated environment supported by cloud-based management [64].

Compared with VPN, SD-WAN virtualisation technology [65] can be considered more appropriate for citizen-engaged or crowdsourced networks. SD-WAN automatically repairs any outages occurring across the network nodes. Therefore, anyone can easily connect a sensor to the network, as SD-WAN offers “self-healing” capabilities. SD-WAN can also ensure automatic alignment while the network topology changes [66]. Due to SD-WAN’s granular level of support and promising technology features, such as caching or application acceleration, devices located at any type of private network (homes, cafes, libraries, community centres, etc.) can readily maintain the connectivity. SD-WAN-based networks can readily allow for individuals or organisations to connect their devices and communicate using any internet connection as a specific communication infrastructure is not required. The flexibility offered by the SD-WAN-based networks makes it a more appropriate approach to implementing the proposed, community-engaged, MEMS-based network.

3.2. Selection of SD-WAN Solution for a Community-Engaged EEW Sensor Network

The proposed EEW network sensors are expected to be installed at community members’ homes. Therefore, after its initial configuration, the sensors should easily connect to any household internet connection and switch networks; ideally, they should function as a plug-and-play. Therefore, this architecture should be designed with the ability to penetrate firewalls and a Network Address Translation (NAT), equipped with self-healing ability during a loss of connection, and be able to dynamically self-configure to manage varying conditions of the network address (as there is a possibility that sensors may change locations for multiple reasons). Ideally, the connection should be capable of being verified and encrypted to mitigate hackers breaking the network defences.

3.2.1. Hole Punching to Overcome Network Address Translation (NAT) Challenges

Network Address Translation (NAT) imposes common challenges in peer-to-peer (P2P) communication [64]. This is primarily because peer nodes may not be able to reach any form of globally valid IP address [64]. Although there are known NAT traversal techniques, there is minimal literature about them and their functionality. Further, there is only minimal information to justify their efficiency and effectiveness [64]. However, the technique commonly known as “hole punching” is considered one of the least complicated, yet more robust and effective NAT traversal techniques, where it simply creates a tunnel for reliable communication between two communicating entities, irrespective of the communication protocol being used. According to Reference [64], about 82% of the NAT techniques support hole punching to work with User Datagram Protocol (UDP), while about 64% support hole punching to work with Transmission Control Protocol (TCP). The use of NAT applications has become crucial for various peer-to-peer applications such as online gaming and voice over IP (VOIP) protocols. Devices attached to networks with public IP addresses should communicate with each other very easily. Additionally, the clients with private addresses could be able to connect to a public server without any difficulty if they can initiate a connection while behind a router or firewall. However, for hole-punching to operate properly, it is essential to form direct communication between two devices installed behind routers or firewalls that use NAT.

Ford and colleagues initially explored the use and application of hole-punching [67], and it has gained considerable attention in the peer-to-peer application communities. Furthermore, the specifications of several experimental level protocols, including STUN, ICE, and Teredo, have documented the key features of the UDP-based hole-punching techniques [67]. However, there are no published works that thoroughly analyse the advantages and disadvantages of hole-punching for multi-level NAT.

3.2.2. Selection of Appropriate UDP Hole-Punching SD-WAN Solution

We considered several popular hole-punching solutions, including WireGuard, Openvpn, Nebula, ZeroTier and Tailscale, to identify the most appropriate to build the community EEW network [68]. In this process, we considered factors such as scalability, flexibility, cost and security. Having considered the pros and cons of the available solutions with regard to NAT-related challenges, we selected ZeroTier as the most appropriate SD-WAN hole-punching solution to implement the intended, community-engaged, MEMS-based EEW network. According to Goethals and colleagues [68], the response time, failure rate, packet loss, and latency of ZeroTier are in the acceptable range to build a proposed community-engaged SD-WAN solution. ZeroTier is capable of reducing the network management complexities by combining the strengths of both the VPN and SD-WAN approaches. ZeroTier’s software solution allows for devices, applications, and services to be connected simply and securely, regardless of their physical location [69]. This can be used in various use cases, including VPN, multi/hybrid-cloud, SD-WAN, peer-to-peer networking, and IoT remote access, allowing all these things to be achieved with a single system, leading to vastly reduced complexity and associated costs.

ZeroTier’s UDP hole-punching mechanism allows for connecting devices to communicate with the use of any type of data packet including TCP, UDP, etc. Basically, it captures data packets from the sender and transmits them to the receiving end through the transmission tunnel created with the UDP hole-punching mechanism. However, similar to any other solution, it comes with its own limitations. Like any other proprietary hole-punching technology solution in the market, it comes with a cost. However, ZeroTier is more affordable than most similar tools available on the market. It is especially appropriate for the experimental type of network as it offers a free service for networks of fewer than 50 devices. Although ZeroTier ensures scalable end-to-end security using 256-bit encryption, it can create vulnerabilities, especially with the type of devices used for the proposed work and hence needs further attention regarding security measures.

The decision to use ZeroTier as an appropriate SD-WAN solution to implement in the proposed network has provided the ability to assign a unique IP address for each sensor when it is connected to the EEW network. As the MEMS-based sensors are to be installed in people’s homes in a citizen science environment, having individual IP addresses for each sensor will help connect sensors to the proposed, highly flexible and ad-hoc sensor network without a dedicated network infrastructure.

3.3. Selection of Suitable Sensors for the Proposed MEMS-Based EEW Network

Having selected the ZeroTier as an appropriate SD-WAN solution to build the proposed EEW sensor network, the next crucial step is to decide on the type of MEMS-based ground motion sensor or sensors to implement the proposed sensor network. In this process, we evaluated several low-cost MEMS-based ground motion sensors that are available on the market. The selection criteria of MEMS sensors include node-level data-processing ability, the memory of the sensor, accessibility, accuracy of the sensor data and price of the sensor. These selection factors are crucial as the proposed network not only captures the ground motion data from the sensors but also processes the data within the sensors, as opposed to other traditional EEW systems where sensors are only used to capture the data. The sensors evaluated for selection include popular off-the-shelf MEMS-based ground motion sensors on the market, such as those from P-Alert [14], Canterbury Seismic Instruments (CSI) [70], Grillo [11,31], and RS [30].

Having compared the sensors against the above-described criteria, we selected the RS sensor to build our experimental network. Its openness to access and relatively superior processing ability led us to select the RS sensor. Comparatively, other sensors provide limited direct access to the sensor and data and the limited processing capacity at the sensor node, which must be resolved before connecting to the proposed network. At present, we are in the process of engaging with sensor manufacturers who have developed other popular, low-cost, MEMS-based sensors in the market with the aim of resolving some of the above-mentioned limitations. It is expected that removing the above-described limitations will create future opportunities to integrate multiple types of MEMS-based sensors into the proposed network rather than depending solely on RS sensors.

Several different types of RS sensors are currently available on the market, namely RS1D, RS3D, RS4D and RSBOOM, RSSHAKE&BOOM. Even though the listed RS sensors are equipped with different sensing capabilities, all of them are powered by Raspberry Pi 3 Model B with a Broadcom BCM2837 4 × ARM Cortex-A53 (1.2 GHz) processor with 1GB LPDDR2 memory. We implemented our experimental RS EEW network by adding different types of RS sensors but predominantly the RS4D, which consists of a geophone and triaxial C-class ground-motion accelerometer.

3.4. Selection of an Appropriate EEW Algorithm

Having identified the appropriate SD-WAN networking approach, followed by the type of MEMS-based sensor, the next crucial step is to identify an appropriate EEW algorithm that can successfully be implemented within the RS sensor node, which is constrained by its processor’s computational and processing capabilities. With the aim of identifying the best-suited detection algorithm, several popular EEW algorithms were compared and evaluated. The complexity of the algorithm and the level of the computational capacity of the sensors are two main factors that were considered during the selection of the detection algorithm.

At present, a variety of EEW approaches have been used across different parts of the world [11]. These approaches can broadly be classified into three categories: (i) the source characterisation, (ii) ground-motion-based EEW and the (iii) on-site prediction approaches [59,71,72]. These three approaches have several strengths and weaknesses depending on the EEW implementation environment [55].

There are notable drawbacks to consider when selecting an EEW method based on source characterisation. These drawbacks include missing earthquake detection during extreme seismic activities, underprediction of large strong-motion earthquakes with finite faults, and overprediction of large, multiple, simultaneous earthquakes [73]. When it comes to on-site prediction approaches, predicting the intensity of the S-wave with the P-wave’s intensity using a single station can lead to inaccurate results [11]. In contrast, ground-motion-based EEW approaches showed promising and accurate results [71]. One of the newer ground motion-based algorithms: the PLUM algorithm by Kodera, has become popular due to its robustness, lightweight design and easy-to-implement nature [71]. The PLUM algorithm has already been implemented in Japan as part of their EEW method [71]. EEW researchers in the West Coast USA are also studying the PLUM algorithm to integrate it into their sensing and alerting system [74]. Considering these implementations, supported by their robustness and ability to perform well in resource-constrained environments, our research has chosen the PLUM algorithm as the most appropriate EEW algorithm to implement the proposed, decentralised, MEMS-based EEW architecture.

4. Implementation and Results

4.1. Implementation of a Raspberry Shake (RS) Sensor Network

We have deployed nearly 25 sensors across five regions in NZ’s North Island: Auckland, Rotorua, Palmerston North, Wairarapa, and Wellington. While our network currently consists of different types of RS sensors, the experiments and evaluations conducted in this paper used RS4D sensors. Figure 2 shows an example of the proposed network with RS4D sensors (S1, S2, … Sn), where sensors are installed at the homes of the general public attached to the home local area network. In this arrangement, data processing entirely occurs at the sensor node, and the communication takes place directly between the sensors without any centralised servers.

4.1.1. Implementation of Appropriate Security Measures for RS Sensor Network

Having selected an RS-based EEW sensor network implemented on a ZeroTier SD-WAN platform, making the sensor network secure is considered the next most important step in the process of building the proposed EEW network. Security becomes paramount, especially because the proposed network consists of RS sensors located at the homes and premises of the general public and attached to private home networks. Even though ZeroTier provides strong end-to-end data security between the low-cost, MEMS-based devices, the proposed node-level processing architecture could still create opportunities for potential security breaches.

Such security breaches can become harmful since sensors are located in different geographical locations, attached to different home-based private networks. It was found that most of the potential security breaches that could be anticipated in the proposed architecture may primarily occur by directly or indirectly accessing the sensor through outside networks [75]. Successful login to a sensor by a third party could allow a user to (a) gain admin access [75], (b) find IP addresses of other sensors through brute-forcing [76], (c) access the source files, (d) remote login into another sensor [77], and (e) sneak out to an outside network [78]. Figure 3 shows the interconnectivity of the above-mentioned threats.

In terms of security measures, several protection mechanisms were implemented at each sensor to increase security at each level in the above diagram. Direct login access was restricted by introducing security configurations to the user account in each sensor. In addition, all possible IO ports, such as USB, serial, i2c, HDMI, etc., were disabled. Furthermore, remote login to the sensors was restricted so that it can only be carried out through the admin’s centralised server. With that, remote login to the sensor from the centralised server is only permitted with a Secure Shell (ssh) key, which is pre-generated and saved inside both server and sensor such that each sensor could have a unique ssh key. In addition, incoming ping requests to all sensors were restricted to reduce the risk of automated hacking tools. Due to security breaches in open network ports, all the unused open network ports were disabled by configuring a network firewall. Moreover, we reduced the number of incorrect login attempts and banned the user IP for a considerable amount of time in case of multiple incorrect login attempts. To protect the source code, we encrypted all the files used for communication purposes with AES-256 encryption [79], which makes it harder to decrypt the source code.

To ensure the security of the proposed community-engaged architecture, we installed the above-mentioned security measures to selected RS4D sensors. After having installed the software to enhance the security, the vulnerability of the network to security breaches was tested using a separate RS4D sensor environment dedicated to testing the performance of newly installed security features. These tests were conducted before the sensors were connected to the proposed EEW sensor network. As a first step, we used a network vulnerability scanner (Nmap) [80] and a password cracker (brute force attack generator) [81] to assess the vulnerability of the network and ensure a proper configuration. The vulnerability scanner was only able to discover the expected open network ports of the RS4D sensors from all the available network ports (1000 ports). Further, the password cracker tool was not able to log in from one sensor to another. These outcomes can be considered a confirmation of the enhanced security of the network due to the newly implemented security measures.

4.2. Implementation of Modified PLUM EEW Algorithm within RS Sensor Environment

Having introduced measures to secure the node-level sensor environment running on a ZeroTier SD-WAN solution, the next crucial step is to implement the PLUM algorithm within the RS sensor nodes to detect the earthquakes.

When implemented with the RS4D sensor, the PLUM algorithm should be able to use the real-time seismic data captured by the sensors to predict the seismic intensities at the given prediction points within an area of a 30 km radius [71].

As shown in Figure 4, the prediction process for a given location (red star) takes place in a circle with a 30 km radius around an observation data point (blue dot). While the PLUM algorithm operates with a single operating point, this approach was subsequently criticised for the possibility of false or missed alerts and to terminate the propagation of the alert [82]. This is particularly relevant for the proposed type of EEW network, consisting of low-cost sensors installed in the homes of the general public, which are often in noisy environments compared to the high-end EEW networks consisting of sensors installed in much more noise-controlled environments. Therefore, it is crucial to include extra observation points in the system to avoid false or missed alerts and terminate the propagation of a false alert [82]. Accordingly, to minimise the anticipated false alarms by having only a single observation station, we made a few modifications to Kodera’s original PLUM algorithm. In our modified approach, we only use the PLUM approach to predict the seismic intensity of a station using the observed real-time intensity at an observation station. Rather than taking the maximum observed seismic intensity concept to predict the station intensity [71], we are directly assigned the real-time seismic intensity of the observation station to the prediction station. In this process, to reduce the number of false alerts, we introduced a two-station trigger concept to the PLUM algorithm, as proposed by Cochran and colleagues [74]. This modified PLUM algorithm triggering occurs when the predicted seismic intensity exceeds a predefined threshold at a particular sensor. Then, the triggered sensor will check whether any of the neighbouring sensors has experienced a ground motion intensity above the same threshold within a defined waiting time. An alert will only be issued if these conditions are met. Otherwise, the system will terminate the alert. As reconfirmed in a more recent EEW study in the US [82], this modified PLUM approach with a two-station trigger concept is expected to reduce the number of false alerts and increase the accuracy of the alert generation.

4.3. Defining and Calculating System Latency for the Proposed EEW Architecture

As shown in Equation (1), The system latency of the proposed EEW network (δt_{sys_latency}), can be defined as the sum of three components δt_detect (detection time)_, δt_transmission (transmission time) and δt_{s-wave_travel} (S-wave travel time).

Equation (1) proposed a formula for EEW system latency:

$$\mathrm{\delta }{\mathrm{t}}_{\mathrm{sys\_latency} }=\mathrm{\delta }{\mathrm{t}}_{\mathrm{detect}}+\mathrm{\delta }{\mathrm{t}}_{\mathrm{transmission}}+\mathrm{\delta }{\mathrm{t}}_{\mathrm{s-wave\_travel}}$$

(1)

4.3.1. Transmission Delay (δt_transmission)

This research defines the transmission delay (δt_transmission) as the time taken to transmit the data between two sensors within an area of a 30 km radius, and it is only dependent on telecommunication factors; it is independent of the earthquake characteristics. Furthermore, the transmission delay (δt_transmission) was measured, along with different communication protocols to identify which protocol could minimise the transmission delay.

4.3.2. Detection Time (δt_detect)

Detection time(δt_detect) is the time taken for a particular detection algorithm to calculate and issue an alert of an earthquake when seismic intensity at a sensor goes above the predefined shaking intensity threshold [41]. Therefore, δt_detect depends on the type of the algorithm and its complexity. Furthermore, δt_detect also depends on the specifications of the ground motion detection sensor itself (in this research, RS). This includes the speed of the processor, size of the RAM, the capacity and the speed of the storage, where these factors determine the speed of execution of the algorithm at the node-level.

4.3.3. S-wave Travel Time (δt_{s-wave_travel})

With the multi-station trigger concept, S-wave travel time (δt_{s-wave_travel}) is defined as the time taken for the S-wave to travel from the first observation sensor to the farthest observation sensor from the epicentre. For different earthquakes, the S-wave travel time will differ according to the sensor geolocations and the number of sensors used to trigger the alert (e.g., two sensors for our approach). As mentioned in the PLUM algorithm section, using the low-cost EEW sensor network proposed in this study, the use of two observation stations to trigger an alert is essential to reduce the number of false alerts [82]. Due to the two-station trigger concept, even though the first sensor in the network detects the earthquake in a fraction of time, it needs to wait for confirmation from the 2nd observation sensor. This makes the S-wave travel time between the 1st and the 2nd observation sensor (δt_{s-wave_travel}) a significant component of determining the system latency. For our experiments, we assumed that the earthquakes are shallow and the generated S-waves propagate horizontally as a plain wavefront with a constant speed of 3 km/s [71].

4.3.4. System Latency Calculation Scenarios

To test the performance of the proposed decentralised EEW sensor architecture as well as to obtain its δt_{sys_latency}, we calculated δt_detect, δt_{s-wave_travel} and δt_transmission separately. As the first step, we calculated the transmission delay (δt_transmission), followed by the detection time (δt_detect), and finally the S-wave travel time (δt_{s-wave_travel}).

For the latency calculations, we deployed a ground motion data simulator inside each RS ground motion detection sensor, capable of accurately simulating the ground-shaking captured by the RS MEMS accelerometers. In this process, we created six hypothetical shallow earthquake scenarios with their corresponding S-wave arrival from various azimuthal directions towards the installed sensors in Wellington. This paper presents the results obtained from the hypothetical earthquake scenarios that originated from the regions that were anticipated to create ground shaking in the Wellington region. One of the six scenarios was from the direction of Hawke’s Bay region, another one from the Tūrangi region, three from the Cook Strait, and the final one from the South Wairarapa region.

In terms of installing sensors, even though we planned to utilise a higher number of sensors located in the Wellington region, our sensor installation efforts in the community were disrupted due to the COVID-19 lockdown. This led to a limit on the number of sensors that were available for the experiments. At the time of conducting the latency experiment, as shown in Figure 5, there were only five sensors available in the Wellington region, which was considered sufficient to conduct the experiments.

As the next step, for each sensor, time-stamped ground-motion datasets with the calculated S-wave arrival time due to a particular earthquake scenario were programmed into the data simulator installed within the sensor. Thereafter, the pre-programmed data simulator in each sensor were triggered at the exact time when the S-wave (with the velocity of 3 km/s) of each earthquake scenario was expected to reach that particular sensor. For the simulations, we assumed that the earthquake waves travelled as circular waves [41]. For the hypothetical earthquake dataset, we used a ground motion dataset captured by our RS sensor network. Each earthquake scenario was repeated ten times, leading to a total of 60 simulations. After running ten simulations for each scenario, the range of the values obtained for the system latency for all the investigated protocols remained negligible and was in the milliseconds range. Therefore, we decided that it is reasonable to report the average findings obtained for the latency figures for each scenario.

Calculating the Transmission Delay of the Network (δt_transmission)

With the hypothetical simulated environment, we analysed and compared different standard communication protocols that support the implementation of IoT-based networks to select the protocol that provides the minimum value for the δt_transmission. This is important, as having a minimum value for the transmission delay is desirable for a time-critical application such as EEW.

At present, several popular communication protocols support the implementation of IoT-based networks [83]. Among them, Message Queuing Telemetry Transport (MQTT) is an application layer protocol based on TCP/IP with a publish and subscribe data transfer mechanism [84]. In comparison, both the TCP and UDP are standard communication protocols without any application layer [85]. These three protocols were evaluated to find the most suitable primary communication protocol for the proposed EEW network. By evaluating the standard communication protocols, TCP and UDP, we defined an application layer where client–server communication can take place.

Having recognised the potential use of the above-mentioned protocols for communication, we compared the transmission delay (δt_transmission) obtained for each of the protocols. During this comparison, TCP, UDP, and MQTT protocols were tested for the end-to-end transmission delay between two sensors for a cycle of 24 h.

Figure 6a shows the average transmission delay recorded for each hour for a 24-h period for the UDP and TCP protocols, while Figure 6b shows this for the MQTT. When comparing the average transmission delay for a day for all three protocols, UDP outperformed the TCP and MQTT, with an average δt_transmission of 16.10 ms, whereas TCP and MQTT reported an average of 51.38 ms and 613.51 ms, respectively.

It is evident that the δt_transmission of UDP is much smaller than that of TCP and MQTT, but the reliability of the data delivery of each protocol should be considered before selecting the best communication protocol for the proposed EEW network. Therefore as the next step, the reliability of each communication protocol is analysed.

According to the communication protocol characteristics, it is evident that TCP has its own benefits, such as error checking mechanism and handshaking process between the sensors, which ensure reliable data communication compared to the UDP, which has none of the above characteristics.

When selecting the most appropriate communication protocol, it is evident that MQTT is the least appropriate due to its high δt_transmission, so it is not suitable for the proposed EEW architecture. As the next step, UDP and TCP were compared to identify the most appropriate. Even though UDP protocol resulted in a δt_transmission which is one-third of the TCP’s δt_transmission, UDP does not guarantee reliable data delivery, which can be considered a significant limitation for a time-critical application. It was also observed that the performance difference between the protocols is in the millisecond range, and hence can be considered as only creating a negligible impact on the system latency.

Having considered findings from the evaluation process of the protocols (MQTT, UDP and TCP), TCP was selected as the best communication protocol for the proposed EEW network to conduct the communication between the sensors.

Calculating the Detection Time (δt_detect) of the Network

The detection time (δt_detect) for the proposed EEW architecture was calculated in the RS4D sensor environment by implementing a modified PLUM-based earthquake detection algorithm. In this experimental environment, the calculated δt_detect varied between 0.10 and 0.19 s for the six selected hypothetical earthquake scenarios (

Table 1. Reported average latencies for the six hypothetical earthquake scenarios with the decentralised architecture.

Hypothetical Scenarios *	Decentralised Processing Using TCP (in Seconds)
	δtdetect	δttransmission	δts-wave_travel	δtsys_latency
Scenario 1	0.10	0.05	2.50	2.65
Scenario 2	0.13	0.05	2.70	2.88
Scenario 3	0.19	0.05	1.00	1.24
Scenario 4	0.17	0.05	1.20	1.42
Scenario 5	0.17	0.05	1.10	1.32
Scenario 6	0.19	0.05	1.60	1.84

* See Appendix A for illustrations of the scenarios with corresponding azimuthal directions.

). We selected the PLUM-based approach due to its simplicity and easy-to-implement nature [71]. Additionally, PLUM does not calculate the source parameters of the earthquake, which makes it comparatively faster than most other EQ detection approaches [11]. More importantly, it requires less processing power. Therefore, the obtained δt_detect values show that the RS4D type of low-cost sensor, with its Raspberry Pi 3 Model B processor, is easily able to provide the level of processing power required to run a PLUM-based detection algorithm.

Calculating the S-Wave Travel Time (δt_{s-wave_travel}) of the Network

When it comes to S-wave travel time (δt_{s-wave_travel}) between the first and the second observation sensors, the travel time differs according to the earthquake scenario, since it is primarily dependent on the respective sensor locations, in relation to the direction of the S-wave. Our findings from the six earthquake scenarios presented in this paper confirm the above observation as the S-wave travel time (δt_{s-wave_travel}) between the first and second sensors varied between 1.0 and 2.7 s (Table 1). Furthermore, it is evident from the findings that there is a clear correlation between δt_{s-wave_travel} and the density of the sensor distribution in the S-wave travel direction. When the S-wave is directed towards the areas with lesser sensor distribution, it resulted in a higher δt_{s-wave_travel} value, whereas a lower δt_{s-wave_travel} value occurred in the direction of higher sensor distribution.

Overall, simulation experiments conducted with the node-level processing approach resulted in a system latency (δt_{sys_latency}) between 1.24 and 2.88 s (Table 1).

Comparison of System Latencies for the Decentralised and Centralised EEW Architectures

In addition to conducting experiments at the node-level with decentralised architecture, we also implemented a centralised network architecture connecting the same set of sensors used for the node-level processing to make a comparison (Figure 7). Unlike the decentralised architecture, the centralised processing architecture consists of an additional computer that acts as a central server to perform all the detection algorithm processing. Sensors in the centralised architecture forward the ground-motion data they captured directly to this dedicated server, at which point the detection algorithm is executed. After the execution, the computer will disseminate the alert data to the appropriate sensors.

Although there is not much evidence available in the literature about the specifications used for centralised processing servers, we found that most of the implementations published with centralised processing used the Amazon Web Services (AWS) as their centralised data processor [9,41]. However, the specifications of the implemented AWS server were not described in any of the centralised processing literature. Thus, guided by the above literature, for our decentralised vs. centralised comparison, we used the Amazon Web Services (AWS) virtual machine as our centralised server to connect the RS4D sensors with the configuration of t2. micro instance, 1GB RAM and 8GB memory.

The experimental simulations with the centralised architecture were conducted using two standard communication protocols: TCP and MQTT.

Although we selected TCP as the best communication protocol to implement the decentralised EEW architecture, when calculating the latency for the centralised architecture, we compared the performance of the centralised architecture with the use of both TCP and MQTT. This is because, traditionally, most of the centralised EEW architectures primarily use MQTT as their communication protocol, but not TCP. As shown in

Table 2. Reported latencies for the six earthquake scenarios with three different architectures.

Hypothetical Scenarios	System Latency for Centralised Processing (in Seconds)		System Latency for Decentralised Processing Using TCP (in Seconds)
	MQTT	TCP
Scenario 1	4.15	2.94	2.65
Scenario 2	4.57	3.13	2.88
Scenario 3	3.24	1.48	1.24
Scenario 4	3.51	1.69	1.42
Scenario 5	3.32	1.64	1.32
Scenario 6	3.84	2.08	1.84

, the results obtained from the comparison experiments clearly show that the TCP-based decentralised EEW architecture proposed in this research, implemented on a ZeroTier SD-WAN platform, outperforms the traditional centralised EEW architecture that operates with either MQTT or TCP.

As shown in Table 2, the results also show that, when running the simulations for the six earthquake scenarios, the centralised processing model with TCP as the communication protocol performed better compared to MQTT. This is evident for the centralised architecture with a TCP reported system latency (δt_{sys_latency}) in the range of 1.48–3.13 s, whereas, when using the MQTT, the system latency (δt_{sys_latency}) varied between 3.24 and 4.57 s.

We also observed that, when using the centralised processing approach, the system latency increased with the number of sensors in the network. In a real-time scenario, a typical nationwide EEW network may consist of hundreds of sensors and, during an actual earthquake, with the use of the PLUM approach, the system has to deal with a significant number of circular regions with a 30 km radius. In such a situation, the system has to identify the region of the detection sensor accurately, followed by its neighbouring sensors. In a centralised arrangement, this processing needs to be carried out in a single dedicated server, and a high number of sensors attached to a number of circular regions will lead to an increase in the complexity of the processing software. The increased complexity of the software is evident when comparing the pseudocodes of the decentralised architecture (Figure 8a) and centralised architecture (Figure 8b). It can be clearly seen that, as shown in Figure 8b, for the centralised processing architecture, it is essential to include two additional if conditional blocks to identify the region and the neighbouring sensors of a particular detection sensor.

With this added complexity, the respective pseudocodes show that the processing time rises along with the number of sensors in the EEW network. Therefore, in a real-life scenario, when an EEW system carries a high number of sensors located across a vast geographic region, a system that operates with centralised processing, identifying the region of a sensor and its neighbouring sensors will become significantly time-consuming. In contrast, when using the decentralised approach, the system latency does not depend on the number of sensors outside the radius of its 30 km region; each sensor will only communicate with sensors within the 30 km radius.

To check the validity of the above observation, in addition to the five sensors installed in the Wellington region, we introduced several additional sensors installed in different regions outside Wellington. We recalculated the system latency with the centralised processing network approach (Figure 9). As shown in Figure 9, these additional sensors were installed in four geographically dispersed regions on the North Island of NZ.

As discussed above, our proposed approach is mainly based on disseminating the alert in a 30 km radius. The introduction of more sensors in a large area, as shown in Figure 9, increased the processing time at the central server. Introducing additional sensors creates an essential need to identify the sensor’s region and its neighbouring sensors during a particular earthquake event.

The results obtained from this multiple region scenario show that the system latency varied from 1.52 to 3.2 s for TCP. This was earlier reported as 1.48 to 3.13 s when operating with only a single, 30-km-radius circular region (Table 2). Despite the above findings having reported a marginal increase in latency, the above experimental results provide evidence to show that the system latency of the centralised architecture continues to increase with each additional sensor that is added into the system. Therefore, we can argue that the system latency of an EEW system with centralised architecture can increase in a situation where the network consists of a significantly high number of sensors dispersed across multiple 30-km regions.

Calculation of Packet Loss

In addition to calculating the system latency, we further investigated the packet loss for the three-sensor network approaches (decentralised processing with TCP, centralised processing with TCP and centralised processing with MQTT) to compare the system latency. These investigations reported significant packet loss when we ran the experiments in a centralised architecture environment where the MQTT was used as the primary communication protocol (Figure 10). In contrast, the reported packet loss was zero for both the decentralised and centralised architecture when we used the TCP as the communication protocol. Although the MQTT is built on top of TCP, the main reason for the packet loss is the packet drop in the centralised broker. We used the free version of the PAHO MQTT centralised broker, where a considerable amount of data packets was dropped due to the heavy traffic in the server [86].

5. Discussion

Unique to any of the previously conducted EEW research across the globe, the research presented in this paper introduces a comprehensive sensor network architecture from scratch, with the specifications of the essential components needed to construct a low-cost, MEMS-based EEW system. Mostly, the previously published literature on EEW systems primarily focused only on discussions of system latency and the accuracy of the network architecture [8,11,41]. In contrast, this paper has investigated all the components and steps required to implement an EEW system and compared them with the existing approaches. In addition, the decentralised EEW sensor network architecture proposed in this paper shows that the detection of earthquakes and processing of ground-motion data can successfully be implemented at the sensor node. This research explored and implemented an experimental EEW system by employing 100% decentralised processing compared to the currently available EEW approaches based on centralised processing [8,11,41,87]. Even though Fischer and colleagues proposed a decentralised EEW approach, there are no clear findings of the robustness of their system [15]. Further, this paper also demonstrates that using a lightweight and easy-to-implement algorithm such as PLUM can be considered an ideal EEW approach, that is suitable for implementation in resource-constrained environments such as low-cost, RS MEMS-based sensors.

Our work demonstrates that a low-cost, MEMS-based sensor network with decentralised processing can be used to produce EEW alerts to the public with a minimal cost compared to both high-end EEW systems such as California’s ShakeAlert and low-cost systems such as Costa-Rica’s ASTUTI [41]. Further, it should be noted that, with the decentralised processing, the proposed EEW architecture outperforms a system with centralised processing; therefore, there will be no additional costs in implementing a centralised middleware server. The major proportion of the cost of our proposed EEW solution is allocated for purchasing the MEMS-based RS sensors. Furthermore, the annual running cost of the proposed network primarily consists of the internet usage of the sensors. Implemented as a community-engaged EEW solution, the public usually absorbs the internet charges.

Most of the network architectures constructed for EEW systems in the past were mainly focused on centralised processing rather than node-level processing. From the results of our proposed decentralised processing approach, it is clear that it outperforms the other proposed approaches worldwide [11]. The data transmission delay between the sensors plays a significant role in the system latency of the EEW system. Our results show that the standard communication protocols UDP and TCP outperform the commonly used communication protocol MQTT. Even though the UDP outperforms TCP by a minimum value of approximately 35 ms, it is always advisable to use TCP as the communication protocol for time-critical applications due to its higher reliability compared to UDP. To compare and evaluate the performance of the communication protocols, along with the proposed SD-WAN architecture, we implemented a centralised processing architecture by adding an AWS virtual machine to the network. From the results obtained from the latency calculations, we can see that the system latency of our proposed decentralised processing outperforms the MQTT-based centralised processing approach by a considerable value of approximately 2 s. It is also evident that the packet loss when using MQTT is a significant drawback for a time-critical application, where packet losses cannot be accepted.

The results show that the system latency of the centralised processing increases with the number of sensors in the network since there is only one processing unit for the complete network, compared to decentralised processing, where each sensor processes the algorithm for the sensors within the 30 km radius. Furthermore, the additional processing blocks for the centralised server, such as identifying the area of the particular sensor and the neighbouring sensors in an earthquake event, will also add to the delay. In comparison, our approach will not have such a delay as the sensors only directly communicate with other sensors in the 30-km-radius area. Our results also show that the decentralised processing approach significantly reduces latency by deploying more sensors in the network, which will shrink the travel time of the S-wave between the two neighbouring sensors [33]. Furthermore, for a larger network with a considerable number of sensors, it should be noted that the processing time of the algorithm with the centralised processing approach can only be reduced by improving the processing power of the centralised server, which will eventually raise the cost of the centralised architecture. On the other hand, the cost of the decentralised EEW architectures is becoming more affordable because MEMS-based sensors are getting cheaper, while their processing power is increasing rapidly.

Regarding system latencies, the above discussion clearly shows that the implementation of the TCP-based decentralised processing architecture outperforms other centralised processing architectures implemented around the world.

In addition, redundancy should be considered in case of a failure in the EEW network architecture. In our approach, the redundancy is mainly dependent on the density of the sensors in a 30 km radius area, since we are processing the algorithm at the sensor node. Therefore, the failure of a single or multiple sensors may not cause any major network failure since the remaining sensors in a particular area will continue to process the data and detect earthquakes. On the contrary, in the centralised processing approach, failure to connect to the centralised server or failure of the centralised server itself will collapse the functionality of the entire network, and lead to failure to detect an earthquake. The EEW sensor network architecture proposed in this paper is less prone to failures compared to an architecture driven by centralised processing.

In addition to that, most of the EEW approaches found in the previous literature were implemented using the MQTT-based centralised processing. It is proven that the TCP-based centralised processing outperforms the MQTT-based centralised processing approach. Even though implementing a TCP-based centralised processing architecture requires the inclusion of a software-defined network at the node-level to identify the sensors uniquely, we can propose TCP as a better choice when reducing the system latency of the network, compared to MQTT, for a centralised EEW network.

Furthermore, in this research, we investigated the potential security-related risks and identified the potential security breaches that can be anticipated in the proposed type of community-engaged EEW sensor network environment. To mitigate the identified vulnerabilities, we implemented appropriate measures to secure the proposed EEW sensor network, which runs on the ZeroTier SD-WAN platform. At present, there is hardly any EEW literature that addresses potential security risks or provides solutions to mitigate such risks.

In addition to the above factors, the proposed architecture can be easily scaled, implemented, and exported to develop a sensor network by simply provisioning low-cost sensors, installing them in people’s homes, and implementing decentralised processing at the node-level. Six of the selected hypothetical earthquake scenarios were triggered by S-waves. The scenarios suggest that a low-cost, MEMS-based, decentralised processing network could achieve the fastest theoretical EEW performance compared with the other centralised EEW networks, especially with the anticipated futuristic improvements in low-cost sensors and processing algorithms. These types of low-cost sensors could also support the implementation of hybrid networks with the aim of enhancing and complementing existing EEW networks consisting of expensive Class A type seismographs. Our approach to ground-motion detection with an appropriate alerting mechanism has demonstrated an effective EEW solution, where alerts may arrive early, allowing the system end-users to carry out simple protective actions, such as drop-cover and hold.

Limitations and Future Work

While this paper provided evidence that an EEW system can be implemented using MEMS-based, low-cost sensors without any centralised processing, we identified several limitations that need further investigation. The inherent limitations of the PLUM approach constrain our proposed EEW system. While the PLUM algorithm is considered a more robust approach to detect seismic intensity, it limits the warning time to a maximum of ~10 s. Regarding the further use of S-Wave to detect the intensity of shaking, PLUM approach makes it unsuitable for providing a meaningful warning to the areas near the epicentre. To minimise the inherent limitations of the PLUM algorithm in the next phase of our research, we intend to investigate the feasibility of predicting the S-wave shaking intensities using the P-waves, which can eventually considerably increase the warning time. Additionally, we are looking into different algorithms, which could predict the shaking intensity beyond the 30-km radius defined by the PLUM algorithm. Further, our team is exploring the opportunities to implement a community-engaged sensor network comprising different types of low-cost sensors, rather than using a single type of sensor. The successful implementation of an EEW network with multiple sensor types will result in an eco-system of community-engaged, MEMS-based, EEW sensor networks.

As described in Section 4.1.1, even though we have conducted a preliminary testing of the performance of the embedded additional measures to enhance the security of the proposed MEMS-based, decentralised sensor network, to provide a more accurate judgment, security enhancements must be tested when exposed to real-world threats when operating under real-world scenarios. We intend to carry out such an in-depth testing of the implemented security enhancements as one of the future activities in the ongoing research. Furthermore, we intend to develop a centralised alert service that could detect and notify users of security breaches in the sensor network and is capable of automating actions upon the suspicious activity (e.g., automatically disconnecting the breached and vulnerable sensors from the network). This feature will automatically remove the vulnerable sensor nodes from the network, which will eventually increase the security of the network.

6. Conclusions

We have demonstrated that the PLUM-based EEW algorithm can be implemented using a network of low-cost, MEMS-based sensors, providing accurate operational EEW at a lower cost compared with scientific-grade seismographs. Furthermore, we investigated the overall system latency of the proposed EEW system and its components in the proposed network. From the outcomes of the transmission delay, along with different standard communication protocols, we can confirm that the use of TCP as a communication protocol running on an appropriate SD-WAN solution can reduce the transmission delay, regardless of the type of processing architecture (centralised or decentralised). In terms of the detection time, by introducing the decentralised processing architecture, we showed that our results outperform the commonly implemented centralised processing architectures. It should be noted that the detection time of our proposed decentralised processing network does not vary with the number of sensors in the network. Thus, it should show approximately the same results as the nationwide EEW system; however, when it comes to the centralised processing, the algorithm’s detection time tends to increase with the number of sensors. Furthermore, the packet loss in the decentralised processing architecture is negligible compared to the centralised architecture.

In this paper, we investigated the feasibility of implementing an EEW network that processes the detection algorithm at node-level rather than in a centralised processor. We also presented a step-by-step guide to building an EEW network with low-cost, MEMS-based sensors. This research provides clear evidence to confirm that the proposed type of EEW system can successfully be implemented by choosing the appropriate detection sensors and algorithms. Therefore, this paper can be considered as providing a comprehensive guide to construct an EEW sensor network with decentralised processing and can be used as a benchmark, which is beneficial in building similar networks in the future. Furthermore, the proposed concept of a decentralised, low-cost sensor network architecture can be used to implement community-engaged warning applications in the other disaster domains, such as developing low-cost warnings for bushfires.