Applied Science, Faculty of
Electrical and Computer Engineering, Department of
DSpace
UBCV
Daiss, Ivelina
Master of Applied Science - MASc
University of British Columbia
Earthquakes are unpredictable, unpreventable natural events that cause extensive damage to the impacted area’s infrastructure and inhabitants. Early warning systems are humanity’s way of having some prior knowledge of the onset of earthquakes. Historically, Earthquake Early Warning (EEW) systems have been implemented, but have shown limited success in providing accurate, adequate, and meaningful information to help societies mitigate what is happening. A new approach to EEW is proposed in the Earthquake Early Warning in Smart Cities (EEW-SC) that utilizes modern technologies like 5th generation wireless access telecommunications networks and the Internet of Things (IoT) to achieve much improved seismic behaviour prediction and apply the learned toward next-gen mitigation and prevention strategies for urbanized and industrialized smart cities' protection. The outlined research covers the development of an advanced Dense Network of IoT Sensors (DeNIS) for seismic data collection in real-time and a novel mechanism for data acquisition, data transfer and Asynchronous Sensor Coordination (ASC). A detailed examination of 4th and 5th generation cellular technologies brought much needed understanding into the behaviour of an EEW system operated on a public telecommunications network. The learnings and developments in this work will be further incorporated with the soon-to-be developed and deployed in British Columbia EEW-SC.
Dense Network of Sensors Applied to Earthquake EarlyWarning in Smart CitiesbyIvelina DaissB. Applied Science, University of British Columbia, 2019A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFMaster of Applied ScienceinTHE FACULTY OF GRADUATE AND POSTDOCTORALSTUDIES(Electrical and Computer Engineering)The University of British Columbia(Vancouver)August 2023© Ivelina Daiss, 2023The following individuals certify that they have read, and recommend to the Fac-ulty of Graduate and Postdoctoral Studies for acceptance, the thesis entitled:Dense Network of Sensors Applied to Earthquake Early Warning inSmart Citiessubmitted by Ivelina Daiss in partial fulfillment of the requirements for the degreeof Master of Applied Science in Electrical and Computer Engineering.Examining Committee:Jose´ Martı´, Electrical and Computer EngineeringSupervisorCarlos Ventura, Structural and Earthquake EngineeringSupervisory Committee MemberShahriar Mirabbasi, Electrical and Computer EngineeringSupervisory Committee MemberiiAbstractEarthquakes are unpredictable, unpreventable natural events that cause extensivedamage to the impacted area’s infrastructure and inhabitants. Early warning sys-tems are humanity’s way of having some prior knowledge of the onset of earth-quakes. Historically, Earthquake Early Warning (EEW) systems have been imple-mented, but have shown limited success in providing accurate, adequate, and mean-ingful information to help societies mitigate what is happening. A new approachto EEW is proposed in the Earthquake Early Warning in Smart Cities (EEW-SC)that utilizes modern technologies like 5th generation wireless access telecommu-nications networks and Internet of Things (IoT) to achieve much improved seismicbehaviour prediction and apply the learned toward next-gen mitigation and pre-vention strategies for urbanized and industrialized smart cities’ protection. Theoutlined research covers the development of an advanced Dense Network of IoTSensors (DeNIS) for seismic data collection in real-time and a novel mechanismfor data acquisition, data transfer and Asynchronous Sensor Coordination (ASC).A detailed examination of 4th and 5th generation cellular technologies broughtmuch needed understanding into the behaviour of an EEW system operated on apublic telecommunications network. The learnings and developments in this workwill be further incorporated with the soon-to-be developed and deployed in BritishColumbia EEW-SC.iiiLay SummaryEarthquakes are natural calamities causing extensive damage to city’s infrastruc-ture and inhabitants. Earthquake Early Warning (EEW) systems give humanitysome knowledge about the onset of earthquakes. Current systems have shownlimited success in providing accurate prediction and meaningful information tomitigate earthquake impact. Proposed is the Earthquake Early Warning in SmartCities (EEW-SC) application that uses modern technologies to achieve a muchimproved earthquake prediction that smart cities can apply toward prevention ac-tions. This research covers the development of an advanced Dense Network ofIoT Sensors (DeNIS) to collect seismic data and a novel mechanism for Asyn-chronous Sensor Coordination (ASC). The network of sensors operates on publictelecommunications networks and examination of cellular technologies was doneto understand the behaviour of an EEW system operated on a cellular network. Theproven contributions in this work will be applied to the EEW-SC system developedfor British Columbia.ivPrefaceThe research work and findings in this thesis are to the best of my knowledge origi-nal and unpiblished. Exceptions make contents of the conference papers publishedon the topic. Dr. Jose´ Martı´ has been the sole supervisor of all work on the topic.The research work and findings in chapters 4, 5, 6 have been accepted in:1. Daiss, I., Martı´, J.R., Chhabra, A., Andjelic, D., Ventura, C.E., Martı´, A.T.J.(2023). “Coordinated Network of Sensors over 5G for High-Resolution Pro-tection of City Assets during Earthquakes”. Lecture Notes in Networks andSystems, Springer 20232. Martı´, A.T.J., Daiss, I., Martı´, J.R., Ventura, C.E., Chhabra, A., Andjelic,D. (2023). ”A Dense Network of Economical Seismic Sensors over 5GTelecommunications Network for Earthquake Rapid Damage Assessmentand Response after an Earthquake”. Canadian Conference - Pacific Con-ference on Earthquake Engineering 2023vTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiLay Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvAcknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xixDedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Research Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Earthquake Early Warning So Far . . . . . . . . . . . . . . . . . 31.3 Technologies Applicable to EEW . . . . . . . . . . . . . . . . . . 51.4 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Research Contributions . . . . . . . . . . . . . . . . . . . . . . . 61.6 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6vi2 Earthquake Early Warning and the Earthquake Early Warning inSmart Cities Application . . . . . . . . . . . . . . . . . . . . . . . . 82.1 Earthquake Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.1 Relevant Terms . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Soil Conditions and Seismic Waves . . . . . . . . . . . . 92.1.3 Observation-based Seismology and Strong Motion Analysis 102.2 The Earthquake Early Warning System . . . . . . . . . . . . . . . 122.2.1 Earthquake Early Warning . . . . . . . . . . . . . . . . . 122.2.2 Approaches to EEW . . . . . . . . . . . . . . . . . . . . 132.3 Currently Operational EEW Systems . . . . . . . . . . . . . . . . 162.3.1 JMA EEW, Japan . . . . . . . . . . . . . . . . . . . . . . 162.3.2 SASMEX EEW, Mexico . . . . . . . . . . . . . . . . . . 172.3.3 CISN ShakeAlert EEW, California, Oregon, Washington . 182.4 Automated Actions . . . . . . . . . . . . . . . . . . . . . . . . . 182.5 Performance-based EEW . . . . . . . . . . . . . . . . . . . . . . 202.6 Vancouver, a Unique Earthquake-prone Area . . . . . . . . . . . 212.7 The Developed EEW-SC Application . . . . . . . . . . . . . . . 232.7.1 Goals of the Application . . . . . . . . . . . . . . . . . . 242.7.2 Top-view Architecture . . . . . . . . . . . . . . . . . . . 242.7.3 Components . . . . . . . . . . . . . . . . . . . . . . . . 253 Internet of Things and Its Potential Application to EEW . . . . . . . 273.1 The Internet of Things . . . . . . . . . . . . . . . . . . . . . . . 273.1.1 Concept and Definition . . . . . . . . . . . . . . . . . . . 273.1.2 The IoT Device/Thing . . . . . . . . . . . . . . . . . . . 283.1.3 The IoT Communication Network . . . . . . . . . . . . . 323.1.4 Types of Communication Between IoT Nodes . . . . . . . 373.1.5 The IoT Application . . . . . . . . . . . . . . . . . . . . 393.2 Relevant IoT Areas and Applications . . . . . . . . . . . . . . . . 403.2.1 Time-Critical IoT . . . . . . . . . . . . . . . . . . . . . . 413.2.2 IoT Applied to Environmental Monitoring and Disaster Man-agement . . . . . . . . . . . . . . . . . . . . . . . . . . . 41vii3.2.3 IoT-inspired Earthquake Early Warning and Seismic Sen-sor Networks . . . . . . . . . . . . . . . . . . . . . . . . 424 Setup of the Proposed Solution . . . . . . . . . . . . . . . . . . . . . 464.1 Requirements on Data Collection and Pre-processing . . . . . . . 464.2 Proposed Solution for Data Collection and Pre-processing . . . . 474.2.1 Physical Deployment of DeNIS . . . . . . . . . . . . . . 474.2.2 Physical Deployment of Data Collecting and Pre-processingServers . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.3 The EEW-SC IoT Access Communication Network . . . . 484.2.4 Data Collection and Pre-processing Mechanism . . . . . . 534.3 Effect of Latency on Data Collection . . . . . . . . . . . . . . . . 564.3.1 Network Performance-related Terms . . . . . . . . . . . . 574.3.2 Performance Testing Methodology . . . . . . . . . . . . . 574.3.3 Conclusions on Network Performance . . . . . . . . . . . 614.4 A DeNIS/ EEW-SC Sensor Node . . . . . . . . . . . . . . . . . . 644.4.1 Sensing Unit . . . . . . . . . . . . . . . . . . . . . . . . 654.4.2 Processing Unit . . . . . . . . . . . . . . . . . . . . . . . 654.4.3 Communication Unit . . . . . . . . . . . . . . . . . . . . 664.5 Data Collection and Pre-processing System Operation . . . . . . . 664.5.1 Steady State Operation . . . . . . . . . . . . . . . . . . . 664.5.2 Operation During the Seismic Event . . . . . . . . . . . . 674.5.3 Asynchronous Sensor Coordination . . . . . . . . . . . . 714.5.4 Sample Time Estimation . . . . . . . . . . . . . . . . . . 735 Validation of the Proposed Solution . . . . . . . . . . . . . . . . . . 765.1 Testing Environment . . . . . . . . . . . . . . . . . . . . . . . . 765.1.1 Simulating Wireless Network Behaviour . . . . . . . . . . 775.1.2 Reference Parameters and Values . . . . . . . . . . . . . 795.1.3 Clock Offset . . . . . . . . . . . . . . . . . . . . . . . . 805.2 Testing Methodology . . . . . . . . . . . . . . . . . . . . . . . . 815.2.1 Data Collection Tests . . . . . . . . . . . . . . . . . . . . 825.2.2 ASC Accuracy and Validating Factor K . . . . . . . . . . 83viii5.2.3 Conclusions on Factor K . . . . . . . . . . . . . . . . . . 845.2.4 ASC Consistency . . . . . . . . . . . . . . . . . . . . . . 855.3 Results and Sources of Error . . . . . . . . . . . . . . . . . . . . 865.3.1 Sources of Error . . . . . . . . . . . . . . . . . . . . . . 865.3.2 Relative Error . . . . . . . . . . . . . . . . . . . . . . . . 885.3.3 Results and Conclusions on Validation . . . . . . . . . . . 896 In-field Testing and Discussion of Results . . . . . . . . . . . . . . . 916.1 In-field Test Scenario . . . . . . . . . . . . . . . . . . . . . . . . 916.1.1 Site Selection . . . . . . . . . . . . . . . . . . . . . . . . 916.1.2 Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . 936.1.3 In-field Testing Methodology . . . . . . . . . . . . . . . 946.2 Comparison of Reference Waves with Waves Captured by In-fieldMSe Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.3 Tracing the Reference Wave with Multiple Devices . . . . . . . . 986.3.1 Tracing with MSe Stations on Different Technologies . . . 1016.3.2 Distance between MSe Stations and its Relationship to Ac-curacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.4 ASC Performance Compared to NTP . . . . . . . . . . . . . . . . 1056.5 Network Quality of Service Guarantees to Improve Performance . 1066.5.1 Regular Network Traffic Impacts Performance . . . . . . 1066.5.2 Quality of Service Guarantees for Public Safety Networks 1096.5.3 QoS Guarantees and Network Slicing to Improve EEW-SCPerformance . . . . . . . . . . . . . . . . . . . . . . . . 1097 Conclusions and Future System Development . . . . . . . . . . . . . 1127.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127.2 Future DeNIS Development . . . . . . . . . . . . . . . . . . . . 1157.3 Future EEW-SC Development . . . . . . . . . . . . . . . . . . . 116Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118A Supporting Materials . . . . . . . . . . . . . . . . . . . . . . . . . . 124ixList of TablesTable 2.1 Implemented Automated Response to EEW System Notification 20Table 4.1 Evaluated Wireless Access Technologies . . . . . . . . . . . . 58Table 4.2 Earthquake Wave Frequencies and Sampling Frequencies. Tocapture each frequency in the range of frequencies most dam-aging to structures and reconstruct it with an error below 3%,EEW-SC must instruct MSe stations to sample with a corre-sponding sampling frequency. . . . . . . . . . . . . . . . . . . 62Table 5.1 NetEm Distributions for LTE . . . . . . . . . . . . . . . . . . 79Table 5.2 Estimation Error on FR1 with Factor K ranging from 0.3 to 0.7.Columns 1 and 2 show the asymmetry in latency applied withNetEm, column 3 shows factor K value and column 4 indicatesthe estimation error produced with these variables. . . . . . . . 84Table 5.3 Estimation Error on LTE, FR1 and FR2 with Factor K = 0.5.The error is bouned regardless of the technology or the latencyasymmetry introduced with NetEm. . . . . . . . . . . . . . . . 85Table 6.1 Tested Fundamental Frequencies and Associated Sampling Rates 95Table 6.2 Distances between MSe stations and Corresponding Delays inSampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Table 6.3 Average Timestamp Error [ms]. Frequency Component vs Cel-lular Technology . . . . . . . . . . . . . . . . . . . . . . . . 97xTable A.1 Modified Mercalli Intesity Scale Compared to Magnitude andPGA from [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 125xiList of FiguresFigure 2.1 Seismology Terms from [2]. The fault is the rupture of the rockbelow the surface during an earthquake. The location of thefault is the hypocentre of the earthquake. The nearest locationon the surface is the earthquake’s epicentre. . . . . . . . . . . 9Figure 2.2 Sources of Earthquakes near Vancouver from [3]. The area isprone to subduction, crustal and subcrustal earthquakes. Theyexhibit unique behaviour and have unique consequences. . . . 22Figure 3.1 The IoT System. IoT devices collect data from assets. Datapasses through a communication channel to the application.The application analyzes the data, applies control to assets, oroffers the results to users. . . . . . . . . . . . . . . . . . . . . 29Figure 3.2 The IoT Thing comprised of Sensing/Actuation, Processingand Communication units. . . . . . . . . . . . . . . . . . . . 30Figure 3.3 The Internet Engineering Task Force Communication Model[4] giving foundation to the IoT communication system model. 33Figure 4.1 The EEW-SC IoT Network. IoT Access Network is mainlywireless and IoT Core Network is wireline, with fibre opticcable as the primary medium. . . . . . . . . . . . . . . . . . 49Figure 4.2 The EEW-SC Communication Protocol Stack based on IETFstack. Layers 1 through 3 provided by an IP-based cellularnetwork. Layers 4 and 5 selected for minimum delay. . . . . . 50Figure 4.3 Latency Test System . . . . . . . . . . . . . . . . . . . . . . 59xiiFigure 4.4 The EEW-SC Sensor Node, consisting of ADXL355 accelerom-eter, Raspberry Pi 4 and a wireless communication module . . 66Figure 4.5 Beginning of Earthquake Event. The EEW agent initializesthe Request Engine to prepare all sector MSe stations for datacollection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Figure 4.6 Data Collection during a Seismic Event. Request Engine per-forms repeated scheduled requests for samples to all devices.Each iteration of requests and responses, including pre-processingof the received samples fit within one processing window. . . 72Figure 4.7 End of Earthquake Event. The EEW agent instructs the Re-quest Engine to discontinue data collection before it shuts down. 73Figure 4.8 A single ASC Request/Response exchange. The EEW agentrecords request and receipt of response on universal time. . . . 74Figure 5.1 EEW-SC Virtual Testing Environment. 15 virtual EEW de-vices are hosted on the UBC server. The EEW agent and theResource Directory are hosted on Rogers MEC. . . . . . . . . 77Figure 5.2 TPSN Message Exchange for Clock Offset Calculation . . . . 80Figure 5.3 A single instance of an ASC Request/Response in the virtualvalidation environment. The EEW agent and the virtual EEWdevice are both on universal time. The times recorded on thedevice are used to validate the agent’s estimates. . . . . . . . 81Figure 5.4 Estimated Sample Timestamps of Two colocated Devices. Thesamples are generated by devices at the same location, detect-ing the same earthquake wave. ASC accurately estimates thesame timestamps for the samples from both devices. . . . . . 86Figure 5.5 Estimated Sample Timestamps of Two Devices Spaced Apart.The samples are generated by device 1 at t = 0 location, device2 detects the same point of the earthquake wave at t = 300 ms.ASC accurately estimates the timestamps for the samples fromboth devices with 300 ms difference. . . . . . . . . . . . . . . 87xiiiFigure 6.1 EEW-SC Three-device In-field Testing Scenario. MSes at eachof the three locations forming a triangle. Rogers LTE and FR1coverage is available across the UBC campus. FR2 coverageis available at the three MSe locations. . . . . . . . . . . . . . 92Figure 6.2 Reference and Captured Waves Compared. . . . . . . . . . . 98Figure 6.3 Reference Wave Captured with Three Cellular Technologies.An example of the same reference wave captured with LTE,FR1, and FR2. The wave estimated on LTE is experiencing atemporary error in estimation. . . . . . . . . . . . . . . . . . 99Figure 6.4 1 Hz Wave Captured by MSes at locations 2 and 3, 600 m aparton FR1. The MSe at location 2 detects the wave first and 0.12seconds later, the MSe station at location 3 detects the wave. . 100Figure 6.5 20 Hz Wave Captured by MSe stations at locations 2 and 3,600 m apart on LTE. . . . . . . . . . . . . . . . . . . . . . . 100Figure 6.6 20 Hz Wave Captured by MSe stations at locations 1 and 3,1600 m apart on FR2. . . . . . . . . . . . . . . . . . . . . . . 101Figure 6.7 1 Hz Wave Captured by MSes at locations 1 and 3, 1600 mapart. The MSe at location 1 transmits on LTE, and the MSeat location 3 transmits on FR2. . . . . . . . . . . . . . . . . . 102Figure 6.8 20 Hz Wave Captured by MSes at locations 1 and 3, 1600 mapart. The MSe at location 1 transmits on FR2, and the MSe atlocation 3 transmits on LTE. . . . . . . . . . . . . . . . . . . 103Figure 6.9 MSe Stations 600 m apart Tracing a 1 Hz Wave . . . . . . . . 104Figure 6.10 MSe Stations 1100 m apart Tracing a 1 Hz Wave . . . . . . . 104Figure 6.11 MSe Stations 1600 m apart Tracing a 1 Hz Wave . . . . . . . 105Figure 6.12 ASC estimated, and NTP recorded 20 Hz waves comparedwith 20 Hz reference. NTP gives the incorrect times for someof the samples until the device re-synchronizes time with theserver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Figure 6.13 Comparison between the round trip times the packets experi-ence when there are enough resources and when resources areshared. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110xivGlossaryAI Artificial IntelligenceAMQP Advanced Message Queuing ProtocolAPIs Application Program InterfacesASC Asynchronous Sensor CoordinationCISN California Integrated Seismic NetworkCoAP Constrained Application ProtocolDDS Data Distributed Services for real-time systemsDeNIS Dense Network of IoT SensorsDSL Digital Subscriber LineDTLS Datagram Transport Layer SecurityE2E End-to-End delayEEW Earthquake Early WarningEEW-SC Earthquake Early Warning in Smart CitiesEMTP Electromagnetic Transients ProgramGMMs Ground Motion ModelsGMPEs Ground Motion Prediction EquationsGNSS Global navigation satellite systemGPS Global Positioning SystemsGSM Global System for Mobile CommunicationsxvHTTP Hypertext Transfer ProtocolIETF Internet Engineering Task ForceIoT Internet of ThingsIP Internet ProtocolJMA Japanese Meteorological AgencyLAN Local Area NetworkLPWAN Low Power Wide Area NetworkLTE Long Term EvolutionM2M Machine-to-machine referring to machine-to-machine communicationMEC Multi-access Edge ComputingMEMS Microelectromechanical SystemsML Machine LearningMMI Modified Mercalli IntensityMQTT Message Queue Telemetry TransportMSe Mini-seismic StationNRCan National Resources CanadaNTP Network Time ProtocolOLSR Optimized Link State RoutingOPEN Ongoing Processing Estimation and NotificationOS Operating SystemPAN Personal Area NetworkPEF Post-earthquake FirePGA Peak Ground AccelerationQCN Quake-Catcher NetworkQoS Quality of ServiceREST Representational State TransferxviRTT Round-trip timeSASMEX Seismic Alert Systems of MexicoSBC Single Board ComputerSN Sensor NetworkSOA Service-Oriented ArchitectureSoC System on ChipSOSEWIN Self-organizing Seismic Early Warning Information NetworkSP Smart PhoneTCP Transmission Control ProtocolTLS Transport Layer SecurityTPSN Timesync Protocol for Sensor NetworksUDP User Datagram ProtocolUSB Universal Serial BusVM virtual machineWAN Wide Area NetworkXMPP Extensible Messaging and Presence ProtocolxviiAcknowledgmentsI would like to humbly thank Dr. Martı´. To say that he is a great man would benothing short of an understatement. A great man, if I may borrow a thought fromRobert Ingersoll, does not seek applause or place but the truth and what he ascer-tains, he gives to others. And Dr. Martı´ has given me so much.I would also like to express my appreciation for Dragan Andjelic, our dearGuardian Angel. His work ethic is impressive, his demeanour is gracious andgraceful, his remarks are insightful. He is always to the point when he insists that”someone has to do the work”. His support was instrumental to this research.Even after all these years, I seem to be unable to leave the i2SIM lab and forthat I can only blame the i2SIM team, Andrea Martı´, and Dr. Carlos Ventura. Theirdeep passion for the next drop of knowledge tugs my heart’s strings as well. Thebaton now passes to Andy to continue this important research into earthquake earlywarning.The partnership and innovation team at Rogers Communications, AmitabhChhabra and Jade Salazaar are much appreciated and their efforts acknowledged.You always saw my challenges as ”ours” and didn’t hesitate to help.I also extend gratitude to my friends who went out of their way to make theload lighter and my life a happy one.xviiiDedicationI dedicate this thesis to Chris and to my mother, Deanna, who have been my great-est supporters since this journey began 9 years ago. For ”the blood of the covenantis thicker than the water of the womb”.xixChapter 1Introduction1.1 Research MotivationEarthquakes are natural hazards that result from contact and friction between Earth’stectonic plates [1]. Earthquakes’ status is upgraded to disasters beyond a certainmagnitude and when they strike populated areas. Their arrival often causes devas-tation to infrastructure, resources and human life [5].Humanity has not found a way of preventing, predicting or reducing the mag-nitude of seismic events. Instead, societies attempt to reduce the impact of theseevents by detecting their onset and having adequate reactive measures in place.As humanity’s resources lessen and living environments become smarter throughincreased dependence on Internet-aided technology and automation, the conse-quences of earthquakes amplify. Developing smart cities, with populations in themillions, highly automated infrastructure and high-speed communication systemsare particularly vulnerable [6]. Frequently located on the coast, these urban envi-ronments are positioned in areas prone to high seismicity. Their size and infrastruc-tural complexity translate into high death tolls and costly infrastructural damagesafter a large seismic event. For such cities, a great emphasis must be placed onreducing the impact of earthquakes through early, accurate, useful knowledge ofimpending seismic activity. An Earthquake Early Warning (EEW) system’s pur-1pose is to provide such knowledge and facilitate reactive measures [5], [7], [8].Vancouver, British Columbia, is a developing smart city. Vancouver and MetroVancouver area is growing in population, city infrastructure is becoming increas-ingly automated, the autonomous train system is expanding, the electrical powersystems are computerized, and the communication systems are currently being up-graded to include 5G coverage [9], [10], [11], [12].Vancouver is located near the Cascadia Subduction zone extending from Cal-ifornia to Alaska, an area prone to strong earthquakes [13]. According to NaturalResources Canada, in the past year, there have been over 300 local seismic events[14]. The area is home to multiple types of earthquakes, and at the same time thelandscape is geologically diverse. These characteristics are complex and coupledwith the inherent difficulty in estimating ground motion, challenge the effective-ness of current EEW approaches.The deployed EEW system on Vancouver Island [15], [13] operates similarlyto most existing EEW systems. These systems have had partial success in reduc-ing the gravity of seismic events [8], [7], [16]. Current research concentrates onnew approaches to upgrade EEW efficacy [5] in view of infrastructural and societalchanges. However, for policy makers, the incentive to apply these upgrades comesafter a devastating event [17], [18]. In foresight, the province of British Columbiamust take steps to revise and upgrade the current state of EEW in the area.Motivated by the early warning needs of Vancouver and the area, we are propos-ing a next-generation, performance-based, auto-response enabling EEW applica-tion, the Earthquake Early Warning in Smart Cities (EEW-SC). EEW-SC will in-corporate the three stages of EEW, data collection, event estimation and notifica-tion, to generate a high-accuracy, high-resolution prediction of earthquake impact.The application will communicate the magnitude of ground shaking in a mannerthat will maximize warning time. It will assess damage to individual assets in thecity, and it will allow for automated actions that minimize the adverse effects ontocritical infrastructure. Chapter 2 details the science and status of earthquake early2warning around the world, and outlines the vision and goals of EEW-SC.The success of the EEW-SC application will be directly dependent on efficientseismic data collection. Collecting data in real-time from a large number of datasources, with emphasis on accuracy under tight timing constraints is a challengingtask. We are looking to recent technological trends in wireless communication, theInternet of Things (IoT) and sensor networks with the potential to fulfill the afore-mentioned requirements and advance the EEW-SC application.To our knowledge, there are no deployed EEW systems that apply IoT to theirpurpose. The few examples found in section 3.2, although introducing forwardideas and applying new technologies to EEW, are only theoretical or in initial de-velopment.This work sets in motion the development of the EEW-SC application, andfocuses on finding an IoT-inspired solution for wireless data collection in a sys-tematized, synchronized manner from thousands of seismic sensors. It will outlinethe design of a sensor network, including architecture, sensor coordination andwireless data collection during a seismic event for a dense network of IoT sensorsthat fulfils the requirements of the EEW-SC application.1.2 Earthquake Early Warning So FarEarthquake Early Warning consists of three stages: data collection, event estima-tion and notification dissemination. EEW systems collect seismic data which isprocessed for event estimation, and should the results indicate a severe enoughevent, a notification is sent out through authorized channels. There are 9 oper-ational and 13 in-test EEW systems around the world [5] and we highlight thefront-runners in section 2.3.Traditionally, predicting earthquake magnitude and the affected area is basedon a few seconds of seismic readings collected at the onset of the event [19]. A3handful of stations located where the shaking is likely to begin are the only sourceof data while the area they service spans hundreds of kilometres. Event estima-tion algorithms must assume what the area is, and will behave alike [5]. In manyinstances their predictions do not apply well to the area beyond the stations’ loca-tion. Prediction accuracy is also impacted by imprecise probabilistic relationshipsbetween earthquake onset and earthquake progress built from limited historical ob-servations [18], [7].In existing EEW systems, a notification is transmitted only when it is predictedthat the seismic intensity will reach a set threshold. Notification to the general pub-lic, the well-known duck-and-cover alarms, is the most frequently issued warning,and prediction accuracy is of little consequence [5]. A limited number of industrialand critical systems get notified, and notifications impact only a few low-stakesautomated decisions [5], [7], [18], [20]. Applied EEW doesn’t yet account forthe varied reaction to ground shaking of diverse city infrastructure. Performance-based prediction goes beyond ground motion and considers the resulting structuralresponse and damage. The warning times, typically in the seconds are further re-duced by communication latency and slow transmissions [19], [21], [20].In recent years, research in early warning has examined the possibility of im-proving ground motion predictions by including more than a few seconds of dataat the onset. Real-time or near-real-time seismic data serves to refresh secondaryor tertiary estimates during the event. Going further, new approaches all-togetherabandon the statistical convention in favour of predictions based only on real-timedata and apply wave or energy propagation theories [22], [23], [24], [25]. In ad-dition, reliance on faster communication and data from sources distributed alongthe path of the earthquake has caused prediction accuracy, together with warningtimes, to increase [5], [26]. Improved system performance could enable a fine-tuned, specialized prediction and notification that goes beyond general alerts.41.3 Technologies Applicable to EEWThe past two decades have seen wireless communications propel to the anywhere,anytime cellular and Internet network access medium. The fourth generation, 4G,cellular networks have realized more cellphone subscriptions than people on theplanet [27], and the fifth generation, 5G, has the potential to enhance the functionsof every industry [28]. With 4G as the backbone, 5G will extend network capabil-ities to reach the most reliable, high-speed wireless communication.The IoT, defined as a network of objects connected over the Internet to providesome type of observation in the physical environment [29], has advanced to uses inalmost every industry, business and economy. Now, the word smart, as in clever,applies to anything that uses technology and automation enhanced by Internet con-nectivity. IoT in its core specifies fast, accurate data collection and data analysisfrom thousands and tens of thousands of devices and is a promising option for seis-mic data collection for the EEW-SC application.Sensors with embedded Microelectromechanical Systems (MEMS), organizedin networks are the archetypical realization of data sources for the IoT. They cangather large quantities of detailed data from any location and offer incredible datadiversity at low cost and low power absorbtion. IoT sensor networks are alreadyextensively applied to many domains, from Smart Environments to industrial pro-cesses and monitoring, and are rapidly being adopted by others, including con-sumer wearables.1.4 Research ObjectivesOn our journey to create an IoT-inspired solution to data collection, we set theintention to investigate and answer the following questions:1. Can we provide a viable IoT solution to seismic data collection and pre-processing for the time-critical EEW-SC application? How is the sensor net-work to be organized and how is data to be collected during an earthquake5event? We investigate approaches to IoT design, not only from data collec-tion perspective, but keeping in mind the needs of the entire application.2. How do different wireless network access technologies impact the perfor-mance of EEW-SC? Time-critical applications are highly dependent on theunderlying medium and its behaviour should be understood and taken intoaccount in application design. This project was sponsored by Rogers Com-munications Inc. and the network is used to facilitate communication in theapplication. The Rogers network offers a number of possible network routeswith different characteristics we examined.3. Clock synchronization is performed in distributed systems to maintain com-mon time. Acknowledging the size of the data collection network the EEW-SCapplication would need, the limitation of cheap devices in accurate time-keeping, and the unpredictability of earthquake events, can we develop amethod for coordinated data acquisition that maintains synchronicity amongmeasurements but doesn’t require data sources to be synchronized?1.5 Research ContributionsOur research contributions, discussed in detail in the following pages, contain:1. An IoT solution for seismic data collection and pre-processing in the DenseNetwork of IoT Sensors (DeNIS).2. A detailed investigation of how 4G and 5G impact application performance.3. An Asynchronous Sensor Coordination Scheme that uses one universal clockwithout the need for time synchronization across the IoT sensor network.1.6 Thesis OutlineThe remainder of the thesis has the following structure:6Chapter 2: Earthquake Early Warning and The EEW-SC Application. In thischapter we will summarize what are considered traditional and non-traditional ap-proaches to earthquake early warning, discuss up-to-date EEW implementationsand deployments and describe in more detail our proposed EEW-SC application.Chapter 3: The IoT and Its Potential Application to EEW. This chapter willdescribe, firstly, the IoT concept and design, the IoT sensor node, and IoT commu-nication. Secondly, it will examine IoT implementation to environmental domainsand time-critical domains, and lastly, will outline EEW applications, characterizedas IoT-inspired, that use new technologies .Chapter 4: Setup of the Proposed Solution. In this chapter we will define ourproposed solution for the Dense Network of IoT Sensors (DeNIS). We will discussthe performance of the underlying medium and our approach to data collection.Chapter 5: Verification of the Proposed Solution. Following the proposed solu-tion is an experimental verification and justification of our design decisions in ourvirtual environment, including discussion of sources of error.Chapter 6: In-field Testing and Discussion of Results. In this chapter we dis-close the procedure for our in-field validation of our proposed solution, includingour three-device testing scenario, the results and conclusions of the in-field tests.7Chapter 2Earthquake Early Warning andthe Earthquake Early Warning inSmart Cities ApplicationThis chapter presents basic earthquake physics and the principles behind eventdetection and evaluation. We describe earthquake early warning systems and ap-proaches. We further give an overview of the current status of deployed EEW sys-tems worldwide and discuss their performance. The chapter ends with an overviewof the EEW-SC application, its goals, intentions, and overall system organization.2.1 Earthquake Basics2.1.1 Relevant TermsAt the boundaries between tectonic plates, friction causes shear stress to build up inthe rock. When the rock fails, massive energy is translated into a seismic eruption.The rock breaking and slipping creates a rupture, or a fault, sometimes extendinghundreds or thousands of kilometres. The earthquake’s hypocentre, or focus, is theestimated location below the surface where the rock ruptures. The nearest area onthe ground’s surface from the hypocentre is known as the epicentre [1]. Figure 2.18Figure 2.1: Seismology Terms from [2]. The fault is the rupture of the rockbelow the surface during an earthquake. The location of the fault is thehypocentre of the earthquake. The nearest location on the surface is theearthquake’s epicentre.depicts the locations of hypocetre, epicentre and fault plane.Seismic waves travel isotropically from the hypocentre through the interior ofthe earth as body waves. The Primary waves (P-waves) released are compressionand rarefaction waves that cause particles to move parallel to the waves’ direc-tion. The Secondary waves (S-waves) have significantly larger amplitudes, andwith shear motion, they displace particles perpendicular to the waves’ direction [1].Released together, P and S-waves separate as they travel at different velocities.P-waves are on average 1.7 times faster and arrive to the surface first. Seismicwaves attenuate moving through the ground and translate to surface waves once atthe top. Surface waves also become weaker as they move away from the epicentre[1].2.1.2 Soil Conditions and Seismic WavesGround conditions have a significant impact on the frequency content, the ampli-tude and the velocity of seismic waves [1], [30], [31], [32]. Softer soils, with highwater, sand and clay content, tend to amplify the low frequency wave components.Harder, rockier soils boost the high frequency components of the wave.9When seismic waves change medium from hard rock to softer soil their shearvelocity decreases, and their amplitude grows. [3], [18]. Seismic events in soil-diverse areas have been known to cause ground shaking on soft soils five timesgreater than the motion of the neighbouring volcanic rock [1].Amplified waves coupled with emphasized frequency contents matching theresonant frequencies of structures produce extreme shaking and serious structuraldamage which spells disaster for populated areas [31], [30], [32].2.1.3 Observation-based Seismology and Strong Motion AnalysisScience and society have introduced multiple ways to characterize the size of anearthquake. For example, ground shaking intensity is a subjective way to qualifythe size of an event as the perceived effect of ground motion on buildings and peo-ple. The method was developed before instruments could measure shaking inten-sity more deterministically, and it is still used when examining historical seismicevents. The ground shaking intensity scale has gone through multiple modifica-tions and since 1931 the Modified Mercalli Intensity (MMI) scale is the acceptedconvention [1].The relative strength of an earthquake can be measured by its magnitude or byits effects. The often-used Ritcher scale, expresses the strength of the earthquakewith an index relating to the amount of energy released. Magnitude is used foranalysis in the discipline and is the preferred way to notify the public of the size ofthe event [1].Ground acceleration is the quantity measured by accelerometers. Peak GroundAcceleration (PGA) is the maximum value of the recorded acceleration throughoutthe duration of the event. Ground acceleration is represented as two horizontal andone vertical components [1]. Refer to A.1 in Appendix A for the relationship be-tween earthquake magnitude, PGA expected close to the epicentre and MMI scale10with a description of each degree. PGA, magnitude and shaking intensity will beused in this work to describe the size of seismic events.In observation-based seismology, seismic stations outfitted with maximum pre-cision seismometers are placed in high seismisity areas and stand by to record theearthquake event. The records obtained from these stations are used to determinethe epicentre, the shaking intesity and the PGA at the epicentre. Further, the PGAand magnitude of shaking intensity for different locations of interest are estimatedbased on the location’s distance from the epicentre. All estimated and observedseismic parameters are compiled into a ShakeMap of the area. Every step in thepreparation of the ShakeMap carries a degree of uncertainty which cascades intothe final estimates [5].ShakeMaps rely on historical data and Ground Motion Prediction Equations(GMPEs) to make estimates for locations without stations. The GMPEs reflect thegeology and the wave propagation behaviour in the area. There are families ofGMPEs developed for specific geographic regions. Still, GMPEs are approxima-tions and generalize the actual conditions in the area they apply to. Their outputsare median values for ground motion that usually have standard deviations of factorof 2 [16].The ShakeMap is finalized post-event when full seismic recordings are pro-cessed, and it becomes part of the area’s seismic record. Locations with existingstations have factual recordings of the episode. However, for locations withoutdirect observations, it cannot be verified whether the magnitude experienced is in-deed the one predicted by the estimation.112.2 The Earthquake Early Warning System2.2.1 Earthquake Early WarningFor many natural hazards, the process of early warning starts with some anticipa-tion before the event. For example, a tiltmeter at a dormant volcano detects grounddeformation as magma gets closer to the surface and produces a warning long be-fore the eruption [33].Predicting when an earthquake will occur is not as of yet possible. We can-not observe the seismic source kilometres into the ground or measure the level ofstress in Earth’s crust [1], [18]. We are limited to identifying locations with a highprobability of seismicity and detecting the earthquake there as the motion begins.Consequently, earthquake early warning starts at the onset of the event and thewarning time is the time it takes for the strong motion to travel to the location ofinterest.As a discipline, earthquake early warning is defined as the rapid detection,characterization and declaration of an upcoming earthquake to enable mitigatingactions by the warning’s users [7]. The basic idea behind EEW is that commu-nications and data processing are several magnitudes faster than the propagationof seimic waves. If the seismic wave is detected at a distance from the point ofinterest, its arrival can be announced ahead of time [5]. The goal of a sophisticatedEEW is not just to inform that an earthquake is coming, but to prepare a ShakeMapof the area as soon as possible [34], and to alert immediately the users of the systemwhat they should expect so they can take appropriate actions.Every EEW system has the following components: data collection, event esti-mation, and information dissemination. Data collection implies obtaining groundacceleration measurements from the system’s data sources. This data is used in anevent estimation procedure to determine earthquake location, magnitude and im-pact on the area. Data source location, amount of data and content and estimationprocedure vary greately depending on the system’s approach. Traditional and non-12traditional approaches are discussed in the following section.Information about the event is sent out to EEW users. This information isregion-specific and includes warning time. Warning time is the time between offi-cial alert and the time when the peak shaking is estimated to occur [5]. The generalpublic receives the warning via a sounding alarm bell in public places or throughradio, television, and computer or phone applications. The message is kept simple,for example, ”Earthquake magnitude 6, expected in 10 seconds. Drop, cover andhold on”[5].Members of the general public use the warning time at discression. Specialpersons or institutions in sensitive job positions need the alert to adjust their pro-cesses, especially if dangerous work conditions or first response are part of theirbusiness activities [5].2.2.2 Approaches to EEWTraditional ApproachesThe traditional approach to EEW, estimates the earthquake point source locationand employs strong motion analysis as described in section 2.1.3. A small cluster ofseismic stations close to the source detects the onset and the P-wave’s arrival. Theprocedure works to prepare a ShakeMap as soon as possible. The strong energy ofthe S-wave, indicator of the earthquake’s magnitude, is empirically predicted fromthe peak ground acceleration of the P-wave [5], [34].With this approach, data collection is very limited, on average only four sec-onds of recordings are collected. [19]. The S-wave is a short distance behind theP-wave and strong S-wave energy leaking into the recording may skew the forcastleading to magnitude over-estimation and false alarms [7], [34]. This is a general-ized prediction of magnitude, using multiple approximations and simplifications,applicable to an area of hundreds of kilometres radius around the epicentre [5], [7].13To minimize transmission delays, data is often processed on-site [35], [13]. Onlythe alert is transmitted if the predicted strong motion exceeds the selected thresh-old.Traditional approaches have difficulty in predicting large events. The predic-tion saturates and events with magnitude 7 and above are forcasted as the samesize [34]. Trading off accuracy for warning time is the practice. Alerts start witha low-accuracy estimate and issue improved magnitude predictions a few secondsafter the initial message [7].Some improvements in traditional prediction’s accuracy have been noticed whenseismic stations are distributed more frequently in the observed area. Distributedstations can detect if the initial fault expands further and impacts other areas [7].Closing the distance between stations refines and increases the reliability of sourceand medium parameters’ estimation [22], [17].Non-traditional ApproachesNon-traditional approaches can be divided into new methods of data collectionwith traditional prediction, and new methods for both data collection and predic-tion. The former, EEW systems with updated data collection, though using tradi-tional prediction process show improved accuracy from denser distributed obser-vations and real-time data processing [24], [26], [36]. The latter, Ground MotionModels (GMMs), employ distributed data collection in real-time and envision theearthquake as seismic energy travelling away from the source [25], [37], [23].The main motivation for finding alternative sources of seismic data is so thatdeveloping countries, where financial and governmental factors prevent the de-ployment of national or regional EEW systems can still have some earthquakeprotection [26]. The prevalent use of Smart Phones SPs and personal computershas identified them as potential seismic data sources [24], [26], [36].The built-in accelerometers in SPs could be a source of vast amount of ground14accelleration data [24], [26]. Networked with processing computers, SPs wire-lessly supply intelligence for decision making and receive earthquake alerts in re-turn [26]. Data generated by SPs has limited accuracy [7], [5]. Not intended forearthquake detection, their accelerometers are less sensitive. The minimum activitythey can detect is magnitude 5 [24]. Because SPs are often in motion, distinctionbetween human movement and seismic activity keeps processing resources rela-tively busy [26].Another alternative data source are MEMS sensors connected via Universal Se-rial Bus (USB) to personal computers [36]. The accelerometers used are of muchbetter quality, able to detect magnitudes 3 and higher. The Quake-Catcher networktakes advantage of the Internet and distributed computing, so data collection andprocessing is done much faster, maximizing warning time for the application user.Still, serial interface sensors lack good connection to ground motion if they are notfirmly mounted to the floor or building walls.New approaches to both collection and prediction look to improve the over-all characterization of the event and offer a better spacial resolution in the for-cast. They depart from strong motion analisys and do not use source parameters orGMPEs. GMMs’ idea is to view an earthquake waveform as the physical processof moving particles carying energy. They apply energy distribution theories, suchas radiative transfer theory, to predict how seismic energy travels and translates intoground motion given some knowledge about the propagation medium [25], [37],[23].Here, high-precision, high-cost sensors are located on the path of wave propa-gation, data is collected in real-time throughout the duration of the earthquake andestimation is constantly updated. Yet, radiative transfer makes some asssumptionson the attenuation and scattering properties of the medium and prediction is admis-sible only 10 seconds in advance. GMMs anticipate well larger magnitude events,subsequent aftershocks and even seismic wave reflections. These methods requirehigh observation density and good knowledge of site conditions to be consistent intheir accuracy.152.3 Currently Operational EEW SystemsThere are nine operational Earthquake Early Warning systems world-wide. The-oretical knowledge and research on EEW are ahead of the deployed systems [8],and almost all operational systems in the world use traditional approaches [16].Below, we describe the three most advanced operational systems in the world andcomment on some of their performance challenges.2.3.1 JMA EEW, JapanThe Japanese EEW system, operated by the Japanese Meteorological Agency (JMA)since 2007, is world’s most advanced and best-tested EEW application [18]. Thesystem’s latest reality trial was the 2011 Tohoku earthquake of magnitude 9 at theepicentre. Its performance gave way to several observations [18], [7], [20]. Firstly,an initial small P-wave does not mean a small earthquake. P-wave amplitude isnot a good indicator of how significant an earthquake will be. The point sourcealgorithm took several cycles to ramp up estimation toward the correct magnitude.This process consumed the warning time for near-source locations.Secondly, the algorthim will underpredict for two reasons, one is the tendancyto saturate, and two is the lack of accountability for continued fault ruptures [20]. Amagnitude of 8.1 was reported in Tohoku instead of 9, and parts of Kanto provincedid not receive a warning at all, though the rupture had already reached them. Thissituation left system users, both the general public and industry, severely unpre-pared for what was to come.Thirdly, the system’s prediction approach becomes very confused by the manysilmutaneous aftershocks, and the estimates keep issuing false warnings [20]. For45 days after the magnitude 9 event, multiple earthquakes shook at once. Thesingle-source centred approach was unsuccessful at separating the contribution ofeach event and notification decisions were made from an incorrect ShakeMap.16After the devastating Tohoku event, the JMA upgraded the traditional systemto a hybrid system, incorporating GMMs in its prediction approach [7], [18], [20].The new improvements kicked-in in 2016 and have performed well, accounting forsaturation, considering simultaneous events. This has led to the physical expansionof the network. 4300 stations across Japan now provide real-time readings from adenser seismic network.2.3.2 SASMEX EEW, MexicoThe early warning systems of Mexico, deployed in Mexico City in 1991 and inOaxaca in 2003, form the Seismic Alert Systems of Mexico (SASMEX) [38]. Sim-ilarly to Japan, system upgrades have been implemented over the years only postpoor performance in seismic events. Initial deployment itself came after the devas-tating 1985 magnitude 8.1 Michoacan earthquake [18].Stations were deployed mainly on the Pacific coast and allowed for warningtimes of 60 seconds for Mexico City, 320 kilometres away from the danger zone.A large event in September 2017, only 100 kilometress away from the capital,shook the city before the notification arrived. The infrastructural damage and theloss of 500 lives forced a revision of a system blind to in-land earthquakes andshowed the need for distributing stations inside the continent [8], [38].A traditional approach to prediction is inappropriate for the area. Mexico Citysits on a dry lake, a jello-like soil will amplify even waves attenuated over a dis-tance of 300 kilometres. Dramatically different ground motion has been observedfrom one neighbourhood to the other [31]. Relative wave amplifications can varyup to 56 times [38]. A GMPEs-based estimate will issue a single magnitude andshaking intensity, when the system should be issuing a custom prediction for everysubarea of a square kilometre or less.172.3.3 CISN ShakeAlert EEW, California, Oregon, WashingtonNearest to us is the California Integrated Seismic Network (CISN) network, ShakeAl-ert. Fully deployed January 2022, with approximately 900 sensor stations, it hasnot yet received extensive seismic testing [35]. It combines several traditional al-gorithms that somewhat cover each others weaknesses and the overall predictionis a weighted average between them [18], [35]. The algorithms vary in their esti-mation process, and most-significantly in the diversity of data they require and thetime they need to produce a prediction.Recognising the relation between observation density and prediction accuracy,ShakeAlert has committed to creating a denser station network, especially in pop-ulated areas near the coast in Sothern California [19], [21]. Still, deployment costsof high-accuracy equipment limit station frequency to a minimum of 10 km whichproduces data for low resolution predictions.A significant event that tested ShakeAlert’s partially-deployed system in 2019was the magnitude 7.1 Ridgecrest earthquake. ShakeAlert underestimated thestrong shaking by 0.8 magnitude points. Apart from the typical challenges of thetraditional algorithms with saturation and empirical uncertainty, the underestima-tion came from inefficient data compression and limited bandwidth at the seismicsites. Packet transmission delays, on average less than 1 second, in some instancesamounted to a minute during the strong shaking. In response, system operatorsare currently putting in place a data transmission infrastructure that will have thenetwork resources guarantee minimum delays [21].2.4 Automated ActionsAs discussed in section 2.2.1, apart from the general public, EEW systems provideservice to businesses with dangerous work conditions and first responders, allow-ing them to alter or stop work and prepare. At the same time, utilities’s systems,high-speed communication and transportation systems, airports, financial and in-dustrial businesses are all vulnerable to damage from seismic activity. These enti-18ties have extensively computerized their activities and are able to implement auto-mated actions through automated response applications in real-time and to modifyactivities as pre-programmed when an earthquake notification is received [5].Many industrial entities recognize the value of early warning and try to pro-tect their individual automated infrastructure [18]. Some employ on-site sensors tocollect data and make estimates of ground shaking at the site. These simple EEWsystems are used to trigger valves for gas and oil pipes, for example. Others, liketrain systems in Japan, create their own mini-EEW application to slow down orstop trains automatically upon earthquake detection [20]. Others take the regionalsystem’s general warning as an advisory opinion rather than an action-requiringinput and decide for themselves how to react.Currently, no automated response is triggered by a notification from a regionalsystem [5]. The industry’s reluctancy to integrate automated responses is a resultof the regional systems’ poor performance in prediction accuracy and spatial res-olution. Automated action should result from site-specific estimates of damage,which requires seismic data collected at the site [20]. Regional systems presentlydo not support site-specific observations. Industrial processes with significant coststo action are unlikely to go beyond considering the notification as an advice in lightof low EEW accuracy . Modifying activities, like turning off a nuclear reactor, isassociated with high financial losses and shortens the equipment’s life.Table 2.1 gives an overview of the EEW-related automated responses imple-mented in different countries [7], [18]. Our research shows that nowhere in theworld is power turned off in regions predicted to experience strong ground shak-ing. In some instances, up to 90% of earthquake-induced damages have been at-tributed to post-earthquake fires PEF from fallen transmission lines or short circuitsin buildings [7], [39]. This type of disaster is avoidable if the power grid can beacted on automatically seconds before the area shakes.When a city sits on the coast line, close to the earthquake’s epicentre, the warn-ing time it receives is a few seconds. This time is enough only for triggering au-19tomated actions [8]. In a critical infrastructure with many interdependent compo-nents, smart modifications in operations can reduce significantly heavy monetarydamage and infrastructure downtime that always accompanies strong earthquakes[20].Table 2.1: Implemented Automated Response to EEW System NotificationAutomated Actions EEW Systemtrain slow down and/or stop ShakeAlert, EDIM Turkey, JMA,SASMEXgas shut off EDIM Turkey, JMA, ShakeAlert,EEW Europe, Chinaoil shut off JMAwater supply management ShakeAlert2.5 Performance-based EEWIn the modern EEW discipline, systems that only perform the estimation of theearthquake’s source and size are seen as a thing of the past, especially in light ofthe increasing need to protect infrastructure [16]. We already discussed that groundconditions influence ground motion. In addition, infrastructural assets vary in theirconstruction. Their response to the same ground motion will be different and sowill the damage they sustain. Structural velocity has replaced ground motion at thebase as the best indicator of damage to a building [3]. Therefore, proper asset pro-tection requires its own event prediction. The EEW of the future will provide bothground motion estimation and successive infrastructure damage estimation EEW[16].Currently, there is no EEW system that issues early warning based on estimateddamage [18]. Damage or loss-oriented, also called performance-based, decisionmaking is only discussed in theory. With this approach, notification is issued if theestimated damage of a specific infrastructure is above a set threshold.20Performance-based alerts require accurate ground acceleration data taken fromthe site. Ground acceleration inserted into the statistical relationships betweenstructure characteristics and sustained damage, called fragility curves, will pro-duce the damage estimate [7].Infrastructures rarely operate in full independence of other activities. Performance-based prediction approaches should consider the interdependencies between dif-ferent infrastructures and the possible effect when notifying a key structure anddisrupting its operation [5].2.6 Vancouver, a Unique Earthquake-prone AreaThis far we have outlined different approaches to address the early warning needsof several regions across the globe. However, Southwest British Columbia standsapart in its characteristics and Vancouver is a unique earthquake-prone area. TheEarthquake Early Warning systems currently implemented will leave us inade-quately protected.Current EEW systems are deployed in an area where one specific type ofearthquake is prevalent and use that earthquake’s statistical relationship betweenP-waves and S-waves. Vancouver, as figure 2.2 shows, is prone to three differenttypes of earthquakes and it is not possible to distinguish between them at the onsetand to apply the corresponding relationship. Earthquakes may start the same butdon’t proceed the same [8]. Estimating ground shaking based on the wrong statisti-cal relationship can lead to huge inaccuracies in prediction. We need a system thatwill bypass the P-S uncertainties and issue estimates directly from the amplitudeof the S-wave.Another factor to consider in finding a suitable EEW application is the varyinggeo-conditions in the area. As we discussed in section 2.1.2, site-specific factorslike soil have a huge impact on ground shaking. Vancouver and Metro Vancouversoils have high water and sand content, therefore high liquefaction. During a heavy21Figure 2.2: Sources of Earthquakes near Vancouver from [3]. The area isprone to subduction, crustal and subcrustal earthquakes. They exhibitunique behaviour and have unique consequences.shaking these soils liquify under the weight of the stucture atop and can engulf it[40]. Areas where high and low liquefaction materials meet can trap and reflectseismic waves causing prolonged shaking: the much-feared basin effect [8]. Thisparticular phenomenon was seen during the 1985 Mexico City earthquake. Build-ings on Lake Zone’s soft and watery soils were severely damaged, and barely ascratch was present on structures in the rocky Foothill Zone a few kilometres away[31], [38]. A high spatial resolution prediction for tens of square metres can takesoil conditions into consideration so occupants can know the intensity of motion intheir specific area.The nearest source of seismicity is the Strait of Georgia. A mere 14 kilome-tres from the University of British Columbia and 28 kilometres from the centre ofVancouver. Issuing a more exact prediction from an S-wave would give a warningtime of less than 10 seconds for an S-wave travelling at 4 km/s [13]. The desiredearly warning system should be able to translate a high-accuracy, short lead-timeprediction into a useful notification. This notification would help industry and cityinfrastructures, and first-aid services to set up automated actions that can be takenin seconds but will minimize the city’s recovery time after the event.22In addition to the ShakeAlert subscription, Ocean Networks Canada and Nat-ural Resources Canada currently support a SouthWest BC EEW system [13] with32 in-land and 8 seafloor stations, installed in 2018. The system design choices areas follows. To increase data reliability in its collection stage, the stations’ groundacceleration data is complemented by GPS ground displacement data. This is ad-mittedly done with some difficulty.Another challenge at present is the actual data transmission. Due to the lack ofhigh-speed high-bandwidth of the current network to carry raw data, processing isdone at the stations and only parameters are transmitted to the decision servers.The prediction algorithm accounts for different types of earthquakes throughempirical scaling relationships between P-waves and S-waves and does not takesite conditions at the stations or elsewhere into account. Both design choices add afurther degree of inaccuracy to the event estimates.When the system produces an estimate and notification, it leaves it up to criticalinfrastructure and responsible authority operators to calculate their own warningtime and shaking intensity for their own location and trigger their own automatedevents. This is an ineffective use of a warning time of at most 30 seconds.In reflection, the local system doesn’t provide adequate service for the grow-ing needs of the area and the features of the Earthquake Early Warning in SmartCities (EEW-SC) application should be incorporated into a hybrid system that willachieve the level of protection we need.2.7 The Developed EEW-SC ApplicationThrough the above we have established that advances in Earthquake Early Warn-ing have shifted focus to more effective service by implementing more accurateprediction approaches, relying on faster communication to collect data, using digi-23tal instruments, expanding ground motion observation networks, and incorporatingreal-time data for better prediction.The Earthquake Early Warning in Smart Cities (EEW-SC) application we areproposing for Vancouver and Metro Vancouver is a next-generation, performance-based, auto-response enabling EEW application that approaches data collection,event estimation and notification in its own way.2.7.1 Goals of the ApplicationThe goals of the EEW-SC application are:1. To detect all possible types of earthquakes with magnitudes between 3 and10+.2. To deliver a 90%+ accurate prediction of earthquake intensity, tailored to thevarying geological conditions in the area of interest.3. To provide a site-specific estimate of the expected damage of individual in-frastructure assets during a seismic event and to predict the future state ofthe assets post-event.4. To enable operators of critical infrastructures to implement automated re-sponses to early warning information.5. To continuously update estimates and assessments in real time, with updategiven every 1 second when the wave enters the area of interest.6. To employ an optimized system for data collection, analysis, and estimationthat maximizes the warning time.7. To require low monetary investment when deployed and little maintenanceduring seismic inactivity.2.7.2 Top-view ArchitectureThe EEW-SC application will be triggered by the seismic sensor closest to theearthquake epicentre. This could be a sensor that is part of the National Resources24Canada (NRCan) seismic network. Upon trigger at the epicentre, the EEW-SCprocessing centre will receive a notification which will wake up the data collectionnetwork.EEW will employ ground acceleration data collection from seismic sensorsdeployed throughout the city in real-time before and during a seismic event. Dataprocessing will happen in real-time in the Edge and Cloud servers to produce pre-diction of earthquake magnitude, ground shaking intensity and asset damage es-timation. Immediate notification will be issued to users of the system, includingautomated infrastructures, critical city infrastructure, and the general public.2.7.3 ComponentsData CollectionThe data collected during the event will reflect the soil conditions, all possible re-flections of the waveforms, all possible simultaneous events, and all aftershockswith a fine grain spatial observation. The rest of this work is concerned with thedata collection and pre-processing process before data enters the wave propagationmodel and the analysis stage to facilitate prediction.PredictionOur prediction approach is based on wave propagation theory. To estimate theearthquake wave values and location, the Electromagnetic Transients Program (EMTP)transmission line segment model will be utilized, where the connection betweenneighbouring observation points is represented as a line segment [41], [42].The propagation prediction will reflect the strong relationship between groundshaking and site-specific conditions. This relationship will be expressed as trans-mission line parameters.25Every observation point will generate ground acceleration data and in turn willgain an estimate of what is and what is to come. Further, site-specific estima-tion of asset performance and condition during the event, as well as estimation ofdamage will be able to use the most accurate fragility curves available for the asset.NotificationThe EEW-SC application is intended for use by the general public and for pro-tection of assets. Its value is most relevant for protecting high-value users suchas special institutions with dangerous work conditions, first response actions, andcritical city infrastructures and industrial installations.Our infrastructure and industry users will be able to apply automated actions toshort lead-time notifications. They will leverage high accuracy of prediction, 90%or higher, over a large warning time.For performance-based notifications, alerts will be issue based on how thestructure will react on the expected on-location’s ground shaking. Notification ofthe health of the asset will be given on ongoing basis during the event, as well aspost-event.We recognize that the Earthquake Early Warning of the future should take ac-tions that allow its users to optimize the warning time and should customize alertsdepending on the area, the infrastructure, and the user’s needs [5].26Chapter 3Internet of Things and ItsPotential Application to EEW3.1 The Internet of Things3.1.1 Concept and DefinitionThe Internet of Things (IoT) is broadly defined as the standardized technologies,systems, protocols, and design principles applied to Internet-connected entities thatinteract with the physical environment [4]. Anything with parameters, states andtransients that can be observed, measured and quantified can be the subject of theInternet of Things.Made possible by wide-scale Machine-to-machine (M2M) communication, theIoT allows for billions of devices to sense and share information over wireless andwired networks, and cooperate to create new applications and services. These de-vices can be securely discovered and identified, monitored and controlled by theapplications. The goal of the technology is to provide the world with knowledgethat could be applied to planning, management and decision-making activities.Several notable technological strides [4] are transforming the IoT from a con-27cept into a commodity available anytime, anywhere, for anything. Improved Mi-croelectromechanical Systems (MEMS) and low-cost, printable electronics can en-able compact, inexpensive sensing technologies. Advances in energy storage andembedded processing give IoT devices the ability to support multiple sensing ob-jects over an extended lifespan. An evolved Service-Oriented Architecture (SOA)makes possible Open and Representational State Transfer (REST) Application Pro-gram Interfaces (APIs) and allows applications to use services available in the net-work. The application of Artificial Intelligence (AI) and Machine Learning (ML)techniques helps clean and make sense of huge quantities of previously unmanage-able data. Virtualization now enables parallel environments for optimized use ofresources. Powerful, full-service data storage and processing platforms and high-speed wireless communication networks ensure data is turned into consumable in-formation instantly and securely.In practical applications, the IoT integrates information and communicationtechnologies [29], [43]. Information technology hardware and software generate,collect and process data for the purposes of the application. Communication tech-nology facilitates the data flow through each step of the process.As IoT solutions grow through research and implementation, the building blocksof the technology are revised and reconfigured. Here, in figure 3.1, we present thefundamental IoT system and its functional components. IoT devices collect datafrom a diverse set of assets. They pass that data through a communication channelto the application which performs strategic computation and data analysis. The ap-plication either applies the conclusions back to environmental control or offers theresults for consumption by different groups of users [4]. Each component is givenattention in the following sections.3.1.2 The IoT Device/ThingThe basic IoT Device/Thing structure in figure 3.2 is comprised of Sensing/Actua-tion, Processing and Communication units.28Figure 3.1: The IoT System. IoT devices collect data from assets. Datapasses through a communication channel to the application. The ap-plication analyzes the data, applies control to assets, or offers the resultsto users.29Figure 3.2: The IoT Thing comprised of Sensing/Actuation, Processing andCommunication units.Deployed densely, often in harsh environments, IoT devices have to be low-cost and expandable [44]. Frugality is built into their design and the majority ofdesigns are resource constrained. They are limited in computation, network accessand power. The overall expectation is, however, that IoT devices perform data col-lection in real or near real time.The design of each unit is dependent on the mission of the application. A num-ber of alternatives are available to fulfil the unit’s functions. We have featured thealternatives presenting interest to our area of research.Sensing/ActuationIoT devices are outfitted with sensors capable of measuring the physical, chemical,and biological parameters [45]. These sensors are mounted on, worn by or im-planted into the assets they observe. Observations are gathered and converted intoa signal read by the microprocessor.In some instances, IoT devices are also enabled with actuators. An exampleis an industrial IoT device that supplies data on facility temperature through itsthermal sensor and activates an industrial fan if the temperature has exceeded athreshold value.30As mentioned, continuous improvement in capabilities, component miniatur-ization and low power demands make MEMS sensors and actuators the most fre-quently utilized in smart devices [45], [4], [44].ProcessingProcessing units in IoT devices are primarily embedded computers such as micro-processors, microcontrollers, System on Chip (SoC), and field-programable gatearrays, with low power consumption and limited capabilities in terms of storageand processing [45], [46], [4].The simplest processing unit an IoT device can have is a basic microprocessorwith an 8-bit CPU, some peripheral memory and a couple of I/O interfaces. Morecomprehensive devices house as much as an SoC with a 64-bit ARM architecture,multiple interfaces and memory elements. During the commercialization stage ofan IoT application, processing units are custom built with only the necessary hard-ware and software features.In the developmental stage, while resource requirements are still under dis-cussion, there exists a trend towards utilizing a Single Board Computer (SBC) as aprocessing unit [46], [45]. These all-in-one solutions have 16 or 32-bit CPUs, opensource software and enough resources to implement basic functionality [45]. Thetop three SBCs for IoT prototyping are the Google Coral Dev Board, the RaspberryPi 4 and the NVIDIA Jetson Nano [46].The Operating System (OS) used corresponds to the hardware capabilities. OSsare typically open-source and target minimal memory consumption. For example,TinyOS uses only 178 bytes of memory [44] and RIOT, Contiki OS and FreeR-TOS have memory requirements in the kilobytes. Higher-level IoT platforms andSBCs like Raspberry Pi, Beagle Bone, Orange Pi, Samsung Artik, Intel Edison andGalileo require multiple gigabytes to run Ubuntu Core, Ubuntu Mate, RaspberryPi OS, Windows 10 IoT Core and others [45], [4].31CommunicationAn IoT application performs organized data collection through its devices by im-posing a particular type of communication mechanism. Devices are organized in anetwork historically called a Sensor Network (SN). The communication abilitiesof an IoT device depend on the type of communication of the network which isdiscussed next.3.1.3 The IoT Communication NetworkCommunication is a central aspect of the Internet of Things and cannot be dis-cussed independently from Internet communication. Internet-based communica-tion is the bond between gathering the data and transforming it into useful infor-mation [4].The IoT communication system’s model is founded on the Internet EngineeringTask Force (IETF) model [4] and its 5-layer architecture, as shown in figure 3.3,will be discussed in relation to IoT communication. Protocols at each layer governthe end-to-end communication between two entities. In the context of the IoT,protocols facilitate data collection.Physical and Data Link LayersIn IoT, wired and wireless networks have their own Physical and Link Controllayer protocols. These low layer protocols differ when they are applied to local orwide area networks. Communication mechanisms like Bluetooth, Zigbee, NB-IoTand LoRa are the first IoT communication mechanisms and are mostly proprietary[45]. They do not make use of IP and rely on their own protocol stack which isinoperable outside their mechanism [4].In the case of EEW-SC, since the network it uses for communication is Rogersnetwork, Physical and Link Control layers have already established protocols for32Figure 3.3: The Internet Engineering Task Force Communication Model [4]giving foundation to the IoT communication system model.facilitating Internet Protocol (IP) based Network layer. In developing the applica-tion, our task was to select the upper layer protocols, namely the Transport andApplication layer protocols so they meet the requirements for data collection andpre-processing and by extension the goals of the application.Network LayerThe Network or Internet layer provides a host-to-host communication service [27].It is a best-effort service meaning neither the order, integrity or definitive deliveryof the packets is guaranteed.Internet protocol is responsible for assigning an unique identity called an IP ad-dress. Addressing has three versions: IPv4, supporting 4 byte addresses, IPv6 sup-porting expanded 6-byte addresses; and 6LowPAN, an IPv6 for low-power wirelessdevices providing encapsulation and header compression. IPv6 has been deemedas best suited for IoT applications and their need for millions of IP addresses [29].33Transport LayerThe Transport layer is responsible for communication between processes on dif-ferent hosts [27]. Two Internet transport protocols are available: User DatagramProtocol (UDP) and Transmission Control Protocol (TCP). Both protocols offerdata delivery and basic error checking between processes.TCP is connection-oriented [27]. It provides congestion and flow control, guar-antees message delivery and segments longer messages if needed. Message ex-changes begin with a hand-shaking phase and end with a link tear-down phase.Every message is acknowledged upon receipt. The protocol uses retransmision ofunacknowledged messages to ensure reliable data transfer. TCP introduces someadditional delays to message exchange to meet its reliability guarantees and adds20 bytes of overhead to message headers.UDP is a lightweight protocol compared to TCP [27]. With UDP, message ex-change commences and stops without handshaking or link tear-downs. UDP doesnot guarantee message delivery, it does not require re-submissions and it is notconcerned with congestion. The sending side can continuously send data. The pro-tocol’s no-frills approach makes it suitable for time-critical IoT applications wheredata redundancy is available. UDP adds only 8 bytes of overhead to message head-ers.Both protocols implement some level of security. TCP uses Transport LayerSecurity (TLS) protocol and UDP relies on Datagram Transport Layer Security(DTLS) protocol.Application LayerThe Application layer is responsible for application-to-application communicationand performs session and presentation functions [27]. Application software exist34on all IoT nodes and Application layer protocol is distributed among end systemsto facilitate application message exchange. IoT applications opt for protocols thatfulfill the goals of the application.There are two possible models for session management [4] at this layer: theclient/server, also known as request/response model, and the publish/subscribemodel.In a client/server or request/response model, the device is the server and the ap-plication is the client. The client requests data, and the server responds back withthat data. This exchange is synchronous. For every request there is a response.Request/response message exchange is already successfully applied in HypertextTransfer Protocol (HTTP).Additionally, application layer request/response protocols use REST mecha-nisms that limit the operational dependency between the client and the server andenforce a uniform interface for interaction. Another feature of REST is statelesscommunication where a request message contains sufficient information for theserver to respond. Optionally, some types of requests can be cached at the client tominimize traffic. REST does not allow clients to handle the resources the serversoffer directly, instead clients interact with the resource representation.REST for IoT has been updated to include server resource observation whichresults in a notification when the resource has experienced a change in state. Thisupgrade alleviates the latency and bandwidth toll of frequent resource polling.The most often implemented client/server protocols are Constrained Applica-tion Protocol (CoAP) and Extensible Messaging and Presence Protocol (XMPP)[46], [45], [4], [46]. CoAP is designed with IoT in mind, allowing basic, con-strained devices to connect even in poor bandwidth or network conditions. CoAPis the preferred protocol in a number of M2M verticals [46].XMPP is better suited for text messaging and chat applications. Only non-35constrained IoT applications would default to it because of its hefty use of powerand transmission overhead [4].The second alternative to facilitate communication is the publish/subscribemodel with a device publisher and application subscriber. This model has a centralbroker to collect, store and distribute the messages between the application and thedevice. The broker advertises the events or topics a publisher can produce as wellas facilitates asynchronous message exchange.A subscriber cannot poll a publisher. If interested in a topic, the applicationwill subscribe to observe that topic and the broker will forward the messages pub-lished by the devices offering that topic. Publishers and subscribers do not needto coordinate. They just wait in expectation of messages. Observation and event-based exchanges are at the core of this model.Publish/subscribe is a better approach for applications concerned with latency,but having a single point of message exchange does little for reliability [4]. Packetloss is frequent at broker message queues. If the queues are full of awaiting mes-sages, incoming messages are dropped.The most often implemented publish/subscribe protocols are Message QueueTelemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP), andData Distributed Services for real-time systems (DDS) [45], [47], [46]. MQTT op-erates over TCP/IP. Its simple message header and constrained device support donot do enough to offset the brokering and reliability overhead that adds to latencyand power consumption. MQTT is not the top choice for real-time systems [4].AMQP has a unique message queue implementation where end points are moreactive in requesting and sending messages to and from the queue. However, theprotocol comes to IoT from enterprise applications and is yet to be optimized [4].In DDS, the broker is omitted and the publisher is responsible for distributingthe data. TCP-dependant, the protocol supports extensive reliability features. Al-36though it performs better than most, it is overhead and bandwidth-greedy and notsuitable for constrained devices. It is favoured and successfully applied in indus-trial automation [45].3.1.4 Types of Communication Between IoT NodesThe communications network lying between an IoT application and devices is notuniform [4]. Typically, IoT devices connect through an IoT Access network to anEdge entity. The link between Edge and the IoT application in the Cloud is estab-lished through the IoT Core network . The Core network is usually a standard IPnetwork.According to MediumAlthough signal propagation could be both guided or unguided, wireless networksare preferred in the context of IoT Access networks [4]. IoT predominately utilizeswidely available satellite and radio connections, and powers devices with batteries.Wireline offers reliability, security and low latency but is associated with highdeployment costs. Wired power and signal connections are preferred only wherethere is already existing infrastructure.According to CoverageNetworks classify as Local Area Network (LAN), Metropolitan Area Network orWide Area Network (WAN), with respect to their coverage [4]. IoT developersselect the network’s range based on the requirements of the application.Transferring data over a short distance from wearables and implanted devicesrelies on Personal Area Network (PAN)s, where device to device link is no morethan a few meters. Low Power Wide Area Network (LPWAN)s, on the other hand,are able to support low-power, low-rate data transmissions over tens of kilometres37and extend device battery life over 10 years [48].Though short-range communications are more affordable and easier to imple-ment in infrastructure [49], their characteristics are not well-suited for many ap-plications. Personal IoT can benefit from the lower cost, but civic and industrialapplications struggle with the limited coverage, the low transmission rates, and theincreased interference and latency [48].LPWANs are challenged when fulfilling the needs of mission and time-criticalapplications. They offer lower transmission rates, are able to transfer only smallpackets, and their reliability leaves more to be desired [4], [48]. In addition,LPWAN communication doesn’t support IP and its upper layers at device level.Instead, it relies on proprietary protocols to handle communication.The gold standard in wireless communication are traditional cellular networks.LTE and especially 5G have high throughput, high reliability, wide coverage andfull IP support for IoT devices. Cellular networks fulfill the needs of Critical IoTfor security, low latency and guaranteed bandwidth. They are more affordablethan satellite communication and their coverage area is larger than Zigbee or LoRawhich makes them suitable for data transmission over large areas [6]. These net-works, however, are designed to optimize the quality of voice communications [48]and are not suitable for battery powered devices [4].Since the rate of IoT deployment exceeds dramatically the new mobile sub-scribers, cellular networks have resolved to provide technologies for IoT support.EC-GSM-IoT, LTE Cat M1 and NB-IoT are some of the enhanced low-power,wide-area Machine-type communications utilizing the current 2G, 3G and LTEbroadband infrastructure [48].5G is expected to meet the needs of the broadest group of IoT applicationsand offer quality of service guarantees, including ultra-low latency and designatedspectrum to accommodate IoT deployment on a massive scale. Specifically, 5Gis called the key enabler [48] technology to support mission and time-critical IoT38applications.According to TopologyIoT networks can be referred to as single-hop or multi-hop, depending on the con-nectivity between two end points [4], [49], [44]. In a single-hop scenario devicesindividually forward data to the application. In a multi-hop topology, an interme-diary node consolidates and forwards the data.Multi-hop connectivity is a heritage approach from sensor networks and thistype of capillary communication is still widely used in IoT. Unfortunately, trans-ferring data through intermediary nodes results in delays and is unsuitable for time-critical applications. Single-hop topology is faster with data transfer but the entiredevice network has to possess the ability to connect long range, which requirescostly hardware.3.1.5 The IoT ApplicationAn IoT application can work to serve, aid, protect and/or improve the functionof a particular industry or domain. Popular domains include living spaces andinfrastructures, agriculture and environment, human healthcare and interaction, in-dustrial and business activities.An IoT application does real-time data analysis. It processes the data immedi-ately as it becomes available, regardless of the sources and the amount, in order toreturn answers in less time [49].There are several computation platforms that IoT applications can use for datastorage, processing and analysis. Computing technologies like Edge, Fog, Cloudlets,and Cloud, discussed below, facilitate in a different way the work of the application[45].Currently, Cloud computing is the most popular platform used by IoT [49].39Cloud computation and data management happens on a shared remote server ac-cessible over the Internet. Cloud users should expect their tasks performed withsome latency. Sharing resources with others and the significant distances betweenobservation and computation sites factor into the wait times. The concentrationof sensitive data makes Cloud facilities a frequent target so security is paramount.Cloudlets are distributed, smaller data centres servicing mainly highly-mobile de-vices and passing pre-processed data to the Cloud application [45].IoT generates a massive amount of data which has to be cleaned of redundancyand processed. Waiting in a processing queue is suboptimal for time-critical tasks.A better option for data analysis in real-time is Edge computation. It reduces delayin processing by distributing work among local servers at the edge of the IoT net-work.Distribution in computation scatters the hacker’s targets. It is exponentiallymore difficult to obtain data from a population of Multi-access Edge Comput-ing (MEC) servers, than from a single Cloud facility. Higher intelligence is re-quired to make sharing of computational burden quick and seamless, especiallywhen handling mobile applications’ tasks. [45].Fog computing, offered by CISCO, eases the burden on Cloud services by per-forming data aggregation, redundancy removal, filtering and pre-processing. Fogdevices go beyond computers and extend to routers, switches and network accesspoints [45]. Fog computing, much like MEC, is resilient to intruders.3.2 Relevant IoT Areas and ApplicationsTo build pervasive presence in our environment and lives, IoT should be applicableto almost any area. Gathering intelligence for decision-making is not just a conceptsuited for industrial, military or business applications. Every day life could benefitfrom the conveniences and protections IoT applications deliver.40Areas that have explored and adopted the IoT range from industry, energy, andstructural health to agriculture and healthcare. Research in IoT applied to under-standing the physical world and phenomena is at an all time high and environmentalmonitoring is an area of prime focus [50]. Quickly changing, unpredictable envi-ronmental conditions can be monitored effectively through IoT’s ability to generateand supply data in real or near-real time.3.2.1 Time-Critical IoTSeveral fields of IoT require real-time operations meaning that data gathering,transmission, and processing are immediate and urgent. These applications areclassified as Critical IoT [28]. Critical, also called time-critical, IoT applicationscould differ in their more specific communication requirements but overall theydemand data delivery within specific time interval and a high-degree of reliability.While an application has some flexibility in approaching its timing and relia-bility constraints, there a few general observations [28]. Moving the applicationcloser to the IoT device has a huge impact on transport latency. Choosing thefastest communication medium, like 5G, minimizes transmission latency. Hostingpre-processing in the network, distributing processing and increasing processingresources speeds up data analysis. Reserving network resources for time-criticalapplications guarantees a cap on latency and increases reliability.3.2.2 IoT Applied to Environmental Monitoring and DisasterManagementSmart Environmental Monitoring deals with effectively addressing, through tech-nology, the challenges arising from unhealthy environmental conditions by moni-toring key environmental factors [50]. This area includes disaster and hazard mon-itoring and management [45].Natural and industrial disaster management and geological hazard monitoringare time-critical in nature [49]. IoT applications in these areas rely on sensor net-41works to collect data on environmental variables [43].Industrial disaster monitoring happens in industrial plants and mines [47]. Italerts of potential rooftop falls, in-rush water or toxic gases and ensures workersafety and good environmental conditions. Geo hazard monitoring IoT applica-tions operating around the world protect communities from the dangers of landand mudslides and debris flow [43].The networks and schemes chosen for environmental data transport have todeliver speed and reliability [49], [43]. In emergency and disaster situations, con-nectivity and data flow is not guaranteed to the same degree by different accessnetworks. The advantages of cellular networks, discussed in section 3.1.4, moti-vates the majority of the aforementioned applications to rely on 4G/LTE technolo-gies and to anticipate utilizing 5G if and when coverage becomes available in theapplication’s monitored area [6].The data processing stage of the application is in-charge of analyzing mas-sive volumes of data with emphasis on expediency [49]. Disaster monitoringand management applications gravitate towards distributed processing. Distribu-tion of tasks produces faster results and conclusions and prevents the application’swork from being interrupted should the hazard affect one of the processing facili-ties. Technologies implemented to drive environmental data analysis are intelligentcomputing, Cloud and Edge computing, and ML [43].3.2.3 IoT-inspired Earthquake Early Warning and Seismic SensorNetworksEarly warning IoT falls under the umbrella of natural disaster management andgeo hazard monitoring. To fulfill their mission, early warning applications workagainst time, especially if the hazards are earthquakes. We emphasized in section2.2.1 that in the context of earthquakes the warning time is the difference betweenthe time of detection and the time of the hazard’s arrival.42Our search for IoT and IoT-inspired earthquake early warning applications,conceptual systems and observational networks of seismic sensors produced veryfew results. Few theoretical designs fully embrace the concept of IoT, and evenfewer are considered for deployment. Several interesting implementations foundin this search are described below.In [51], a real-time sensor system for detecting and processing seismic wavesfor an EEW system is outfitted with limited quantity of sensing units containing a3-axis highly sensitive Bosch BMA-180 accelerometers, able to detect frequenciesin the range of 0.1-30 Hz. An Arduino Due microcontroller handles processing inthe unit. The onboard module provides localization and time-stamping services,and GSM is the chosen long-range communication technology. The sensing unitsare expensive; they process the data locally for P and S-wave detection and onlytransmit parameter data if analysis shows an earthquake is underway.e-Quake, a Smart Phone-Based Wireless Sensor Network [26] applies severalIoT technologies towards Earthquake Early Warning. The application functions inthree components: sensing, intermediate and control. Sensing collects accelerationdata with SP accelerographs and uses GPS to communicate the phones’ location.On the SP, the e-Quake software runs on Android OS. Seismic data is sampledwith frequency of 20 samples per second.SPs process and forward data to an intermediate server. Each intermediateserver has an assigned physical area. The phones in the area both supply data andreceive notification in case of an event detection. They communicate with the in-termediate server over any cellular technology available (Wi-Fi, 3G, 4G). Data isqueried in real-time via a HTTP interface using the Sensor Web Enablement Sen-sor Observation Service.Intermediate servers communicate with the control centre with MQTT proto-col, previously discussed in section 3.1.3. The control centre aggregates differ-ent applications that make decisions based on the information available from eachserver.43The Quake-Catcher Network (QCN) [36] is a distributed computing projectusing MEMS sensors and PCs interfaced over USB as seismic stations. The ap-plication takes advantage of distributed processing, firstly to avoid infrastructurecosts, and secondly to pre-process and reduce the data before it is transferred to acentral server for further analysis.Computers transfer data any way they can, con-nected to Ethernet, WiFi or any other type of IP network. The transfer takes onaverage between 4 to 5 seconds. When a significant detection occurs, the sensor-computer notifies the QCN server, indicating the time, seismic signal amplitudes,and IP address. The network is synchronized over Network Time Protocol (NTP).Turkey’s Self-organizing Seismic Early Warning Information Network (SOSEWIN)is described as a low-cost, wireless, EEW and structural monitoring system [18].The SOSEWIN testbed contains 20 sensing units. Each unit costs 700 Euro, low-cost compared to traditional seismic stations.Each sensing unit consists of digitizer board, communication module, and 3-axis MEMS accelerometer. The digitizer board is an embedded PC with 2 giga-bytes of storage with OpenWRT an open-source lightweight Linux OS. The ac-celerometers sample between 100 and 400 samples per second. Time and locationare determined with GPS. Sensing units have to be installed outside with GPS cov-erage and access to power.The sensor network’s communication mode is ad-hoc. It is meant to be a self-organizing mesh where units talk to each other and data transfer paths adapt to theaddition, removal or malfunction of nodes. Downlink, control and alert messagesare sent via broadcast.SOSEWIN uses Optimized Link State Routing (OLSR) multi-hop routing pro-tocol to periodically assess and maintain network topology and TCP-based pro-tocol for data transfer over a wireless LAN at maximum rate of 54 Mbps on 2.4GHz and 5 GHz unlicensed bands. The Core network connects the gateways to theservers over Digital Subscriber Line (DSL).44The reliability of transmission in the Access network is 95% with 80 millisec-onds End-to-End (E2E) latency, provided a maximum distance of 250 metres be-tween sensing nodes and a line of site between antennas. Since this is rarely thecase, add-on delays can be experienced from multiple packet retransmissions.SOSEWIN is meant to assist the traditional network in an event by supplyingreal time data for ShakeMap preparation. In addition to data collection, sensingnodes perform on-site data processing, analysis of structural health and data archiv-ing as well as communicate the broadcasted early warning messages.45Chapter 4Setup of the Proposed Solution4.1 Requirements on Data Collection and Pre-processingIn section 2.7.1 we discussed the goals of the EEW-SC application. To summarize,the application intends to deliver fast, accurate, fine-grain prediction of seismic en-ergy distribution. The prediction is meant to be updated as often as every second inreal-time and enable automated mitigating responses and infrastructure conditionassessments before and during the seismic event. This is a time-critical application.The intentions of the application translate into several important requirementsfor the implementation of the IoT system for seismic data collection and pre-processing. Firstly, an accurate prediction of ground motion propagation, thatreflects the varying geological conditions requires a high density of observationpoints on the ground. These points collect in real-time very accurate observationson ground acceleration in two horizontal and one vertical directions to allow theapplication to recreate the present conditions and make prediction of future be-haviour. IoT devices for the applications would have to be deployed densely andoutfitted with good accuracy sensors to fulfill these functions.Secondly, providing site specific estimation of earthquake impact, requires thatat least one IoT device is attached to the infrastructure asset, the device identifieswith that geo-location and the data it collects is associated with the asset.46Thirdly, for the application to provide an update in estimates every second formaximized warning time implies that data collection and delivery has to happen inan organized manner, under tight time constraints.Fourthly, a low-cost deployment and low maintenance IoT application need toemploy low-cost devices for data collection and a low-complexity, self-managingIoT communication network to facilitate data transfer.In addition, we have to consider the unpredictability of the phenomenon weare observing. Data is collected only during seismic activity. Seismic events couldstrike consecutively in a matter of minutes or could be absent for years. There is nopredictability of when the application will be active, though it has to be on stand-byand fully operational at all times.4.2 Proposed Solution for Data Collection andPre-processingTo fulfill the requirements above, we propose deploying a dense network of low-cost IoT sensor devices, a Dense Network of IoT Sensors (DeNIS), outfitted withaccelerometers to collect ground acceleration data in real time, deliver it understrict time constraints to a pre-processing entity which will forward ordered, cleaneddata for analysis and allow the application to meet its goals.4.2.1 Physical Deployment of DeNISThe physical deployment of DeNIS will represent a grid of IoT nodes coveringthe City of Vancouver and Metro Vancouver area. Each node is an EEW IoT de-vice. Since devices are observing ground motion, accelerometers have to be firmlymounted to a structure or the ground. Communication antennas will be placedabove ground where connecting to the Rogers network is guaranteed.We envision EEW devices mounted to hard infrastructures like buildings, bridges47and tunnels, recording ground motion and the structural response to that groundmotion. Then, devices are stationary, their identity and the data each collects isassociated with a specific site/location.A Vancouver city block is approximately 100 square meters in length and theproposed deployment scenario results in a fine grid of devices placed approxi-mately 100 meters apart. This resolution in space allows us to capture the high-frequency, low-wavelength components of the seismic waveform.4.2.2 Physical Deployment of Data Collecting and Pre-processingServersThe EEW-SC application requires computational power for data collection, pre-processing and main processing. As we discussed in section 3.1.5, there are sev-eral drawbacks in transferring raw data directly to Cloud. A MEC solution for datacollection and pre-processing close to the data source, potentially in Vancouver orMetro Vancouver, will manage data in parallel from hundreds of thousands of de-vices, reducing propagation and data processing costs.Once cleaned and filtered on the edge, only data that is needed for further pro-cessing and analysis will be sent to Cloud. Hosting main computation and decision-making functions on Cloud secures sensitive data and delivers enough processingpower for coordinated analysis of the core data. This hybrid processing solutionwill meet the strict time constraints of the application and will deliver early eventdetection.4.2.3 The EEW-SC IoT Access Communication NetworkCommunication in the EEW-SC application is accomplished by IoT access networkbetween DeNIS and a Multi-access Edge Computing (MEC), called a EEW agent,and an IoT core network which connects the EEW agent to the hosted-on-CloudOngoing Processing Estimation and Notification (OPEN) where the applicationperforms its data analysis, decision-making and notification functions.48Figure 4.1: The EEW-SC IoT Network. IoT Access Network is mainly wire-less and IoT Core Network is wireline, with fibre optic cable as theprimary medium.As seen in figure 4.1, the IoT Access network consists of Rogers wireless andRogers backhaul to the MEC. This work covers the design of the communicationand data transfer mechanisms of the IoT Access network.Though wireline networks offer reliability and low latency, the accessibility ofsuch networks is a challenge for the intended location of our DeNIS sensor nodes.To establish communication for our application we are using a wireless connectionfor the IoT Access network. The 4G and 5G cellular network infrastructure alreadyexists and there is no cost for us in deploying such network.Besides available infrastructure, section 3.1.4 covered in detail the benefits ofusing cellular networks to facilitate communication in IoT, including quality ofservice indicators like reliability, security, delivery guarantees, bandwidth guaran-tees, stable service and minimum packet loss. Going a step further, in section 4.3we have examined how the application will perform under several 4G and 5G tech-49Figure 4.2: The EEW-SC Communication Protocol Stack based on IETFstack. Layers 1 through 3 provided by an IP-based cellular network.Layers 4 and 5 selected for minimum delay.nologies to select the optimal medium.Finally, the devices will communicate and transfer data to MEC directly, en-abled by the wide area network coverage. Since data collection for EEW-SC istime-constrained, local area networks and multi-hop communication are not a suit-able choice. They will contribute to data transfer delays, as per sections 3.1.4 and3.1.4.IoT Access Network Communication StackRogers cellular network has a mechanism for establishing an IP session that servesthe IP mechanism of the Network layer. 4G/LTE and 5G cellular networks areall-IP networks, all voice and data are carried in IP datagrams from/to the userequipment, therefore our IoT Access network is IP-based. EEW-SC, as many other50IoT systems, has organized its communication stack around the 5-layer architec-ture of the Internet Engineering Task Force (IETF) model, outlined in section 3.1.3.Transport LayerAs the application developers, we aimed to select the transport protocol that bestmatches our application’s needs. Timely data transfer is of prime importance to us.The application will not tollerate delays created by message retransmissions andhandshaking in establishing connection.From the two protocol options, compared in section 3.1.3, we chose UDP as ourtransport protocol. TCP’s time-consuming transfer guarantees and lengthy hand-shaking procedures when establishing a connection could result in large variationsin packet transfer times.UDP produces no delay to establish connection and adds only 8 bytes header tothe forwarded packets. Though unacknowledged method of packet transport, UDPwill have a predictable transfer time. With dense device deployment and redun-dancy in observation points, the application can afford to trade off some degree ofpacket loss for stable latency.Here, we make an important note: the application is tested to run with no traf-fic priority during an earthquake. Adverse events usually leave a communicationsnetwork working close to capacity. Using less overhead and optimizing the pack-ets for samples will avoid unneccesary transfers and use of already overextendednetwork resources.Application LayerWe utilized Constrained Application Protocol (CoAP) for application layer com-munication. Its advantages and the advantages of its REST mechanisms are listedin section 3.1.3. CoAP is based on request/response model and HTTP and its REST51architecture eases the operations of IoT applications.The combination CoAP over UDP is one of the most frequently used to en-able connection of sensor networks with the Internet [49]. Used with UDP , CoAPtransactions are time efficient and the communication cycle is faster than compa-rable implementations.With its basic 4-byte header, CoAP adds little overhead to packets. CoAP hasbetter bandwidth consumption than the publish/subscribe alternatives [45]. Theprotocol is also very versatile, supporting unicast, multicast and broadcast com-munication and device sleep mode. It offers block data transfer, and facilitatesautomatic connection refresh and over-the-air software updates. Applications un-der development, such as ours, rely on its flexibility to try different approaches inimplementation without heavy alterations to their overall architecture.As specified in section 3.1.3, protocols based on the request/response modelimplement servers that offer resources to a set of clients. A resource is anythingthat is observed. All resources are registerred in a Resource Directory which clientshave access to. The resource directory stores a current list of resources and theirdescriptions, identifies them uniquely, and periodically updates their availability.The protocol also offers a subscribe/notify feature called observation. Obser-vation is a way for the client to monitor the state of a resource without having torequest observations unnecessarily if there is nothing new. A client can sign upfor observation with a GET request. This adds the client to the list of observers.While repeated polling keeps track of the current state of a resource, opting forobservation ensure the client is kept aware of current and future representation ofthe resource.52M2M FrameworkIn EEW-SC, the mechanism of how information is exchanged between the server,the EEW device, and the client, the EEW agent, is handled by the M2M Framework[52]. Based on the standardized Lightweight M2M Protocol, the M2M Frameworkuses CoAP and manages communication between end points as well as processexecution and monitoring.The framework contains the following components: Device Model which han-dles device initialization and resource processing; Discovery and Registration forresource discovery and registration to the CoAP resource directory; Device Man-agement, responsible for device monitoring and session statistics; and Securitywhich integrates device security with the security features of the underlying proto-col layers.The M2M Framework is built in Python to run on an SBC with more resourcesthan constrained devices. It allows for fast prototyping and development of newdevice functionalities in the experimental stages of defining our application’s capa-bilities. Python is IoT platform developers’ programming language of choice dueto its flexible, easy-to-implement structure for experimentation [45].In summary, although our communication stack uses UDP as a transport pro-tocol, data transfer reliability is provided by the application. Guarantees such asindexing every sample sent are used. In addition, the Rogers network also providesbuilt in assurances, for example, it guarantees that packages arrive in order.4.2.4 Data Collection and Pre-processing MechanismThe massive deployment of tens to hundred thousand sensors we envision requiresa well-organized mechanism for data collection and an effective management oflarge quantities of packets arriving in seconds during the onset of an earthquake.From their stationary positions on the DeNIS grid, the EEW devices will be taskedwith recording a seismic wave moving at about 5 km/s. The collected data will be53used to reassemble in time and space the seismic waves propagating through thegrid.In the EEW-SC application, as in the majority of IoT applications, meaningfulresults can be drawn only when the collected data is correlated in time. Having acommon time is an important aspect of IoT and M2M communications. For ourapplication to trace the wave with high accuracy, the samples’ timestamp must beof high accuracy in relation to the grid and the entire EEW-SC application.In sensor networks, time synchronization is the most often implemented solu-tion when establishing common time among the nodes. This is achieved throughsome mechanism of communicating, negotiating and adjusting devices’ systemclocks until a common time is reached. However, the approach to common timedepends on the requirements of the application as well as the approach to and fre-quency of data gathering.Our EEW agents are hosted on MEC computers connected to the Rogers net-work. The agents’ clocks are stratum 2, and for the purposes of this work weconsider their time correct and common among all agents. Keeping in mind therequirements of the application, we explored several options in our effort to bringEEW devices to the agents’ common time.Currently deployed EEW systems use Global navigation satellite system (GNSS)as a time source for their stations [18], [13], [35]. After certain testing, this optionwas deemed not appropriate for us. The addition of GNSS hardware would add todeployment costs and would be in vain as the typical location of EEW-SC devicesis indoors or at the base of buildings or other infrastructure where GNSS signalsdo not reach.We considered time synchronization through Network Time Protocol (NTP).NTP is a centralized approach to time synchronization in which highly precisetime server is responsible for communicating correct time to devices. Computeror SP-based EEW networks such as QuakeCatcher and eQuake use NTP for syn-54chronization [36], [26], [24] and a similar lightweight synchronization mechanism,Timesync Protocol for Sensor Networks (TPSN), is commonly used in sensor net-works [44], [53].NTP is too complex for sensor networks that communicate over a wirelessmedium and its synchronization margin of error is highly dependent on the fre-quency of control message exchanges. Although better suited for SNs, still TPSNaccepts approximations such as: the delays on the network are constant and sym-metrical. Time synchronization can be made more precise or is needed less fre-quently with the use of a real time clock (RTC). RTCs are hardware add-ons thatimpact the cost of the IoT device.Inexpensive hardware systems like the EEW-SC devices are poor time keep-ers. Their intended deployment location will worsen the situation. Environmentalfactors like temperature, pressure, and humidity cause different drift rates amongdevices.Attempting to compensate for this through frequent time synchronization oradding hardware contradicts the low-cost, low-maintenance intend of the design.EEW-SC is a low-activity application that should require minimum to no main-tenance during hibernation. Lastly, the phenomenon the application monitors isunpredictable and synchronization cannot be performed in advance of a scheduleddata acquisition.Since devices are such poor time keepers and the efforts to make them bettertime keepers go beyond reasonable, lets ignore the time on devices all together.To keep with the intended application and to satisfy the tight timing requirementsof the application we developed the Asynchronous Sensor Coordination (ASC)scheme. In January 2021, Dr. Martı´ proposed that we accept the time on the EEWagent’s clock as absolute universal time and retrieve sensor samples from clock-less devices through query-based data acquisition.We are using query-based data collection to gather in real-time all observations55from asynchronous devices in an organized manner, so the EEW agent can order,clean and pre-process the data before it is forwarded to OPEN. This approachavoids lengthy and frequent time synchronization message exchanges and allowsthe system to remain in basic operational readiness until the onset of the seismicevent.At the onset, data collection is initiated by the EEW-SC EEW agent. The agentuses CoAP’s Request/Response message exchange to request the samples that de-vices have gathered. The clock-less EEW devices capture the ground accelerationsamples and hold the samples in storage until the request arrives. Each device re-sponds with a packet containing the latest sensor samples and the agent assigns auniversal timestamp to each received sample. The detailed procedure is discussedin section 4.5.3.4.3 Effect of Latency on Data CollectionConnectivity facilitates data collection and data collection produces a massive amountof network traffic that has to be managed in real-time. How the network steers thisprocess is very important, especially for a mission-critical application.The EEW-SC application cannot influence the network or redesign network op-eration. Our design is such that the application is adjusted and optimized to workon top of an already developed medium.In some cases, public safety networks have received preferential treatment oftheir traffic [54]. We only tested the EEW-SC network for operation in an environ-ment where the application’s traffic doesn’t get any priority and shares resourceswith non-time sensitive traffic.During this process we evaluated how well the network executes its intendedpurpose and functions in the case of data collection i.e. we evaluated the network’sperformance. The performance of communications networks is based on features56such as available throughput, experienced packet latency, and offered reliability.4.3.1 Network Performance-related TermsTo start, we offer definitions on the terms throughput, latency and some relevantnetwork hardships.Latency (or delay) is defined as the packet’s travel time. End-to-End (E2E) latency is the total packet travel time from source to destination.Round-trip time (RTT) is the time it takes for the packet to travel from source todestination and back to source. In IoT Request/Response architectures, RTT is alsodefined as request latency.Latency is affected by processing, transmission and propagation delays alongthe link from sender to receiver [27]. Both E2E latency and RTT will fluctuate dueto congestion and queuing at routers and varying load on end systems.One common network hardship is the variation in latency, referred to as jit-ter. We define jitter as the difference in round trip times between two consecutivepackets. A second network hardship is packet loss. These are the missing sourcepackets that the destination host did not receive. Packet loss results from the drop-ping of packets at routers with full processing queues.The average rate of transferring data, known as throughput, is an importantnetwork parameter. For IoT applications, the bandwidth or the maximum rate thenetwork can provide to an application indicates if the necessary data transfer canbe achieved.4.3.2 Performance Testing MethodologyTo meet the requirements of the application for high density of data points at di-verse locations and real-time constrained data collection we chose to transfer datawirelessly over a cellular network and to employ a minimum delay protocol stack,see section 4.2.3. In addition, we had to ensure that the application is deployed on57the “fastest” medium available.As our research commenced, Rogers Wireless had already extensive LTE cov-erage in Vancouver, including LTE Cat M1, an IoT-accommodating enhancementof LTE. In the process of the research, Rogers deployed 5th generation (Sub-6and mmWave) non-standalone technology implemented as a software upgrade tothe current network. As coverage was expanded on UBC campus to facilitate re-search, we examined how each of these four technologies impacts the behaviour ofEEW-SC and supports the application’s objectives.Test SetupOur hardware test system consisted of:• A laptop running Ubuntu 20.04 with a Linux kernel version 5.3.0-64-genericor a Raspberry Pi 4• A Quectel evaluation board with an embedded wireless module compatiblewith the technology observed.Table 4.1: Evaluated Wireless Access TechnologiesNetwork Technology Celluar Module RTT (request) Latency [ms]Average 95 PercentileLTE Cat M1 BG96 80.20 105.37LTE RM500Q/RM510Q 21.54 26.665G FR1 (Sub-6) RM500Q/RM510Q 11.81 18.415G FR2 (mmWave) RM510Q 9.34 11.84For Table 4.1, the connection to LTE Cat M1 was established using the BG96module, an LPWA LTE Cat M1 and NB-IoT module. We used the RM500Q-GLmodule to connect to 4G/LTE and 5G sub6 (FR1). 5G mmWave (FR2) access wasachieved using the RM510Q-GL module.58Figure 4.3: Latency Test SystemFigure 4.3 represents the link under evaluation: from the UBC Point Grey cam-pus to the Rogers MEC in Surrey, BC. The link consists of wireless and wirelinebackhaul connections.Objectives when TestingAssessing the network performance between our devices at UBC and the RogersMEC provides a view into the consistency of the network within the same area andanswers the question of whether devices within the same sector experience similarconnectivity conditions. Consistency will allow the sector’s agent to collect sam-ples from each device within approximately the same time, to accurately estimatesample times, and to consistently have pre-processed data readily available for thenext step of analysis.Since we look for consistency within a sector, testing network conditions inother parts of the city, was not necessary. Backhaul network processing will varywithin the city and latency to the same MEC will differ since packets are routeddifferently from different neighbourhoods.59During the initial design, we also sought to discover a predictability in the net-work’s behaviour by running tests with changing input characteristics. Our testsvaried in the throughput they allowed, how often a ping was sent, and what trans-port protocol was selected, and the time of day or day in the week we tested.LTE, LTE Cat M1 and FR1 measurements were taken from different indoor andoutdoor places. mmWave is available at six cells and measurements were taken atthe coverage sites.Testing ToolsWe utilized a number of network performance test tools, each producing informa-tion on a specific parameter or a set of parameters. We used Linux-based open-source tools such as iperf3, mtr and ping, and our own tool mec-test.iperf3 is a tool that measures throughput using TCP and UDP transport proto-cols. The iperf client device initiates testing with some conditions, the iperf serverreceives the client’s packets and at the end submits a report to the client of the av-erage throughput for the session.mtr stands for my-trace-route and determines the nodes between server andclient. The tool is useful in discovering bottlenecks along the link. Each nodereceives a series of Internet Control Message Protocol (ICMP) echo requests andresponds, while the client records the packets’ RTTs. The ping tool sends ICMPecho messages to the destination and waits for the response messages to recordRTT.mec-test is a MEC acceptance tool, developed by Dragan Andjelic for the pur-poses of testing Rogers Network for throughput and latency. The mec-client sendsconsecutive request packets to the mec-test server at MEC to which the server re-sponds.60We found this tool particulary useful for several reasons. Firstly, some routersblock and drop the Internet Control Message Protocol (ICMP) echo messages thatthe tools like mtr or pink send. mec-test messages pass through such firewalls andpacket loss is accurately represented. Secondly, our tool simulates the same Re-quest/Response environment that our application uses. Further, the requests andresponses are sent from the same layer as the main application and request latencymeasurements are fit to use in our virtual validation environment. Finally, each re-quest is sent only when the response to the previous request arrives. This approachavoids increasing the load on the network which could result in congestion, addi-tional delays and thus could skew our measurements.4.3.3 Conclusions on Network PerformanceWe collected extensive observations on request latency, throughput, jitter and packetloss and employed several techniques in their analysis. The detailed results andconclusions are confidential and will not be included in this work. Rogers Commu-nications have received thorough reports on network performance of the examinedwireless access technologies.Here we share generalized conclusions and observations.1. Any of the examined technologies can achieve the throughput we need.Even with increased sampling rate, for example 500 samples per second,the throughput we require is in the kilo-bits per second. By optimizing theuse of packet load space via binary encoding of samples the throughput isfurther kept low. We don’t foresee the need for higher bandwidth and evenLTE Cat M1 with channel bandwidth of only 1.4 MHz can provide us withenough transmission resources.2. Packet loss is negligible. Packet loss is not a critical issue for the application.The density of data points provides enough redundancy and the accuracy ofthe results will not be impacted by some loss of samples. Packet loss wasobserved to average around 2%. Notably, LTE, 5G sub6 and mmWave showgood reliability even when using UDP.613. Latency is the critical network parameter to consider when deciding whichtechnology is best for our application. Any of the above technologies cancarry data from DeNIS to the EEW processing agents, but not all would fa-cilitate delivery and processing in real-time. To reconstruct seismic waves ina meaningful way, we observe each period of the wave as soon as it is avail-able. Therefore, for the purposes of this application, we define processing inreal-time as reconstructing 1 period of a wave’s frequency component beforethe next period is generated.While the EEW processing agent acquires and pre-processes the data, theEEW Decision agent at OPEN reads the curated data. The interval betweenreads, also called a processing window, is set to the reconstruction period.Table 4.2: Earthquake Wave Frequencies and Sampling Frequencies. To cap-ture each frequency in the range of frequencies most damaging to struc-tures and reconstruct it with an error below 3%, EEW-SC must instructMSe stations to sample with a corresponding sampling frequency.Earthquake Wave SamplingFrequency[Hz] Period[ms] Frequency[Hz] Period[ms]0.1 10 000 1 1 0001 1 000 10 10010 100 100 1020 50 200 5For performance-based prediction, detecting earthquake wave’s frequenciesbetween 0.1 to 20 Hz is enough to predict the impact on most structures.These frequencies correspond to the resonant frequencies of most structuresand cause the most structural damage.For the highest frequency of concern, 20 Hz, to keep the error in reconstruct-ing the wave below 3% we sample at a frequency 10 times the frequencyobserved, therefore 200 Hz. According to table 4.2, to “see” and reconstruct6220 Hz frequency components as each period of the wave occurs, we need toreceive samples and process samples within 50 ms. That will be the lengthof the processing window. This implies that the request latency plus the pro-cessing time of the wave should be equal to or less than 50 ms.EEW-SC aims to provide a prediction update every 1 second. With a 50 msprocessing window we can observe the most destructive wave’s amplitudeand update 20 times before we offer an update in prediction. In one second,the lowest frequency with a period that can be fully observed is 1 Hz.Lower frequency components’ period, such as 0.1 Hz, cannot be fully ob-served in a short processing window. They would have to be be reconstructedusing signal processing.Referring back to table 4.1, the 50 ms processing window criteria eliminatesLTE Cat M1 from the possible solutions. On average, these requests willexperience over 80 ms latency, missing the processing window. The sampleswill be excluded from wave reconstruction.4. Jitter is proportional to the latency of the technology and it affects how wellASC performs estimations. Since the mechanism relies on RTT, or requestlatency, the variations in RTT create variations in the estimates between de-vices.LTE, 5G sub6 and mmWave technologies will fulfill the requirements. Whilethe optimal selection is using 5G, it is important that the MSe station is able to useany resource in the range of device deployment.Currently, 5G is a non-standalone configuration, the device will connect to ananchor LTE band and if 5G resources are available then the device will use them.Devices could be in areas where connecting to higher freqency bands, typicallyassociated with 5G, is challenging due to shadowing from large objects or foliage.63LTE coverage, delivered mostly by lower frequency bands, is much more compre-hensive and offers a wider coverage.Another point to consider is that restricting the application to rely on a singlenetwork technology will present a barrier to potential adoption and deployment.Additionally, during a seismic event some resources might become unavailable.The ability of DeNIS to operate on a wide range of options and adapt makes it agood candidate for areas that might not have 5g resources available and increasesits resiliency in disaster situations.4.4 A DeNIS/ EEW-SC Sensor NodeEach node in DeNIS is an EEW device. According to figure 4.4, the devices consistof sensing, processing and communication units and a power source. The sensingunit collects samples on ground acceleration, passes the data to processing whereeach sample receives an ID and a place in a storage queue. When a request forsamples arrives from the EEW agent, samples are packaged and passed to be trans-mitted to the agent.The device is always connected to power via an outlet. The network will be inoperation for years, with no predictability of the number of seismic events detectedor their duration. Therefore, it is difficult to assess the amount of power that a de-vice would consume and determine the battery size. In addition, an early warningand disaster mitigation application with battery powered sensor units runs the riskof suboptimal operation during an event. Units can be running out of battery powerif batteries do not get replaced in time.At deployment the device is mounted firmly to a wall or the ground and isconfigured. The device undergoes a start-up procedure to calibrate the sensor andconnects to DeNIS and the EEW-SC application’s Resource Directory whose URLis known. The device acquires a unique IP address and registers to the CoAP re-source directory with its unique ID and location (latitude and longitude) on the gridand receives a home sector. If the device disconnects from the application, it has64to be restarted. The cost of each unit is less than $100.In our research, the Mini Seismic Station units consist of an ADXL355 MEMSaccelerometer as a seismic sensing unit, a Raspberry Pi 4 SBC as a processingunit, and a number of wireless communication modules depending on the wirelessaccess network we were testing on. See figure 4.4.4.4.1 Sensing UnitThe ADXL355 accelerometer was selected and validated for the application in[55]. It is a low-cost, low-power (200 µ A in measurement mode, 21 µ A in standbymode) MEMS accelerometer [56]. It has an ultralow noise floor(22.5 µg/√Hz allaxes), a digital output (integrated 20-bit ADC), a minimal offset drift over temper-ature, for long-term stability-enabling precision applications with minimal calibra-tion. It measures 3-axis ground acceleration and the measurement range can beselected (ranges of± 2g,± 4g, and± 8g). The sensitivity specification for this ac-celerometer is considered very good [55]. One least significant bit is 3.9 µg/ in the± 2g operating range. MEMS accelerometers are ideal data sources for distributedseismic stations and are already used in other EEW applications [36].4.4.2 Processing UnitThe processing unit consists of a Raspberry Pi 4 [57], a low-cost SBC with 4 GBmemory and ARM CPU. The Raspberry Pi is equipped with a General-PurposeInput Output (GPIO) interface containing programmable GPIO pins. The board re-ceives input from the accelerometer and outputs data to the communications mod-ule over USB2.We used a standard keyboard and monitor to interact with the installed oper-ating system Raspberry Pi OS Lite headless, optimized for Raspberry Pi boards.The Raspberry Pi OS is based on the Debian Linux distribution which allowedus to utilize a number of tools and libraries during the development and testing.Throughout this research, the OS underwent several upgrades in version, includingkernel modifications to achieve compatibility with the 5G modules used.65Figure 4.4: The EEW-SC Sensor Node, consisting of ADXL355 accelerom-eter, Raspberry Pi 4 and a wireless communication module4.4.3 Communication UnitWe used several wireless communication modules for different network technolo-gies as discussed in section 4.3. Each device was outfitted with a Rogers networkSIM card which provides independent wireless connection to the Rogers MEC. Wecan refer back to table 4.1 for the list of modules.4.5 Data Collection and Pre-processing SystemOperation4.5.1 Steady State OperationAs discussed in section 4.2.3, once started, each Mini-seismic Station (MSe) de-vice applies for registration with the CoAP resource directory. The device mustsend a keep-alive signal to update its registration and a failure to update meansthat the device is out of reach (turned off, no reception, no access to network, mal-functioning, etc). If its registration is not updated the device is removed from theresource directory.With its registration, the device makes public a set of resources that it handles.The EEW agent queries the resource directory on a specific resource of interest,66for example the sensor resource, and receives a list of devices within the agent’ssector that offer that resource.The agent creates a local proxy for each device, a device twin, and interactswith the device through this proxy. Upon creation, the device twin has a genericcontent. The content is updated with device specific information once connectionbetween the device and the agent is established.Device twins contain some cached information on the devices: general infor-mation, configuration, etc. The agent does not need to request that informationfrom the physical device every time. If the device ceases to be on the resourcedirectory list, the agent is informed and the device twin is removed. Should thedevice re-register, its twin is added once more.As long as the devices keep up with their registration, there is no need forcommunication between agent and devices. The agent performs updates based oninformation from the resource directory. Communication might be triggered onlywhen maintenance or upgrades are underway.4.5.2 Operation During the Seismic EventThe EEW-SC application becomes active only when triggered. At the beginning ofthe seismic event, the application will receive notification from the sensor closestto the earthquake fault. The application will then trigger for operation and will no-tify all agents. The implementation of the initial notification lies beyond the scopeof this work.The operation during an earthquake event is divided into three parts and isdepicted on figures 4.5 through 4.7. The Request Engine, activated by the EEWagent, interacts with all devices in the sector. The devices are numbered 1 to N.67Initialization/Beginning of Earthquake EventTo start, the EEW agent initializes the Request Engine responsible for data collec-tion and pre-processing. The initialization procedure can be seen in diagram 4.5and proceeds as follows:1. The agent initilizes the Request Engine.2. The Request Engine updates the list of available devices that are within itssector.3. The Request Engine receives a response from the available and on-line de-vices.4. The Request Engine initializes sampling by instructing the MSe stations tobegin sample collection with a specific sampling rate and the number ofsamples they should include in a packet.5. Request Engine receives a positive response from the devices that are readyto sample.Data CollectionTo collect samples in an organized, synchronized manner, the Request Engine cre-ates a schedule for repeated requests to every device in the sector. The frequency ofrepeated requests depends on the device’s sampling rate, the size of the requestedpacket of samples, and the data redundancy needed.Data redundancy is achieved with a smaller interval between requests, ensur-ing that devices will not have time to generate enough new samples. Redundancyof 30% translates into 13 of the packet containing samples already seen in the lastpacket. As we described in section 4.3.3, to observe each period of the highest fre-quency of interest, 20 Hz, the application uses a 50 ms processing window. In thattime, it has to request, pre-process, align and interpret the latest data. To updateprediction every 1 second, twenty 50 ms processing windows are available. Dataredundancy could increase the fidelity of prediction for each processing windowwhere lost samples in the previous processing window could be taken into account68in the current.An advantage of building data redundancy handling into the system shows indeployments where MSe stations have different sampling rates. Request inter-vals could be set to sensors that sample faster and repeating samples from slow-sampling sensors could be sifted through.Redundancy could be a negative number if the application considers unneces-sary to obtain every generated sample. This approach will generate less traffic bythe application on the network.With equations 4.1 and 4.2 we can calculate the interval between requests toa single device. For example, if the device is instructed to sample with samplingrate of 100 samples/second and to include 10 samples in a packet and we require aredundancy of 0.3, then the agent sends a request every 70 ms.sampling interval =1sampling rate(4.1)request interval = S · sampling interval · (1− redundancy) (4.2)where:S is the number of samples requested in a packet and redundancy is a decimalbetween 0 and 1.Creating a schedule for repeated requests for every device, allows that deviceenough time to generate enough samples before the next request arrives. RequestEngine staggers the requests to the sector which staggers the arrival of data packetsfrom the devices in the sector. Packets are full and traffic is optimized.The design of the system also aims to complete every round of requests to the69sector within the processing window of the application, which is the interval be-tween data reads by the main application. The optimal length of the processingwindow was discussed in section 4.3.Data collection during the event is shown in diagram 4.6, and proceeds as fol-lows:6. For each sampling device in the sector, the Request Engine sends a requestfor samples, and starts the counter to the next scheduled request.7. As a response to the request, the device sends a packet with samples. Thepacket is forwarded for pre-processing.8. When the counter expires, the Request Engine sends another request for sam-ples.9. The device sends a response packet with samples.This Request/Response procedure loop iterates until the end of the earthquakeevent.End of Earthquake EventThe procedure at the end of the earthquake event is depicted on diagram 4.7 andproceeds in the following way:10. At the end of the earthquake event, the Request engine is instructed to dis-continue its requests for samples and to shut down.11. The Request Engine instructs devices to stop sample collection.12. The Request Engine receives confirmation that devices have stopped sam-pling.13. The Request Engine acknowledges shutdown to the agent.The system returns to steady state operation.70Figure 4.5: Beginning of Earthquake Event. The EEW agent initializes theRequest Engine to prepare all sector MSe stations for data collection.4.5.3 Asynchronous Sensor CoordinationAs established in section 4.2.4, the EEW-SC application considers the clock at theEEW agent to be universal time. The Asynchronous Sensor Coordination (ASC)mechanism’s mission is to synchronize the data flowing from all MSe stations inthe sector and to provide an estimate of the time of generation of every sample theagent receives.Packet Processing and Sample Time EstimationOne Request/Response exchange between the agent and a device is seen in diagram4.8. The Request Engine handles the packets from each device in the sector sep-71Figure 4.6: Data Collection during a Seismic Event. Request Engine per-forms repeated scheduled requests for samples to all devices. Each iter-ation of requests and responses, including pre-processing of the receivedsamples fit within one processing window.arately, and pre-processed data from every device is given a separate data buffer.With every Request/Response message exchange, Request Engine records the timeof sending the request, trequest , and the time of receiving a response, treceipt o f response.Upon receipt, the packet of samples is sent for pre-processing and sample time,ts, estimation. In pre-processing, the packet is checked for completeness and con-secutive sample ID’s. Sample times are estimated, and each sample, with its times-72Figure 4.7: End of Earthquake Event. The EEW agent instructs the RequestEngine to discontinue data collection before it shuts down.tamp and amplitude value, is moved into the device’s buffer to be read by theapplication in the present processing window.Currently, data redundancy is handled by keeping the first instance of the sam-ple and discarding the repeats. This ensures that the estimated sample timestampis closest to the time of sample generation, which minimizes the error in estimation.4.5.4 Sample Time EstimationMSe stations are clock-less devices. When the device receives the agent’s request itresponds immediately with a packet of the latest samples. To estimate in universaltime the timestamp of each sample, the agent operates on two assumptions:1. It is possible to estimate the universal time at which the agent’s request ar-rives at the device.2. The latest sample in the device’s buffer is generated at the moment when theagent’s request arrives.73Figure 4.8: A single ASC Request/Response exchange. The EEW agentrecords request and receipt of response on universal time.When the request is received, the devices respond immediately with the latestsamples. We assume that at device, the receipt of agent’s request coinsides with thegeneration of the latest sample. If we can estimate when the agent’s request arrivesat device, we can estimate when the latest sample was generated and calculate forthe rest of the samples using the interval between sample generation.To estimate the universal clock time when the request arrives at the device, theagent starts by calculating the request latency or the Round-trip time (RTT) withequation 4.3. The downlink portion of that time, as per equation 4.4, cannot beexplicitly found. It is a portion of the RTT and here we express the coefficientof that portion with K. Factor K’s value we determined through tests when wevalidated our solution. Then, the universal time of the agent’s request receipt at the74device is described in equation 4.5request latency = (treceipt o f response− trequest) (4.3)downlink delay = K · (treceipt o f response− trequest) (4.4)where:K is the coefficient of the portion of request latency assigned to the downlinkdelay.treceipt o f request = trequest +downlink delay (4.5)Once the time of receipt of the request is calculated, this value is assigned tothe timestamp of the latest sample in the packet, as per equation 4.6. The times-tamp of each previous sample is calculated by subtracting the interval of samplegeneration in equation 4.1 from the previous sample’s timestamp. See equation 4.7.tS = treceipt o f request (4.6)s ∈ (1, ..,S−1) ts = treceipt o f request− (S− s) · sampling interval (4.7)75Chapter 5Validation of the ProposedSolutionValidation of our proposed solution for communication and synchronization of datacollection requires a large number of devices. In the early stages of this research,with limited funding, validation is best achieved with virtual devices in a virtualtesting environment that simulates as close as possible the environment that thesystem will be deployed into.5.1 Testing EnvironmentThe full-scale testing environment we used to fine-tune the system is presented infigure 5.1. We built 15 headless VirtualBox virtual machine (VM)s, hosted on UBCserver running Ubuntu 20.04 Server OS. We installed Ubuntu 20.04 Server OS andincluded all tools and libraries needed to support the EEW device, the communica-tion and data collection mechanisms described in sections 4.2.3 to 4.2.4, includingCoAP and m2m framework libraries. The virtual devices are identical to the phys-ical MSe stations in terms of software and operation.To get access to the Internet, each VM uses a bridged adapter as the virtualnetwork adapter, which bridges the physical connection straight to the VM so VM76Figure 5.1: EEW-SC Virtual Testing Environment. 15 virtual EEW devicesare hosted on the UBC server. The EEW agent and the Resource Direc-tory are hosted on Rogers MEC.can have an IP address on the network. Permanent IP address was assigned to eachVM and we were able to interact with them remotely. The VMs had their systemclocks synchronized with the EEW agent over NTP.The EEW MEC Agent, a real processing agent, and the CoAP Resource Di-rectory were hosted on virtual machines on the Rogers 32 GB, 8-CPU core MEClocated in Surrey, BC.To simulate seismic sample collection, we used per-recorded earthquake datafrom Natural Resources Canada [58]. The pre-recorded data was read into the de-vice buffer at the same rate as the sampling rate communicated to the device at thestart of sampling.5.1.1 Simulating Wireless Network BehaviourWireline network connects the UBC Server hosting the EEW virtual devices to theInternet and the Rogers MEC. The behaviour of this communication setup doesnot reflect the characteristics of the wireless medium that the MSe stations willexperience when deployed. To give the system realistic behaviour, we prepared a77simulation of the cellular network the devices will experience in-field.To simulate Rogers 4G and 5G we prepared and introduced artificial latencies,using the NetEm tool. NetEm is open-source, readily available on Linux distri-butions and works with UDP protocol [59]. In addition, the tool has been wellstudied, it was relatively easy to use and configure and no specialized equipmentwas needed. NetEm shapes the traffic of the Ethernet interface by imposing a delayon each packet through the interface.To reproduce the random nature of delays and jitter in wireless communica-tions, we gave the agent and device NetEm interfaces delays from custom latencydistributions. These custom distributions were prepared from the latency measure-ments collected during our network evaluation.The latency measurements are of round trip times of Request/Response pack-ets. There is no concrete way to determine E2E delays from RTT measurements.As we discussed in 4.3, RTT is a function of several delays, some random in nature.Although accepting E2E delay as 12 of RTT is an industry practice [27], asymmetryin the network is possible and neededs to be accounted for in testing.To account for the randomness and asymmetry of cellular networks, we pre-pared pairs of distribution tables for downlink and uplink latencies for LTE, FR1and FR2 with different portion of RTT given to the downlink and uplink delays.Equations 5.1 and 5.2 demonstrate how each entry in the distributions was pre-pared. The values of the E2E delays were allowed to vary between 0.3 to 0.7 ofRTT. See Table 5.1 for LTE distributions. Similar tables were created for FR1 andFR2.For each technology, for each RTT measurement:NetEmDL,distro entry = RT T · portion downlink−wirelineDL (5.1)78NetEmUL,distro entry = RT T · (1− portion downlink)−wirelineUL(5.2)Both NetEm interfaces were configured to experience delays: the agent’s re-quests travelling downlink and the device’s responses travelling uplink. Artificialdelays were corrected for the default wireline latency in the environment.Table 5.1: NetEm Distributions for LTENetwork Technology Latency Asymmetry [Portion of RTT]Downlink UplinkLTE 0.3 0.7LTE 0.4 0.6LTE 0.45 0.55LTE 0.5 0.5LTE 0.7 0.3LTE 0.6 0.4LTE 0.55 0.455.1.2 Reference Parameters and ValuesWe created reference parameters which we used as a benchmark to evaluate theaccuracy of ASC and the estimation of sample timestamps. In the controlled en-vironment, reference values are sample timestamps on an EEW device which ison EEW-SC universal time. To obtain these values, we implemented a procedurewhere statistics are calculated for every Agent-device interaction. The MEC serveris on EEW-SC universal time and EEW virtual devices have their clocks synchro-nized with NTP. Further, we calculated the instantaneous clock offset between thetwo machines. We corrected the reference values for clock offset to bring them asclose to EEW-SC universal time as possible.The response packet from the device was expanded to contain the time of re-ceipt of the agent’s request, the time of device response, each sample’s ID, sam-79Figure 5.2: TPSN Message Exchange for Clock Offset Calculationple timestamp and sampled wave amplitude. The data is in JSON format and themaximum Transmission Unit IPV4 is 1460 Bytes. We limited the packet size to10 samples. Including more samples risked packet fragmentation and fragmentedpackets might be dropped by routers along the path. This would have inflated thepacket loss and negatively affected our tests.5.1.3 Clock OffsetInstantaneous clock offset between virtual environment hosts is calculated on ev-ery Request/Response exchange and applied in calculations. We used the sameapproach to clock offset calculation as Timesync Protocol for Sensor Networks(TPSN) [53]. TPSN synchronization message exchange is seen in diagram 5.2.The client issues a synchronization pulse at T1. The message is received by theserver at T2 and the server responds with an acknowledgement at T3. The clientreceives the packet at T4. The client calculates its clock offset with equation 5.3.TPSN assumes that the delay does not change during the brief message exchangeand therefore the E2E delay is one-half of the round trip time.o f f set =(T 2−T 1)− (T 4−T 3)2(5.3)80Figure 5.3: A single instance of an ASC Request/Response in the virtual val-idation environment. The EEW agent and the virtual EEW device areboth on universal time. The times recorded on the device are used tovalidate the agent’s estimates.5.2 Testing MethodologyControlled environment tests were performed to determine if ASC is successfullycoordinating and collecting the correct data from multiple sensors in network con-ditions where the asymmetry of the latency and the type of technology varies. Wedefined success in two ways, firstly, with the high accuracy that ASC shows in theestimation of sample times. Estimation accuracy is achieved by bringing estimatesas close as possible to reference values by tuning factor K, the coefficient of theportion of RTT assigned to downlink. Further, we had to demonstrate that the typeof network technology affects our estimates with the optimal factor K. Secondly,we aimed to show that ASC accuracy is consistent for multiple devices, both whenthe devices are positioned at the same location and when positioned a distanceaway.815.2.1 Data Collection TestsThe tests consisted of simulated operation during a seismic event as described indiagrams 4.5, 4.6, and 4.7. As in diagram 4.5, sampling is initialized by the Re-quest Engine with a predetermined sampling rate of 100 samples/second and 10samples in a packet. Request Engine calculates the interval between requests, us-ing equations 4.1 and 4.2, and repeats requests to each device.The particulars of one Request/Response exchange in the validation stage areshown in Figure 5.3, where we consider the device to be on EEW-SC universal timeand collect reference values from that device. In addition to collecting referencevalues from the device, during validation, the Request Engine processes the testpacket with samples in the following way:1. ASC calculations: estimate the time of receipt of request at device with equa-tion 5.4, as the deployed mechanism would.2. Reference value calculations, performed only during validation:(a) Calculate the clock offset between the agent and the device with equa-tion 5.5.(b) Correct the device’s time of receipt of the request to universal time withequation 5.6.treceipt o f request, estimated = trequest +K · (treceipt o f response− trequest) (5.4)clock o f f set =(treceipt o f response− tresponse)− (treceipt o f request− trequest)2(5.5)82treceipt o f request, re f erence = treceipt o f request at device− clock o f f set (5.6)These estimated and reference values are recorded in a validation database andused in error calculations.5.2.2 ASC Accuracy and Validating Factor KThe optimal factor K, the coefficient describing the downlink portion of the round-trip time, is such that it minimizes the error between the estimated receipt of therequest, treceipt o f request, estimated , and the receipt of request at device on universaltime, treceipt o f request, re f erence.The procedure we followed during our tests goes through the outlined steps:1. We apply the pair of artificial latencies for downlink and uplink.Before running a during-event test, the agent and the devices’ NetEm in-terfaces are modified. For example, referring back to table 5.1, if the pairNetEm distributions applied are on line 1, then the delay distribution appliedto the agent is LTE downlink 0.3, and the uplink delays at the device aredrawn from the LTE 0.7 distribution.2. We run data collection tests with varying factor K in the estimate calcula-tions.3. We record the results and calculate the estimation error.4. We remove NetEm configuration.Table 5.2 shows an example of the testing parameters on FR1. Columns 1 and2 contain respectively the downlink and uplink NetEm delays. Column 3 is thevariation in factor K and column 4 is the error between the estimated and referencetime of receipt of request at device, calculated with equation 5.7. The same roundof tests was performed for LTE and FR2.83Table 5.2: Estimation Error on FR1 with Factor K ranging from 0.3 to 0.7.Columns 1 and 2 show the asymmetry in latency applied with NetEm,column 3 shows factor K value and column 4 indicates the estimationerror produced with these variables.Latency Asymmetry [Portion of RTT] Factor K EstimationError [ms]Downlink Uplink0.4 0.6 0.3 3.0550.4 0.6 0.4 1.2840.4 0.6 0.5 0.4540.4 0.6 0.6 2.1750.4 0.6 0.7 3.9440.5 0.5 0.3 3.1110.5 0.5 0.4 1.3340.5 0.5 0.5 0.4250.5 0.5 0.6 2.1760.5 0.5 0.7 3.9030.6 0.4 0.3 3.0320.6 0.4 0.4 1.3360.6 0.4 0.5 0.4480.6 0.4 0.6 8.5280.6 0.4 0.7 3.9935.2.3 Conclusions on Factor KDepending on deployment location and connectivity resources the devices mightuse a different technology to connect and send data. A measure of estimationaccuracy is a factor K that minimizes the error in estimated time of receipt ofagent’s request, regardless of network behaviour or technology.For all three technologies a factor K of 0.5 shows to minimize the estimation errorto below half a millisecond. Table 5.3 is a summary for all technologies withvarying latency asymmetry and K = 0.5.84Table 5.3: Estimation Error on LTE, FR1 and FR2 with Factor K = 0.5. Theerror is bouned regardless of the technology or the latency asymmetryintroduced with NetEm.Technology Latency Asymmetry [Portion of RTT] EstimationError [ms]Downlink UplinkLTE 0.3 0.7 0.460LTE 0.45 0.55 0.464LTE 0.6 0.4 0.458FR1 0.4 0.6 0.454FR1 0.45 0.55 0.472FR1 0.55 0.45 0.432FR1 0.6 0.4 0.448FR2 0.4 0.6 0.459FR2 0.45 0.55 0.468FR2 0.55 0.45 0.438FR2 0.6 0.4 0.4645.2.4 ASC ConsistencyWith factor K accepted as 0.5, we performed multi-device tests to determine if ASCis consistently estimating the devices’ timestamps with minimum error. These sim-ulations were performed with both devices on the same network technology. Theagent sends requests through the same NetEm interface that draws samples fromone downlink distribution. Therefore, both devices have NetEm interfaces drawinglatency samples from the same uplink distribution.We simulated data collection for two scenarios: devices at the same physicallocation and devices situated some distance apart. In the simulation with devicesat the same physical location, the devices started sampling at the same time i.e.replaying the same earthquake data starting at t = 0. That results of that scenario isdepicted in figure 5.4.We also tested if ASC is consistent when devices are located some distancesapart. Figure 5.5 relates to the scenario where the earthquake wave arrives at the85Figure 5.4: Estimated Sample Timestamps of Two colocated Devices. Thesamples are generated by devices at the same location, detecting thesame earthquake wave. ASC accurately estimates the same timestampsfor the samples from both devices.first device at t = 0 and at the second device 300 milliseconds later.5.3 Results and Sources of Error5.3.1 Sources of ErrorEstimation errorASC accuracy was determined by evaluating the error between the estimated treceipt o f request estimatedand the reference treceipt o f request re f erence time of receipt of the request at the device.This difference between the estimate and the reference is the estimation error. Re-fer to equation 5.7.Here, we calculate and report the mean absolute estimation error over the entirebatch of samples in a given data collection test. See equation 5.8. The mean abso-86Figure 5.5: Estimated Sample Timestamps of Two Devices Spaced Apart.The samples are generated by device 1 at t = 0 location, device 2 detectsthe same point of the earthquake wave at t = 300 ms. ASC accuratelyestimates the timestamps for the samples from both devices with 300ms difference.lute error is the estimation error reported in tables 5.2 and 5.3. Estimation error, isdependant on the variations in RTT, known as jitter.Absolute error = |Valestimated−Valre f erence| (5.7)Mean absolute error =1NN∑n=1|Valestimated−Valre f erence| (5.8)Sampling ErrorASC makes an assumption that the agent’s request arrives at the device exactlywhen the latest sample is generated. In reality, the agent’s request can appear any87time between two neighbouring samples having been generated. The time inter-val between samples depends on the sampling rate. With equation 4.1 we canconclude that if the sampling rate of the device is 100 samples/second, then theinterval between two samples is 10 ms. Therefore, the maximum sampling errorwe can experience with this sampling rate is ±5ms. Sampling error is minimizedthe faster we sample, for example at 500 samples/second sampling rate, this erroris only ±1ms. Sampling faster, however, will increase the traffic the applicationgenerates to collect the larger amount of samples.Clock Offset ErrorTPSN clock offset calculation makes the approximation that the E2E delay is 12 ofthe round trip time. This approximation will add some uncertainty to our referencevalues. This uncertainty will affect our estimation error.Timestamp ErrorRecall that the estimated time of receipt of request, treceipt o f request estimated , the agentassigns to the latest sample in the packet tS. The total error between our estimateof tS and the actual timestamp of the latest sample is the sum of the estimation andsampling errors. Refer to equation 5.9. We refer to this error as the timestamperror.Timestamp error is a function of estimation error and sampling error and is furtherinfluenced by the uncertainty from the approximations in clock offset calculation.Timestamp error = estimation error+ sampling error (5.9)5.3.2 Relative ErrorThe main purpose for data collection is to provide samples in time that the appli-cation can trace the wave device to device. The system relies that the estimated88timestamps of a data point on the wave moving through the DeNIS grid will givean accurate representation of how the data point moved through the grid in space.That means that for colocated devices we expect the same estimate on the times-tamp of the data point. For devices a distance apart, the estimate of the timestampwill differ as a function of the distance between the devices and the velocity of theearthquake wave.In perspective, the timestamp errors in the estimates compared to the referencetime are not as important as how accurate are the estimated timestamps of the dif-ferent devices in relation to the devices’ placement on the grid. The relative erroris the error between the estimated timestamps of the samples of two devices.The timestamp error showed little variation during our tests. If the same abso-lute error exists for all devices in the grid then we should expect that the relativeerror should be insignificant.The system relies that if devices are colocated, the same sample of the earth-quake wave will be detected at the same time by both devices and the estimatedtimestamp of the sample from the first device will be equal to the estimated times-tamp of the sample from the second device.5.3.3 Results and Conclusions on ValidationWe expect some variation in the timestamp error for the estimated timestamps ofthe two virtual devices even when devices are in a controlled environment becausewireless communication is simulated with its characteristic jitter.Referring back to figure 5.4 to the test with two colocated devices, for bothdevices sampling starts at t=0, the estimation error for device 1 is 0.435 ms and fordevice 2 is 0.454 ms. The average sampling error for device 1 is 3.514 ms and fordevice 2 is 3.627 ms. The average relative error between the estimated timestampswas 0.002 ms. We can see that the estimated timestamps of the first device, repre-89sented by red circles, coinside with the estimated timestamps of the second devicerepresented by blue squares.In figure 5.5 the two devices are 1.2 km apart and we aimed to confirm that thesame data point detected at device 1 at t = 0 was detected at device 2 at t = 300and that consistency would exist with all data points in the test. That will informif the approach is consistent in tracing the wave. The timestamp error for device1 is 0.433 ms and the timestamp error for device 2 is 0.447 ms, sampling errorfor device 1 is 5.369 ms and for device 2 is 3.896 ms the relative error is 0.008milliseconds.In both cases, collocated and separated devices, the relative error is insignif-icant. The samples of the wave they have recorded are estimated to have beenacquired at the same time which proves ASC’s consistency in estimation regard-less of jitter and sampling difference.In reality, devices will not start their sensors at exactly the same time. Therewill be variations in sampling and environmental factors will contribute to mis-alignment,jitter will further contribute to estimation error. With the AsynchronousSensor Coordination (ASC) scheme for data collection these variations should besmoothed out and the relative error between the sensors on the grid is very insignif-icant.In conclusion, the above validation tests and procedures in our virtual environ-ment show that ASC is successfully coordinating and collecting the correct datafrom multiple sensors in network conditions where the asymmetry of the latencyand the type of technology varies. ASC estimates sample times with high accuracywith factor K of 0.5 in all tested types of network technologies. ASC is consistentin its accuracy for multiple devices in their various relative positions on the grid.With the validated approach to sensor network coordination, the followingchapter is dedicated to in-field tests on the Rogers cellular network.90Chapter 6In-field Testing and Discussion ofResultsFollowing validating our sensor synchronization and data collection setup, we in-troduced real EEW devices, the Mini-seismic Station (MSe) stations, to the EEWAgent to observe how system behaviour and accuracy change on the actual cellularnetwork. This chapter addresses the results and observations from the EEW-SCin-field tests. We describe the scenario, tests and the results we selected to bestvalidate our solution in actual deployment conditions.6.1 In-field Test Scenario6.1.1 Site SelectionEEW-SC was developed and tested on the University of British Columbia campus.The campus has a unique location on a peninsula, where earthquake waves aremost likely to come from West -South West.It was important to have as much distance as possible between the test sensors.We chose a scenario of three MSe stations to simulate an earthquake arriving fromthe South West and getting detected at first, second and third devices. Our testbed91Figure 6.1: EEW-SC Three-device In-field Testing Scenario. MSes at eachof the three locations forming a triangle. Rogers LTE and FR1 coverageis available across the UBC campus. FR2 coverage is available at thethree MSe locations.92layout is a triangle with sides 600 m, 1100 m and 1600 m, which are the distancesbetween the sensors. In figure 6.1, the test scenario is layed out on a map of theUBC campus, including the distances between the three sensors and the directionof the earthquake.The locations of the cells have been chosen to give a triangular shape of thetestbed so that if an earthquake hits from any direction, we can still be able toobserve a wave travelling from one station to another. These MSe stations are con-nected to our EEW MEC agent located on Rogers MEC. No modifications wererequired on the agent side, because, as we stated in section 5.1, virtual EEW de-vices and MSe stations are thus far identical in software and operation.During the time of this research, Rogers Communications was selecting loca-tions for mmWave small cells to accommodate the needs of our and other researchprojects. Our three MSe stations can operate on mmWave and are assumed to becollocated with the Rogers small cells. The location of the small cells is also indi-cated on Figure 6.1, while LTE and FR1 coverage is available across campus.6.1.2 Test DataOur in-field testing aimed to validate the solution described in the above chaptersthrough a real world deployment operating on the actual communications network.An earthquake wave is comprised of varied frequencies. Frequencies between 1and 20 Hz are an adequate range for damage assessment to most structures. That isthe frequency range that will determine if the performance of DeNIS is acceptablefor the EEW-SC application.For in-field testing we created and transmitted pure sine waves of the funda-mental frequencies of 1 Hz, 5 Hz, 10 Hz, and 20 Hz and observed how well thesystem reconstructs and traces these frequencies. We view the reference waves asgenerated by an ideal accellerometer with ideal sampling and timestamping.93The reference sine waves amplitude and time data points are generated inPython. The amplitude points are the same for all three dimensions and are writtento a csv file, with each x, y, z point on a separate line. All reference waves have asampling rate of a minimum 10 points per period, which produces 3% or less error.1 Hz, 5 Hz and 10 Hz are sampled with 100 samples/second. 20 Hz is sampled with200 samples/second. Each reference wave contains 10 000 sample points. Refer totable 6.1 for overview of frequency components and sampling rates.S-wave attenuation is insignificant for the distances between our test locations;therefore, we have assumed no attenuation in the wave’s amplitude, regardless ofthe frequency, all travelling at 5 km/s and all sensors transmitting the same ampli-tude points.The CSV files containing the amplitude points of the reference waves are thenadded to the waveforms that the MSe station can replay through its replay function.Similar to our virtual EEW devices, the MSe station start to replay the fundamentalfrequency data file with the sampling rate provided by the agent at the time of thestart of the sampling.6.1.3 In-field Testing MethodologyAs we described in section 4.4, the MSe stations were outfitted with a QualcommRM510Q-GL module and were positioned in the environment and connected toone of the technologies and communicating with EEW agent and resource direc-tory over Rogers cellular network.Modifications to connectivity were made at the time of the test, depending onthe cellular technology being tested. When testing on LTE, 5G mode on the mod-ule is disabled. When testing on sub6/FR1, device modules have 5G enabled arelocked on band n41, corresponding to Rogers 2.5 GHz frequency. When testingon mmWave/FR2, device modules have 5G enabled and are locked on band n261.For the mmWave tests, the devices had to be within mmWave coverage at the small94cell site indicated in 6.1.In tests with multiple devices, we needed to simulate a travelling earthquakewave reaching the first, then second and then third devices. The spatial distancebetween the devices was simulated with a delay to the start of sampling in the sec-ond and third devices.We assumed that the earthquake wave travels at 5 km/s and arrives at the firstdevice at t = 0, at the second device some ∆t later. Equation 6.1 introduces thecalculation of delays. Table 6.2 shows the distances between the trio devices andthe delays the devices will experience in detecting the wave.Table 6.1: Tested Fundamental Frequencies and Associated Sampling RatesFrequency Component Sampling Rate [samples/second]1 Hz 1005 Hz 10010 Hz 10020 Hz 200Table 6.2: Distances between MSe stations and Corresponding Delays inSamplingDistance from 1st MSe sta-tion[m]Delay in Sampling [s]0 0600 0.121100 0.221600 0.32tdelay[s] =distance[km]speedwave kms=distance[km]5 kms(6.1)95For each scenario the first sensor transmits the first data point at t = 0 and thesecond sensor transmits the first data point with the predetermined delay. The pro-cedure is similar to our validation tests procedure in section 5.2. When the replayfunction is asked to start sampling, it replays the first line in the CSV file corre-sponding to the wave’s amplitude at t = 0. The sampling rates of the device and thesampling rate of the reference wave points are the same. If the wave was createdwith 100 samples/second then it is sampled by device with 100 samples/second toensure the comparison of the reference and the estimated timestamps is valid.Similarly to our virtual EEW test devices, the MSe stations return 10 samplesin a packet. The rest of the contents of the packet depended on the test. Belowwe discuss several tests, including single-device tests, wave tracing with multipledevices, and ASC and Network Time Protocol (NTP) comparison tests.6.2 Comparison of Reference Waves with WavesCaptured by In-field MSe StationsIn these single-device tests, we compared the performance of our system in trans-mitting a perfect sine wave and estimating the timestamps of the wave points. Asstated, there is no attenuation to the reference waves at these small distances. Ourtask was to evaluate the correctness of the estimated timestamps against the gener-ated reference timestamps of the time-amplitude data point pairs.Refer to Figure 6.2 for a visual comparison between reference and estimatedwave. It is evident that the estimated wave follows the reference 1 Hz wave trans-mitted very closely. Figure 6.3 compares LTE, FR1 and FR2 estimations for thesame 1 Hz reference. Here we observe that the tests on FR1 and FR2 provide ex-cellent results in estimation. However, the test on LTE experiences a temporaryerror. Later in section 6.5.1 we discuss the causes of such deviations from the cor-rect estimates resulting from latency variations.96In these tests we are evaluating the timestamp error with reference to section5.3.1, this is an error in both estimation and sampling. Timestamp error absorbsclock and network inconsistencies. The timestamp root mean square error betweenreference and estimated timestamps can be calculated with equation 6.2.RMSE =√ΣNn=1(tn,re f erence− tn,predicted)2 (6.2)where N is the number of sensor data points collected.Table 6.3: Average Timestamp Error [ms]. Frequency Component vs CellularTechnologyF-cy Component LTE FR1 FR21 Hz 5.52 ms 5.27 ms 5.20 ms5 Hz 5.53 ms 5.23 ms 5.22 ms10 Hz 5.53 ms 5.24 ms 5.19 ms20 Hz 4.21 ms 4.01 ms 3.98 msSection 5.3.3 already discussed timestamp error in the virtual environment andsampling error is the biggest contributor to timestamp error. In tests, 1 Hz, 5 Hz,and 10 Hz are sampled with 100 samples/second, leading to an average of 5 mssampling error. As sampling rate doubles to 200 samples/second in 20 Hz, thesampling error falls to an average of 2.5 ms.Refering to Table 6.3, the average timestamp error is still dominated by sam-pling error, as it was in our validation test results. Estimation error is on averageless than 0.5ms and is minimized when testing on 5G. In-field estimation error islarger compared to the virtual environment estimation error. This is the result ofdeparting from the near-ideal conditions of the virtual environment and estimatingtimestamps on the network where we share resources and latency fluctuates morefrequently.Although the sampling error for 20 Hz averages 2.5 ms, the estimation error ishigher than the corresponding error in the lower frequencies. The increased traf-97Figure 6.2: Reference and Captured Waves Compared.fic in retrieving the 20 Hz samples caused some hardship and larger variations inlatency when sharing resources was more frequent. We discuss the causes behindthe larger errors in section 6.5.1.6.3 Tracing the Reference Wave with Multiple DevicesSince DeNIS will be deployed to trace earthquake waves as they travel, it is im-portant to evaluate how well our system is able to trace each of the fundamentalfrequencies. Namely, when the wave is transmitted by two devices, some distanceapart, what is the relative error between devices in timestamps. In section 5.3.3,relative error was defined as the difference in estimated timestamps between thesamples collected by two devices.In Table 6.3 we reported average timestamp error. In the following sections,instead of relative error calculations, we use graphs as a representation of tracing ofwaves. We consider this approach better for visualization of the test results. Figure98Figure 6.3: Reference Wave Captured with Three Cellular Technologies. Anexample of the same reference wave captured with LTE, FR1, and FR2.The wave estimated on LTE is experiencing a temporary error in esti-mation.6.4 depicts tracing the wave in our test scenario in figure 6.1. The wave is recordedby the device at the first location and shortly after by the device in the next location.The phase shift in the sine wave corresponds to the physical travelling time of theearthquake wave.Throughout testing, we varied the cellular technology the devices were con-nected to, the frequency component and the distance between devices in our sce-nario.Figures 6.5 and 6.6 show devices on the same technology tracing the highestfrequency wave component of interest, 20 Hz. The wave is traced well with mi-nor distortion. The quality of tracing when devices are on the same technology iswithin the acceptable, regardless of the frequency component traced or the cellulartechnology.99Figure 6.4: 1 Hz Wave Captured by MSes at locations 2 and 3, 600 m aparton FR1. The MSe at location 2 detects the wave first and 0.12 secondslater, the MSe station at location 3 detects the wave.Figure 6.5: 20 Hz Wave Captured by MSe stations at locations 2 and 3, 600m apart on LTE.100Figure 6.6: 20 Hz Wave Captured by MSe stations at locations 1 and 3, 1600m apart on FR2.6.3.1 Tracing with MSe Stations on Different TechnologiesWe aimed to determine if tracing the wave is less exact when the devices are ondifferent technologies. The drawback of having the system dependent on one cel-lular technology is to limit the deployment locations to where there is coverage.This is discussed in more detail in section 4.3.Figure 6.7 represents an instance where the MSe station first to detect the waveis operating on LTE and the MSe station second to detect the wave is operating onFR2. Figure 6.8 depicts the opposite scenario; the first MSe station operates onFR2, and the second is connected to LTE.As evident from the figures, although the slower technology, LTE is prone tohigher timestamp error due to higher roundtrip times, tracing accuracy is very goodwith no significant distortion.101Figure 6.7: 1 Hz Wave Captured by MSes at locations 1 and 3, 1600 m apart.The MSe at location 1 transmits on LTE, and the MSe at location 3transmits on FR2.6.3.2 Distance between MSe Stations and its Relationship toAccuracyDeploying a dense network of MSe stations at once might not be possible due tothe financial commitment required. We have to ensure that the system can workaccurately even when the density of sensors is smaller than required to make dam-age assessments for every asset.Figures 6.9, 6.10 and 6.11 depict a scenario where the same wave component iscaptured at our three locations. Referring back to Table 6.2, the first device detectsthe wave at t = 0; the start of sampling for the second device is delayed to accountfor the distance the wave travels between locations 1 and 2. Similarly, the start ofsampling for the device at location 3 is delayed to account for the distance between1 and 3. And finally the delay between location 2 and 3 is captured. The sample102Figure 6.8: 20 Hz Wave Captured by MSes at locations 1 and 3, 1600 mapart. The MSe at location 1 transmits on FR2, and the MSe at location3 transmits on LTE.timestamps for both devices are estimated by the EEW agent.Figures 6.9 to 6.11 show that the distance between the sensors is not an error-contributing factor. Similar relative error was experienced in tracing tests with 600m between devices and tracing tests with 1600 m between devices. Because thenetwork is consistent in the latencies it produces, larger distances did not contributein a significant way to the error in estimation. We confirmed that these results areconsistent for each frequency component and each technology.Several conclusions can be made as a result of our in-field tests. Firstly, al-though technologies with smaller RTT and less jitter work better, all three tech-nologies tested perform well into the acceptable error and can be used for oursystem. This makes the system robust and versatile in both communication andlocation of deployment.103Figure 6.9: MSe Stations 600 m apart Tracing a 1 Hz WaveFigure 6.10: MSe Stations 1100 m apart Tracing a 1 Hz Wave104Figure 6.11: MSe Stations 1600 m apart Tracing a 1 Hz WaveFurther, all relevant frequencies can be captured correctly by our system. Wecan conclude that DeNIS captures the seismic wave and its travelling time is cor-rectly detected by the sensors and estimated by the Asynchronous Sensor Coordi-nation (ASC). Its application to detecting earthquake waves is definitively proven.Distance between sensors is not an error contributing factor, implying that the gridof MSe stations can densify over time.6.4 ASC Performance Compared to NTPOnce validated in-field, we tested the solution with the wave traced with ASCagainst the wave traced by Network Time Protocol (NTP) synchronized devices.NTP is the default time synchronization protocol for all Internet-connected de-vices. As a reminder, NTP, as ASC assumes that uplink delay is equal to downlinkdelay in its approach to client-server clock synchronization.For the tests the Raspberry Pi 4 system clocks were synchronized every 64 sec-105onds with stratum 2 NTP servers. Due to restrictions on the servers, 64 secondsis the most frequent polling interval that can be set. Connected to the university’sWi-Fi over the wlan interface, the Raspberry Pi units were synchronized using theRaspberry Pi OS chrony service. Since the Rogers MEC is also synchronized withstratum 2 servers, we assume that both MSe stations and EEW MEC agent are onuniversal time.The following figures demonstrate the performance in tracing the wave be-tween the sample timestamps estimated with ASC and those recorded with anNTP-synchronized device. We put forward two instances, 6.12a, where the MSestation is connected to FR2, and 6.12b, where the MSe station is connected to LTE.In these instances, the clock synchronization is incorrect, resulting in a consistenterror in the NTP-generated timestamps. In contrast to errors in ASC-estimatedtimestamps, corrected within the next request for samples 100 ms later, as seen inFigure 6.3, NTP errors persist until the next synchronization procedure 64 secondslater.6.5 Network Quality of Service Guarantees to ImprovePerformance6.5.1 Regular Network Traffic Impacts PerformanceWhile a Dense Network of IoT Sensors (DeNIS) delivers the correct data, its per-formance tracing the earthquake wave is not as ideal as its performance in the vir-tual environment we used for validation. We used wireline connection in our virtualenvironment, and relied on Rogers cellular network for in-field testing. Wirelessnetwork resources are significantly more limited than wireline resources. Theselimitations became evident during in-field testing and affected the accuracy of ourresults.DeNIS was tested on Rogers network along with regular user traffic. During aperiod of low usage by others, our system experienced low latencies and fast data106(a) A 20 Hz Reference Wave was Estimated with ASC on FR2 and Recorded with NTP.(b) A 20 Hz Reference Wave was Estimated with ASC on LTE and Recorded with NTP.Figure 6.12: ASC estimated, and NTP recorded 20 Hz waves compared with20 Hz reference. NTP gives the incorrect times for some of the samplesuntil the device re-synchronizes time with the server.107retrieval with low estimation error. When the application shared wireless resourceswith others, the error increased.Figure 6.13a shows the round trip times experienced during one of our tests onLTE; the latencies are acceptable for the technology. Conversely, in Figure 6.13bthe round trip times are within the normal range for the first 6000 samples retrieved,while the latencies become significantly larger and random for the second half ofthe test. The application is now sharing the network resource with another user.Sharing limited resources has an adverse effect on latency, impacting bothtimestamp estimation and sample loss. Timestamp estimation depends on jitter,as discussed in section 5.3.3, and this is best seen in 6.3 with the temporary incor-rect timestamp estimation on LTE.Severely delayed requests lead to inflated sample loss. For a sampling rate of100 samples/second and a packet of 10 samples, the EEW agent sends out requestsevery 100 ms. This allows the device enough time to generate 10 new samples tobe returned in response to the request. As the sensor continues to generate samples,a significantly delayed request finds more than 10 new samples. 10 latest samplesare returned in the response and a number of samples never make it to the agent.When the sampling rate increases to 200 samples/second to capture 20 Hz, a de-layed request will have even more detrimental impact on sample loss.In the test in figure 6.13b, from the samples between 1 and 6000 only fivesamples did not make it to the agent. Between samples 6000 and 10 000, data ac-quisition lost 1/4 of the samples due to delayed requests.Data redundancy could be a partial solution to sample loss if the system oper-ates on a busy resource. Sending out requests more frequently could ensure that wehave a duplicate of the sample in case a spike in latency causes requests to arrivelate. We discussed redundancy in section 4.5.2. Redundancy causes an increase inthroughput, creates additional network traffic, and is a further burden on an alreadybusy channel.1086.5.2 Quality of Service Guarantees for Public Safety NetworksPublic safety networks such as emergency communications and early warning sys-tems must be equipped with the tools they need to function properly [60], [61],[62]. Dense networks of sensors and public safety networks use the latest gener-ations of communication technologies not only for enhanced throughput but alsofor low latency and distributed processing on the edge. There are tools that 4G and5G offer that go beyond the resources we had access to while testing EEW-SC.Commercial 4G networks already offer and implement Quality of Service (QoS)and prioritization mechanisms to guarantee high priority, end-to-end security, lowlatency, ample bandwidth and low packet loss to selected network users [61]. While4G provides essential features to support public safety applications, it is fairly in-flexibile. Its network orchestration is hardware-based, and lacks software-basedsolutions and capabilities [60].Advanced 5G networks are softwarized and programable, and can dynamicallyallocate resources. Network slicing is a tool for implementing support tailored tothe specific performance requirements and security needs of the application whileit shares the same infrastructure with other network traffic [60], [61], [62].In particular, dynamic network slicing will serve the needs of mostly low-activity public safety systems. It is created on demand, it is robust, and couldsteer mission-critical traffic through difficult network conditions, especially duringa natural disaster like a seismic event.6.5.3 QoS Guarantees and Network Slicing to Improve EEW-SCPerformanceCanada and Canadian cellular network operators must work to establish a dedi-cated broadband infrastructure policy for public safety systems. In addition, they109(a) LTE is behaving consistently.(b) LTE is not behaving consistently.Figure 6.13: Comparison between the round trip times the packets experiencewhen there are enough resources and when resources are shared.110should optimize bandwidth allocation and ensure uninterrupted connectivity forcritical communication needs.We extensively tested cellular technologies and examined the associated la-tency to take it into account in system design and to learn how to cope with thevariability it produces. Yet, figures 6.13a and 6.13b, show an early warning systemthat performs below its potential. We did not have the opportunity to test QoS ornetwork slicing and their effect on EEW-SC.Providing EEW-SC with Quality of Service (QoS) guarantees and a dynamicnetwork slice during its operation will improve the performance dramatically. Itwill prioritize its traffic for ultra-low latency, ensure the throughput the applicationrequires and provide maximum security so that the system operates at its best dur-ing an earthquake.111Chapter 7Conclusions and Future SystemDevelopment7.1 ConclusionsUnderstanding the limitations and low effectiveness of traditional EEW systems,we proposed the EEW-SC system. Unlike conventional systems, which providea general alarm when magnitude prediction is at a set threshold, EEW-SC aimsto make real-time precise predictions of magnitude and ground shaking intensitywith fine resolution in space. EEW-SC departs from traditional systems in pro-viding high-accuracy prediction of earthquake energy transfer based on actual datafrom a dense grid of seismic sensors gathered in real-time. Going beyond generalalarm, EEW-SC will will be capable of performing structural damage estimationand enable damage-preventive actions.To support data collection, data transfer and pre-processing for the EEW-SCapplication, we outlined three major objectives in section 1.4. Firstly, we com-mitted to research and design a viable IoT solution for data collection and pre-processing for a time-critical application. Secondly, utilizing wireless access tech-nologies for connectivity, we committed to investigate how latency and the overallnetwork behaviour of cellular technologies such as LTE, and 5G impact the per-formance of data collection and sensor network synchronization and the overall112performance of EEW-SC application. And finally, we aimed to develop a low-complexity mechanism for data collection and overall sensor network managementand coordination of the incoming data.As per section 1.5, we completed the first objective by providing a solutionfor a dense IoT sensor network organization. The solution adheres to advancedIoT design approaches and meets the real-time, high-accuracy requirements of theapplication. A minimum delay communication stack was selected, along with aframework for fast prototyping. The finely-spaced grid of sensors, organized insectors, collects data in real-time and uses distributed processing for minimizedprocessing delays.Network latency is a factor of prime importance and system design has to bemoulded around the underlying medium that transfers data and ensures connectiv-ity between the different parts of the application. Through the completion of oursecond objective, we demonstrated a deep understanding of cellular technologiesand their impact on EEW-SC. We validated our proposed solution through exten-sive testing, and extensive system performance analysis on the live Rogers network.We completed our third objective, when we proposed a novel mechanism fordata collection called ASC. We validated the mechanism in a virtual environmentand later with in-field scenario testing. The mechanism efficiently collects and esti-mated sample timestamps during a seismic event, and allows the sensor network toremain in a default operational readiness when no seismic activity is present. Thesensors require only a basic connectivity check, and as clock-less devices, they donot have to undergo clock synchronization.There is an inherent difficulty in forecasting ground motions. The most promis-ing approach is to densify the number of observation points and estimate how theenergy released will distribute in real time. Using digital communication and IoTto support seismic data collection and processing for EEW applications will im-prove earthquake early warning. While the prediction accuracy will only increasewith higher resolution, our research concludes that DeNIS delivers the correct data113even using less resolution, and the network of sensors can densify over time to easethe initial financial commitments associated with deployment.Communication and data transfer mechanisms were designed for minimum de-lays and optimized to work on top of an established wireless medium. The ASCmechanism works very well, and no synchronization at the MSes is needed. Atthe start of a seismic event we only need to initiate data collection. Sample loss isinsignificant: only about 2% of samples requested are lost. Sample loss increaseswhen the channel resources are absorbed by other traffic. The primary sourcesof data acquisition errors are associated with the sensor’s accuracy, sampling fre-quency, and error in reconstructing the waves at the server. These errors are knownand manageable.The DeNIS can detect and capture correctly all the frequencies we require onall studied 4G and 5G wireless access technologies. It is up to the application todecide how fast it needs the resources. The application defines real-time as theobservation of each period of the earthquake wave as soon as it happens. It definesreal-time processing as the ability to process the current period of the wave beforethe next period is fully generated. Then, it is up to the application to define theprocessing window in which samples should be acquired. This currently is 50ms,the length of a period of the 20Hz frequency component. This naturally makes 5Gcellular technologies the most suitable for the application.For our testing environment, Rogers network gave us access to the default besteffort QoS. Although, the accuracy of data collection and coordination was within90-95%, in the future specific quality of service could be given by the cellularnetwork operator to meet the goals of the network thru assigning resources: dy-namically orchestrated slices, dynamic resource scaling and allocation. This willboost accuracy and guarantee connectivity during network hardships typical foremergency situations.1147.2 Future DeNIS DevelopmentFurther design ideas to consider, that are not addressed at this research stage areto focus on more efficient data collection, bridging DeNIS development from re-search to commercial-grade technology, and addressing the resiliency and securityof the sensor grid.Exploring a higher sampling rate will create more data points for higher pre-cision waveforms; however, collecting additional data will increase the networktraffic created by the application. Resource guarantees by the communications net-work will be necessary to manage this requirement.The system should be tested with QoS guarantees to confirm the expectationsof performance improvement. Data collection on a designated network slice on 5GStand Alone will give us an understanding of the resource the system will need tooperate optimally during a seismic event.Data acquisition could be made more robust with a request timeout by ex-ploring CoAP’s Nonconfirmable mode. Currently, Request/Response message ex-changes are in Confirmable mode. This translates into 0 packet loss, but EEWagent’s querying waits for the response packet until it arrives. In Nonconfirmablemode, if the request is not received by the device or the response packet is lost,after wait timeout the agent can discontinue the request and move on by sendinganother request.Some optimizations are needed for a final deployment version. The M2MFramework working on top of CoAP is suitable for research simplification ofthe standardized Lightweight M2M Protocol. Full implementation of LWM2Mis needed at commercialization.Defining MEC performance and characteristics, including EEW agent and agent’ssector size will be addressed in future work. The MEC we used in the benchmarkshas an 8-CPU core. For that MEC resource, we determined a sector size of 100115devices. Further improvements are recommended. Code optimization, parallelprocessing, and a faster machine could yield 10-20 times the capacity.Considering the critical importance of the EEW-SC application and the sensi-tive nature of the data collected, the reliability and security of the DeNIS grid needto be addressed before deployment. Seismic shaking may cause an individual or agroup of MSe stations to disconnect from the grid. In these situations, the predic-tion model requires a method of coping with the missing data points. Simulatingdata points for the absent devices could be achieved through data interpolation fromthe non-impacted stations and historical data from the moments before the devicesdisappear from the grid.Currently, security is provided through DTLS, which comes paired with UDPby default. Further security mechanisms must be added for thorough authenticationof devices, prevention of node compromise, eavesdropping, intrusion and man-in-the-middle attacks on the sensor network.7.3 Future EEW-SC DevelopmentBeyond the EEW agent in figure 4.1 is the Ongoing Processing Estimation andNotification (OPEN) of EEW-SC. Once pre-processed, seismic data will be trans-ferred for further analysis by the model. The model will use physics-based electro-magnetic transient wave propagation for earthquake prediction and early warning.It will detect early structural damage and enable asset-level alerting, automatedresponse actions and post-earthquake evaluation. The model is currently underdevelopment to be integrated in the future with the sensor network and its effec-tiveness is being tested.Further work on EEW-SC will undertake the development of the Managementcentre and the Decision engine. The Management centre will handle software up-dates, status checks, node configuration modifications, and alert dissemination.The Decision engine will be responsible for analysis and conclusions related to116the application’s goals.EEW-SC will be tested in a region with relatively frequent seismicity to allowthe prediction model to train and improve its accuracy. DeNIS will be deployedin an urban area with cellular coverage in this region. Subsequently, EEW-SC willbe integrated with the regional EEW system to fulfill its purpose of warning theprovince’s citizens, preventing extensive loss of lives and mitigating the damagesthat earthquakes have historically caused in British Columbia.117Bibliography[1] H. Estrada, L. S. Lee, and T. . F. eBooks A-Z, Introduction to earthquakeengineering. Boca Raton: CRC Press, Taylor & Francis Group, CRC Pressis an imprint of the Taylor & Francis Group, an informa business, 1 ed.,2017. → pages xi, 1, 8, 9, 10, 12, 125[2] T. O. University, “Earthquakes,” 2016. Online; accessed September 1, 2022.→ pages xii, 9[3] L. Finn, A. Bebamzadeh, F. Pina, C. Ventura, and B. Pandey, “The Use ofEquivalent Intensity Factors to Model Site Conditions for PerformanceBased Design of School Buildings in British Columbia, Canada,” 15 WorldConference on Earthquake Engineering, Lisbon, Portugal, 05 2012. →pages xii, 10, 20, 22[4] R. Herrero, Herrero, and S. E. eBooks 2022 English/International,Fundamentals of IoT Communication Technologies. Cham: Springer, 2021.→ pages xii, 27, 28, 31, 32, 33, 35, 36, 37, 38, 39[5] “Earthquake early warning: Recent advances and perspectives,”Earth-Science Reviews, vol. 205, pp. 103–184, 2020. → pages1, 2, 3, 4, 11, 12, 13, 15, 19, 21, 26[6] S. A. Shah, D. Z. Seker, S. Hameed, and D. Draheim, “The Rising Role ofBig Data Analytics and IoT in Disaster Management: Recent Advances,Taxonomy and Prospects,” IEEE access, vol. 7, pp. 54595–54614, 2019. →pages 1, 38, 42[7] R. M. Allen and D. Melgar, “Earthquake early warning: Advances,Scientific Challenges, and Societal Needs,” Annual Review of Earth andPlanetary Sciences, vol. 47, no. 1, pp. 361–388, 2019. → pages2, 4, 12, 13, 14, 15, 16, 17, 19, 21118[8] D. J. Wald, “Practical limitations of earthquake early warning,” Earthquakespectra, vol. 36, no. 3, pp. 1412–1447, 2020. → pages 2, 16, 17, 20, 21, 22[9] T. Crawford, “Metro Vancouver’s $21-billion transit plan, which includes agondola to SFU, approved,” 2022. Online; accessed October 17, 2022. →page 2[10] B. Government, “B.C. investing more than $2.4 billion in Metro Vancouvertransit improvements,” 2022. Online; accessed October 17, 2022. → page 2[11] T. Orton, “5G spectrum starting in B.C.,” 2022. Online; accessed October17, 2022. → page 2[12] B. Hydro, “Continuous optimization,” 2022. Online; accessed October 17,2022. → page 2[13] A. Schlesinger, J. Kukovica, A. Rosenberger, M. Heesemann, B. Pirenne,J. Robinson, and M. Morley, “An Earthquake Early Warning System forSouthwestern British Columbia,” Frontiers in earth science (Lausanne),vol. 9, 2021. → pages 2, 14, 22, 23, 54[14] N. R. Canada, “Earthquakes Canada,” 2022. Online; accessed October 17,2022. → page 2[15] N. R. Canada, “Earthquake Early Warning Program,” 2021. Online;accessed October 17, 2022. → page 2[16] S. E. Minson, A. S. Baltay, E. S. Cochran, T. C. Hanks, M. T. Page, S. K.McBride, K. R. Milner, and M.-A. Meier, “The Limits of Earthquake EarlyWarning Accuracy and Best Alerting Strategy,” Scientific reports, vol. 9,no. 1, pp. 2478–2478, 2019. → pages 2, 11, 16, 20[17] H. S. Kuyuk and R. M. Allen, “Optimal seismic network density forearthquake early warning; a case study from California,” Seismologicalresearch letters, vol. 84, no. 6, pp. 946–954, 2013. → pages 2, 14[18] W. Friedemann, Early Warning for Geological Disasters. Springer Berlin,Heidelberg, 1 ed., 2014. → pages 2, 4, 10, 12, 16, 17, 18, 19, 20, 44, 54[19] R. M. Allen and H. Kanamori, “The potential for earthquake early warningin Southern California,” Science, vol. 300, pp. 786–9, May 02 2003.Copyright - Copyright American Association for the Advancement ofScience May 2, 2003; Last updated - 2017-10-31; CODEN - SCIEAS. →pages 3, 4, 13, 18119[20] Y. Fujinawa and Y. Noda, “Japan’s Earthquake Early Warning System on 11March 2011: Performance, Shortcomings, and Changes,” EarthquakeSpectra, vol. 29, no. 1 suppl, pp. 341–368, 2013. → pages 4, 16, 17, 19, 20[21] A. I. Chung, M.-A. Meier, J. Andrews, M. Boese, B. W. Crowell, J. J.McGuire, and D. E. Smith, “Shakealert earthquake early warning systemperformance during the 2019 Ridgecrest earthquake sequence,” Bulletin ofthe Seismological Society of America, vol. 110, no. 4, pp. 1904–1923, 2020.→ pages 4, 18[22] R. De Matteis and V. Convertito, “Near-real-time ground-motion updatingfor earthquake shaking prediction,” Bulletin of the Seismological Society ofAmerica, vol. 105, no. 1, pp. 400–408, 2015. → pages 4, 14[23] T. Wang, X. Jin, Y. Wei, and Y. Huang, “Real-time numerical shakeprediction and updating for earthquake early warning,” Earthquake science,vol. 30, no. 5-6, pp. 251–267, 2017. → pages 4, 14, 15[24] Q. Kong, R. M. Allen, L. Schreier, and Y.-W. Kwon, “Myshake: Asmartphone seismic network for earthquake early warning and beyond,”Science advances, vol. 2, no. 2, pp. e1501055–e1501055, 2016. → pages4, 14, 15, 55[25] Y. Kodera, Y. Yamada, K. Hirano, K. Tamaribuchi, S. Adachi,N. Hayashimoto, M. Morimoto, M. Nakamura, and M. Hoshiba, “Thepropagation of local undamped motion (PLUM) method; a simple and robustseismic wavefield estimation approach for earthquake early warning,”Bulletin of the Seismological Society of America, vol. 108, no. 2,pp. 983–1003, 2018. → pages 4, 14, 15[26] A. Z. Vizuete, I. P. Llopis, C. P. Salvador, and M. E. Domingo, “QuakeDetection System Using Smartphone-based Wireless Sensor Network ForEarly Warning,” Revista iberoamericana de automa´tica e informa´ticaindustrial, vol. 12, no. 3, pp. 260–269, 2015. → pages 4, 14, 15, 43, 55[27] J. F. Kurose and K. W. Ross, Computer networking: a top-down approach.Boston: Pearson, seventh ed., 2017. → pages 5, 33, 34, 57, 78[28] J. S. Y.-P. E. W. A. Z. Fredrik Alriksson, Lisa Bostro¨m, “Critical IoTconnectivity: Ideal for time-critical communications,” 2020. Online;accessed September 14, 2022. → pages 5, 41120[29] K. K. Patel, S. M. Patel, and P. Scholar, “Internet of things-IOT: definition,characteristics, architecture, enabling technologies, application & futurechallenges,” International journal of engineering science and computing,vol. 6, no. 5, 2016. → pages 5, 28, 33[30] R. Aksoy and A. Demiroz, “The Konya earthquakes of 10-11 September2009 and soil conditions in Konya, Central Anatolia, Turkey,” Naturalhazards and earth system sciences, vol. 12, no. 2, pp. 295–303, 2012. →pages 9, 10[31] H. B. Seed, M. P. Romo, J. I. Sun, A. Jaime, and J. Lysmer, “The MexicoEarthquake of September 19, 1985—Relationships between Soil Conditionsand Earthquake Ground Motions,” Earthquake spectra, vol. 4, no. 4,pp. 687–729, 1988. → pages 9, 10, 17, 22[32] A. Becerra, E. Saez, L. Podesta, and F. Leyton, “The 2014 earthquake inIquique, Chile; comparison between local soil conditions and observeddamage in the cities of Iquique and Alto Hospicio,” Earthquake spectra,vol. 32, no. 3, pp. 1489–1505, 2016. → pages 9, 10[33] USGS, “Volcano Watch — Tiltmeters measure tiny changes that can havebig consequences,” 2018. Online; accessed September 4, 2022. → page 12[34] G. Wurman, R. M. Allen, and P. Lombard, “Toward earthquake earlywarning in Northern California,” Journal of Geophysical Research: SolidEarth, vol. 112, no. B8, 2007. → pages 12, 13, 14[35] shakealert.org, “Shakealert: An Earthquake Early Warning System for theWest Coast of the United States,” 2018. Online; accessed September 6,2022. → pages 14, 18, 54[36] E. S. Cochran, J. F. Lawrence, C. Christensen, and R. S. Jakka, “TheQuake-Catcher Network; citizen science expanding seismic horizons,”Seismological research letters, vol. 80, no. 1, pp. 26–30, 2009. → pages14, 15, 44, 55, 65[37] M. Hoshiba and S. Aoki, “Numerical shake prediction for earthquake earlywarning; data assimilation, real-time shake mapping, and simulation of wavepropagation,” Bulletin of the Seismological Society of America, vol. 105,no. 3, pp. 1324–1338, 2015. → pages 14, 15[38] G. Sua´rez, “The Seismic Early Warning System of Mexico (SASMEX): ARetrospective View and Future Challenges,” Frontiers in earth science(Lausanne), vol. 10, 2022. → pages 17, 22121[39] A. Bagchi, V. K. R. Kodur, and S. Mousavi, “Review of post-earthquake firehazard to building structures,” Canadian journal of civil engineering,vol. 35, no. 7, pp. 689–698, 2008. → page 19[40] N. R. Canada, “Liquefaction Hazard,” 2017. Online; accessed October 17,2022. → page 22[41] D. J. J. Martı´, “EECE 560 Course Notes,” 2019. → page 25[42] D. J. J. Martı´, “The EOZ Transmission Line Model for Earthquake WavePropagation.” Internally distributed. → page 25[43] G. Mei, N. Xu, J. Qin, B. Wang, and P. Qi, “A Survey of Internet of Things(IoT) for Geohazard Prevention: Applications, Technologies, andChallenges,” IEEE internet of things journal, vol. 7, no. 5, pp. 4371–4386,2020. → pages 28, 42[44] P. D. Zheng, Jun, A. Jamalipour, and W. O. Library, Wireless sensornetworks: a networking perspective. Piscataway, NJ;Hoboken, N.J;: IEEE,1st ed., 2009. → pages 30, 31, 39, 55[45] S. N. Swamy and S. R. Kota, “An Empirical Study on System Level Aspectsof Internet of Things (IoT),” IEEE access, vol. 8, pp. 188082–188134, 2020.→ pages 30, 31, 32, 35, 36, 37, 39, 40, 41, 52, 53[46] James and S. E. eBooks 2022 English/International, IoT System Design.Springer International Publishing, 2022. → pages 31, 35, 36[47] A. S. Pillai, G. S. Chandraprasad, A. S. Khwaja, and A. Anpalagan, “Aservice oriented IoT architecture for disaster preparedness and forecastingsystem,” Internet of Things, vol. 14, p. 100076, 2021. → pages 36, 42[48] G. A. Akpakwu, B. J. Silva, G. P. Hancke, and A. M. Abu-Mahfouz, “ASurvey on 5G Networks for the Internet of Things: CommunicationTechnologies and Challenges,” IEEE access, vol. 6, pp. 3619–3647, 2018.→ page 38[49] Y. Hajjaji, W. Boulila, I. R. Farah, I. Romdhani, and A. Hussain, “Big dataand IoT-based applications in smart environments: A systematic review,”Computer science review, vol. 39, p. 100318, 2021. → pages38, 39, 41, 42, 52[50] S. L. Ullo and G. R. Sinha, “Advances in Smart Environment MonitoringSystems Using IoT and Sensors,” Sensors (Basel, Switzerland), vol. 20,no. 11, p. 3113, 2020. → page 41122[51] Y. Sherki, N. Gaikwad, J. Chandle, and A. Kulkarni, “Design of real timesensor system for detection and processing of seismic waves for earthquakeearly warning system,” pp. 285–289, IEEE, 2015. → page 43[52] D. Andjelic, “m2m Framework.” Internally distributed. → page 53[53] W. Dargie, C. Poellabauer, and W. O. Library, Fundamentals of wirelesssensor networks: theory and practice. Hoboken, NJ;Chichester, WestSussex, U.K;: Wiley, 1. aufl.;1; ed., 2010;2011;. → pages 55, 80[54] A. Yarali, W. O. Library, W. F. A. O. 2020, and O. for Higher Education,Public safety networks from LTE to 5G. Hoboken, NJ, USA: John Wiley &sons Ltd, 1 ed., 2019;2020;. → page 56[55] A. Schlosser, “Early Earthquake Warning Sensor Evaluation and NetworkSensor Coordination Simulation,” Master’s thesis, University of BritishColumbia, 2021. → page 65[56] Analog Devices Inc., ADLX354/ADXL355 Data Sheet, 2020. → page 65[57] Raspberry Pi, Raspberry Pi 4 Data Sheet, 2019. → page 65[58] A. Viswakumar, “Data-driven Approaches for Aiding Earthquake EarlyWarning Systems,” Master’s thesis, University of British Columbia, 2011.→ page 77[59] Linux.org, “tc-netem,” 2011. Online; accessed August 10, 2021. → page 78[60] A. Othman and N. A. Nayan, “Public Safety Mobile Broadband System:From Shared Network to Logically Dedicated Approach Leveraging 5GNetwork Slicing,” IEEE systems journal, vol. 15, no. 2, pp. 2109–2120,2021. → page 109[61] M. Hoyhtya, K. Lahetkangas, J. Suomalainen, M. Hoppari, K. Kujanpaa,K. Trung Ngo, T. Kippola, M. Heikkila, H. Posti, J. Maki, T. Savunen,A. Hulkkonen, and H. Kokkinen, “Critical Communications Over MobileOperators’ Networks: 5G Use Cases Enabled by Licensed SpectrumSharing, Network Slicing and QoS Control,” IEEE access, vol. 6,pp. 73572–73582, 2018. → page 109[62] F. Franchi, A. Marotta, C. Rinaldi, F. Graziosi, L. Fratocchi, and M. Parisse,“What Can 5G Do for Public Safety? Structural Health Monitoring andEarthquake Early Warning Scenarios,” Sensors (Basel, Switzerland), vol. 22,no. 8, p. 3020, 2022. → page 109123Appendix ASupporting Materials124Table A.1: Modified Mercalli Intesity Scale Compared to Magnitude andPGA from [1]Degree Intensity Description Magnitude PGAg(9.81 ms2 )I Not felt, except by some in rare circumstances. < 3.0 < 0.03II Felt only by a few persons at rest or on upper floors ofbuildings.3.0-3.9III Felt indoors, but many people do not recognize it as anearthquake.IV During the day felt indoors by many, outdoors by few,while at night some awakened.4.0-4.9V Felt by nearby everyone during the day and many awak-ened at night. Some dishes, windows, etc. are broken;cracked plaster in a few places; unstable objects over-turned.0.03-0.08VI Felt by all, many frightened and run outdoors. Some heavyfurniture moved; a few instances of fallen plaster and dam-aged chimneys. Damage slight.5.0-5.9 0.08-0.15VII Everybody runs outdoors.Damage negligible in buildingsof good design and construction; slight to moderate inwell-built ordinary structures; considerable in poorly builtor badly design structures; some chimneys damaged.0.15-0.25VIII Damage slight in specifically design structured; consider-able in ordinary buildings (some partial collaps); great inpoorly built structures. Chimneys, factory stack, columns,monuments, walls toppled. Heavy furniture ouverturned.6.0-6.9 0.25-0.45IX Damage considerable in specifically designed structures;well-designed frame structures thrown out of plumb; greatdamage of others, including partial collapse. Buildingsshifted off foundations. Ground cracked conspicuously.Underground pipes broken.7.0-7.9 0.45-0.6X Some well-built wooden structures destroyed; most ma-sonry and frame structures distroyed. Ground badlycracked.0.6-0.8XI Few masonry structures remain standing. Bridges de-stroyed. Broad fissures in ground. Underground pipelinescompletely out of service.>8.0 0.8-0.9XII Damage total. Waves seen on ground surface. Objectsthrown into the air.> 0.9125
Thesis/Dissertation
eng
Electrical and Computer Engineering
Vancouver : University of British Columbia Library
Attribution-NonCommercial-NoDerivatives 4.0 International
Graduate
Martí, José R.
Dense network of sensors applied to earthquake early warning in smart cities
Text