MeshSOS: An IoT Based Emergency Response System

Bhavye JainIIT Roorkee

bjain@cs.iitr.ac.in

Kaustubh TrivediIIT Roorkee

ktrivedi@cs.iitr.ac.in

Swati AgarwalBITS Pilani Goa

agrswati@ieee.org

Rahul ThakurIIT Roorkee

rahulthakur@ieee.org

Abstract

Due to the limited mobility and technicalknowledge, senior and disabled citizens of thesociety face difficulties during emergencies. Mosthardware/software emergency assistance/responsesystems available in the market have a complex userinterface even for the general public. Requesting helpusing these systems requires sharing information suchas type and location of the event, which wastes precioustime to respond to the event. Often, citizens end uphandling the event themselves instead of waiting forsomeone to arrive at the event location. Hence, itis necessary to design a simple but incredibly robustsystem which bypasses the challenges of traditionalemergency response systems. In this paper, we proposean Internet of Things (IoT) based mesh-enabledemergency response system called MeshSOS, whichenables senior and disabled citizens to get assistanceby simply pressing a button. Use of mesh networkingalong with WiFi made our system robust to networkfailures. We have also developed a central monitoringapplication for healthcare and security agencies tohandle emergency events proactively. Initial fieldexperiments and simulations show that our system hasthe potential to improve the robustness and responsetime in an energy and cost-efficient manner.

1. Introduction

Building a community with basic knowledgeof delivering first-aid is important for immediateemergency response. Unfortunately, the know-how andthe experience of delivering first-aid is not common,and the chances of having such a person around whenneeded are fairly low. A report in The Guardian1 statesthat the lack of first-aid skills endangers up to 150, 000lives annually. In such scenarios, timely assistancefrom trained personnel takes paramount importance. In

1First aid skills deaths. https://www.theguardian.com/society/2010/apr/12/first-aid-skills-deaths

most countries, the primary public safety and assistancesystem includes a unique phone number such as 911(USA) and 100 (India) where citizens can call torequest for assistance. Even though calling a fixednumber is the simplest solution, it is certainly not themost efficient one. A citizen in distress has to sharedetails related to his/her location and type of emergency(security, medical, fire, etc.) before an appropriateemergency response team can be dispatched. This delayin response time could mean the difference between lifeand death in case of critical emergencies2. The problembecomes even worse in developing countries wherethe emergency response services (such as ambulanceand police) are inherently inefficient by design. Areport of the Comptroller and Auditor General (CAG)of India shows that the ambulance service failed torespond in more than 40% (113, 632 out of 275, 243calls) of the cases within a stipulated time. Furthermore,these calls are not only unattended but cancelled anddeclined as well. As per CAG’s reports [1, 2], in thestate of Kerala (India), out of 1, 867, 508 received calls,17, 627 calls were cancelled while 28, 102 calls weredeclined. The delay in the service cannot be solelyattributed to traffic delays, but also communicationand management delays. A study by the NationalHealth Systems Resource Centre (NHSRC) [3] showsthat the percentage of calls for which ambulances weredispatched were as low as 1.21% of the calls received.

The need for medical and security assistanceincreases manifold for senior and disabled citizensof society. The response time for emergency eventsis even more critical when it comes to senior anddisabled citizens with limited technical knowledgeand/or mobility. Modern smartphone-based emergencyresponse systems can be too complicated or intimidatingfor the elderly and disabled. In such systems, multiplesteps are required before relevant assistance can bedispatched. Also, some systems require a lot of

2Government of India data shows that morethan 50% of heart attack cases reach hospitalslate. https://www.hindustantimes.com/story-penFdsewgGwpIwiQnRDoLJ.html

Proceedings of the 54th Hawaii International Conference on System Sciences | 2021

Page 3903URI: https://hdl.handle.net/10125/71089978-0-9981331-4-0(CC BY-NC-ND 4.0)

specific configuration before they can actually workon the devices. Available hardware systems on themarket are not affordable by masses and also requireregular maintenance [4]. These hardware systemsand applications are proprietary and hence, cannotbe maintained or repaired by a third party or anend-user. Additionally, most of the existing systemsrely entirely on the wide-area networking capabilitiesof a smartphone (or a smart device) for Internetconnection via WiFi or cellular network. This makesthe system unreliable since an event of a network failurewill completely fail the system without any fail-safe.Therefore, it is need of the hour to develop a systemthat can bypass the above-mentioned challenges andminimize the points of failures while providing promptand hassle-free emergency services.

In this paper, we introduce MeshSOS, a robustIoT-based mesh-enabled emergency response system.We have designed a simple and intuitive end-userdevice which allow citizens to request for Medical andSecurity related assistance by simply pressing a buttonon the device. Our system is extremely convenientfor seniors and disabled citizens who prefer ”a singlebutton press to get the job done” vision due to limitedtechnical knowledge and mobility. Additionally, Wehave developed a central monitoring application whichallows emergency service authorities to monitor theend-user devices and to keep track of the emergencyevents (location, route, status, etc.). Finally, toimprove the robustness, MeshSOS uses multi-hopmesh communication which eliminates the requirementof direct connectivity to WiFi/4G networks. Fieldexperiments and simulations show that the performanceof our proposed system is better in terms of delay,message delivery ratio, robustness, energy, and cost.

2. Related Works and Motivation

Advancement in hardware and wirelesscommunication technologies has accelerated thedevelopment of low-cost and reliable emergencyresponse systems for home/office/business security,medical and road emergencies. There exist manysoftware, hardware, and IoT based products in themarket which use wireless technologies (such as WiFi,Bluetooth, and 4G) to provide emergency services.Inbuilt SOS feature in mobiles and third-party appssuch as SirenGPS, Kitestring, Red Panic Button,etc. allow users to send an alert for assistance inunfavourable situations. The primary feature inall these apps is to provide an easily accessibleswitch/button to inform a pre-selected list of contactsor first responders about your whereabouts. Some

apps, such as Kitestring take one step further to alertyour friends and family if you don’t respond to apotential emergency message sent to your phone. Therealso exists apps and hardware devices specificallydesigned to tackle medical emergencies. Dedicatedbattery-powered lightweight hardware systems such asmedical bracelets/necklaces/watches are available in themarket. By pushing a switch on these wearables, thecentral monitoring stations can be informed about thelocation of a person in distress. In [5], the authors haveintroduced iHelp, an emergency assistance smartphoneapp for helping the deaf-mute and elderly citizens.This app can report an emergency using 3G/4G/WiFiInternet, which enables medics to be rushed to the scenequickly. All the above-mentioned devices and appsprovide useful features but do not tackle the situationswhere proper WiFi or cellular networks are unavailable.

In order to deal with unreliable network connectivity,emergency response systems must use multiple wirelesstechnologies in an efficient manner. The system mustswitch among these technologies without asking extrainput from the end-users. In this direction, the use ofwireless mesh networking (WMN) is another interestingsolution which eliminates the need for ubiquitousconnectivity from an access point [6]. WMNs have beenreceiving a great deal of attention as a broadband accessalternative for a wide range of applications includingtransport, emergency, public-safety, carrier-access, andsmart homes [7, 8]. Mesh architecture has thepotential to provide easy configuration and highrobustness by choosing alternative routes in caseof failure/unavailability of a wireless link or accesspoint. It also offers an economical solution to extendnetwork coverage by eliminating the need for a largenumber of access points. In [9], the authors haveproposed an emergency response system based onwireless mesh networks for public safety using anARM kernel control unit system. The authors suggestthat wired/wireless systems with a base station arevulnerable to destruction by natural or human agents,resulting in system collapse. Their proposed wirelessmesh system performs better under the circumstanceswhere ordinary communication technologies are unableto the Internet. In [10], the authors have exploredthe feasibility of using distributed wireless meshnetworks for medical emergency response. Theauthors proposed a wireless information system formedical response in disasters situations. Theypresented the traffic behavioural observations made bythe client-server medical emergency application testedduring a large-scale homeland security drill. The authorsevaluated the system on some essential requirementsfor an emergency response system such as geographical

Page 3904

position, dependable and redundant backhaul links,utilization of off-the-shelf technology-based products,and robust operation in high interference situations.The results of this study have motivated us to create asystem that can be deployed on a larger scale. In [11],authors have described the capabilities and architectureof a portable, interoperable, tactical operations centrecommunication system, which was funded by theU.S. Department of Homeland Security. The workevaluates wireless mesh network as the key solutionfor emergency and rural applications. The authorssuggest that despite its unique challenges, the wirelessmesh network is a technically suitable yet affordableapproach with significant payoffs. In [12], authors haveproposed a ballooned WMN to ensure communicationin the disaster area promptly. The WMN devices areattached to physical balloons capable of hovering at analtitude but anchored to the ground. It is suggested thatby combining multiple ballooned wireless networks, anad-hoc network can be organized in the sky to provideurgent communication means in disaster areas.

The above-mentioned systems [9, 10, 11, 12] areinteresting examples of WMN; however, they arecomplex, inefficient, and uneconomical for large scaledeployments. For example, the WMN system in [9] usesdedicated nodes (called mesh routers) in the network fordata collection, routing, and monitoring. Additionally,end-user devices collect and send audio, visual, andinfrared data to the control centre via mesh networkingonly. On the other hand, our proposed system has asimple design where dedicated pushbuttons are used tosend extremely small size emergency messages eitherthrough WiFi or mesh. This reduces the cost ofeach device and saves precious network bandwidthwhile improving connectivity. Each end-device in oursystem is capable of working as a router, therebyforwarding emergency messages through multi-hopcommunication. Another example is [12], where thesystem provides connectivity to devices such as mobilephones and laptops via a mesh network. Their setuprequires additional equipments which are vulnerableto damage by bad weather and hence, needs periodicmaintenance by emergency response authorities. Suchan arrangement would work well for short deployments(during natural disasters) but won’t be cost-effectivefor large-scale long-period deployments. On the otherhand, our proposed system can be protected by simpleIP67 weatherproof enclosures and does not requireconstant maintenance. Considering the limitations ofabove-mentioned systems, it is essential to develop asimple, efficient, and robust emergency response systemwhich can minimize deployment and maintenance costsfor large scale deployments.

3. Problem Formulation and SolutionDescription

Our problem focuses on the design of an efficient”Emergency Response System” which can provide asimple IoT-based end-device to elderly and disabledcitizens for requesting emergency assistance. Thesystem should also provide a centralized monitoringplatform/application for medical and security personalsto keep track of end-devices and emergencyevents. Finally, the system should provide reliablecommunication between end-device and monitoringplatform in case of network failure. The contributionsof our work are as follows.

• We have designed an intuitive IoT hardwareprototype which allows citizens to request forMedical and Security assistance by simplypressing a button.

• We have developed a central monitoringapplication which allows authorities to monitorhardware prototype units and keep track of theemergency events’ data (location, route, status,etc.).

• We have developed a robust mechanism foremergency message transmission from hardwareprototype units to central monitoring applicationusing multi-hop mesh and WiFi communication.

• We have analyzed the performance of ourproposed system in terms of delay, messagedelivery ratio, robustness, energy, and cost viasimulations and field experiments.

4. Design Science Research Framework

Before introducing the MeshSOS system, we brieflydiscuss the research methodology adapted behind itsdevelopment using the Design Science Research (DSR)framework [13, 14]. Figure 1 shows six mainsteps in our framework viz., Problem Motivation andIdentification, Objectives, Design and Development,Experimental Setup, Performance Evaluation, andCommunication. As shown in Figure 1, these steps canbe further represented as five possible research phases.In the first phase, we identify the research problem,its motivation, and challenges. In the second phase,we define the objective as the design and developmentof a simple and robust emergency response systemfor elderly and disabled citizens. We have alreadydiscussed the first two phases in Sections 1 and 2.In the third phase, we design and develop the IoT

Page 3905

Figure 1: Design Science Research Framework

hardware prototype (discussed in Section 5.1 and 5.2)and a central monitoring application (Section 5.5). Inthe fourth phase, we perform field experiments (refer toSection 5.4) based on ready-to-use system and researchframework acquired from the previous state. In the fifthphase, we evaluate the performance of our proposedsystem in terms of delay and message delivery ratio(discussed in Section 6). Finally, based on the domainknowledge acquired from experimental results, we aimfor the scholarly publications and technology incubationat our organization.

Our DSR framework follows an iterative processwhere we iteratively update the objective, design anddevelopment of our proposed system to improve itsperformance further. We are finished with the firstiteration, and the first version of hardware prototypeand central monitoring application is finalized. Wehave evaluated the performance of our system viasimulations and field experiments. Currently, we arein the final step (Communication) with the reviewprocess of this research article. Based on the resultsof our simulations and field experiment, we are nowplanning to make changes in the design of the prototypeunit and monitoring application for future large-scaledeployments.

5. Emergency Response System

Our proposed emergency response system hasfour major components: 1) IoT Hardware Prototype2) Software and Services 3) Networking and DataCollection and 4) Central Monitoring Application. Inthis section, we discuss these components in detail.

5.1. IoT Hardware Prototype

We have designed an IoT based hardware prototypewhich allows its user to request for emergencyassistance by merely pushing a button. The prototype isdesigned using an Arduino compatible microprocessorboard called Argon from Particle Inc [15]. Argonboards support multiple wireless technologies such asBluetooth 5.0 and 802.11 b/g/n WiFi. Additionally,these boards have out-of-the-box 802.15.4 meshnetworking capabilities which can be configured usingGoogle OpenThread3; an open-source implementationof the Thread networking protocol. Due to theseintegrated wireless technologies, an Argon board in amesh network can act as an end-node (thereby collectingend-user input/data) or a relay (thereby forwardingtraffic to other boards using 802.15.4 mesh) or agateway (thereby connected to the Internet using WiFi).The schematic of our hardware prototype is shownin the Figure 2 which includes two momentary pushbuttons, an 8 dBm external antenna, USB power supply,on-board RGB status LED, and an external Li-Po 3.7Vbattery. Two push buttons are configured to requestfor two different types of emergencies viz., Medicaland Security. An external antenna is added to providelong-range transmission capabilities for direct WiFi andmesh communication. The prototype can be poweredusing a USB power supply or using an external batteryin case of a power outage. Note that, an equivalentIoT prototype can also be designed using much cheaperESP-32 microprocessor boards with additional hardwaremodules for the external antenna, RGB LED, Li-Po

3OpenThread. https://openthread.io/

Page 3906

Figure 2: IoT Hardware Prototype Figure 3: Software Components and Services

charging circuit, and battery connector [16]. However,to avoid the complexity of connecting multiple modulestogether with unreliable wired connections, we chose touse all-in-one Argon boards.

5.2. Software Components and Services

In this section, we describe all the softwarecomponents and services used in the development ofour proposed emergency response system as shown inFigure 3.

5.2.1. Particle Workbench. To code, compile,and flash the Argon board with the source code, wemake use of Particle Workbench [17]. This workbenchprovides various tools, libraries, and extensions foroffline and online (cloud) compilation of the source codeand supports OTA (Over-The-Air) interface for futureupdates. Additionally, a command-line interface (CLI)is also available which can be used to flash individualArgon boards and to accept serial outputs via a USBcable.

5.2.2. Particle Cloud. Particle Inc provides adevice cloud to manage different types of ParticleIoT devices/boards (such as Argon, Boron, Photon)in a secure, scalable, and reliable manner [18]. Thecloud communicates with the IoT boards using apublish-subscribe model. The cloud also supportsthe integration of third-party APIs such as GoogleMaps and HTTP webhooks. The main objective ofParticle cloud in our emergency response system is toprocess the emergency messages and deliver them tothe central server. The cloud is also responsible forpublishing response/acknowledgement messages to theArgon boards. The Particle cloud essentially binds allthe software and hardware components in our system.

5.2.3. Google Maps API. Our prototype keepstrack of its GPS location using Google Map’sGeolocation service [19]. The Argon boards should beconnected to the Internet using WiFi to use Geolocationservice. Apart from providing GPS location (with 30-40meter accuracy), Geolocation service also computes anoptimal route to reach the board/event location. Sinceeach prototype unit is expected to be fixed within ahome/office region, constant calculation of its preciselocation is not necessary (hence, avoiding additionalGPS/GLONASS hardware modules).

5.2.4. HTTP Webhook. Webhooks areuser-defined HTTP callbacks that enable an applicationto provide data to other applications efficiently inreal-time [20]. Webhooks eliminate the need forconstant polling by an application to fetch data. Oursystem requires that emergency messages are forwardedto the central server as soon as the Particle cloudreceives it from a board. Thus, it is necessary tolink the server to the Particle cloud using a webhookthat updates the server immediately. The support forwebhooks is provided in the form of Particle cloudIntegration. When the cloud receives a message from aboard, the webhook fires an HTTP POST request withthe message in JSON format to an API endpoint on ourserver. The server checks for the validity of the dataand appends an acknowledgement in response to therequest.

5.3. Workflow

When a user presses a button on the prototype unit,an emergency message is generated which we refer to asSOS message from now on. We use the term ’Source’for the Argon board, which generates the SOS message.The term ’Relay’ is used for the Argon boards which

Page 3907

Figure 4: Sequence Diagram

forwards/relays the SOS message to Particle cloud orto other boards in the mesh network. The sequencediagram in Figure 4 summarizes the workflow of ourproposed emergency response system. Broadly, therecan be two possibilities based on whether source Argonboard has Internet connectivity or not:1. If the source board is connected to the Internet: Inthis case, the board first fetches its geographic locationfrom the Particle cloud. Then, the board publishesan SOS message to the Particle cloud directly usingthe WiFi Internet connection. Finally, the webhookintegrated into the Particle cloud sends the data toa central server for data storage and analytics. Ifthe server successfully processes the SOS message,a positive acknowledgement (ACK) is sent from theserver to the Particle cloud. If the server is unableto process the SOS message due to any reason (Forexample, Message corruption) and then a negative

acknowledgement (NACK) is sent. Based on thereceived ACK (or NACK), Particle cloud sends the ACK(or NACK) to the source board. On receiving the ACK,the status of successful delivery is shown to the user byblinking the RGB status LED. In the case of NACKor timeout, the process is repeated until ACK is notreceived. Note that, in this case, the mesh network isnot involved in SOS message transmission.2. If the source board does not have anactive Internet connection: In this case, thesource board floods the SOS message to all theneighbouring Argon boards (in the communicationrange) using the mesh network. After receiving theSOS message, neighbouring boards without an activeInternet connection floods the SOS message to its ownneighbours and so on. We put a limit on the number oftimes an SOS message can be flooded in the mesh toavoid network congestion. If any neighbouring board

Page 3908

have an active Internet connection, it can publish theSOS message to the Particle cloud. This further leadsto 2 sub-cases:

• The source board has valid but outdated locationinformation: In this case, the relay boardpublishes the SOS message received from thesource board to the cloud. Then, integratedwebhook sends the data from the cloud to a centralserver.

• The source board does not have any locationinformation: In this case, the source boardattaches a flag to the SOS message. Relay boardupon receiving the flagged SOS message, appendits own location information to the SOS messageand publishes it to the Particle cloud. Then,integrated webhook sends the data from the cloudto a central server.

Upon successful delivery of the SOS message, ACKis sent from the server to cloud, then from cloud to relayboard, and finally from relay board to the source board.In case of an unsuccessful delivery, NACK follows thesame path from server to the source board, and the entireprocess is repeated until an ACK is received or a timeoutoccurs. The boards in the mesh network and the serveruse the publish-subscribe model to communicate. Assoon as an SOS message is generated and successfullypublished to the Particle cloud, a webhook is fired,which sends the data to the central server. Thisensures that the data is forwarded instantaneously andno time is wasted in waiting for the server to start thesynchronization process. Acknowledgements from theParticle cloud are sent the source boards via relay unlessthe acknowledgement was meant for the relay boarditself.

5.4. Networking and Data Collection

The primary motivation for using the mesh networkalong with WiFi is to provide redundancy for guaranteedmessage delivery. If a user presses a button, thenSOS message must be delivered to the server eitherthrough WiFi or mesh network. Not only that, theacknowledgement of the SOS message should alsobe delivered to the source board. Keeping this inmind, our IoT prototype is programmed to constantlylook for neighbouring boards in its communicationrange (for mesh networking) as soon it is poweredup. Additionally, in the background, the IoT prototypeconstantly looks for available WiFi connections andtries to connect to a known access point. Once aWiFi connection is established, the board maintainsits connection to the Particle cloud. This ensures

that the board does not stall the boot process due tounavailability of WiFi Internet connection and that theboard can publish SOS messages in the mesh network atall times.

The central server receives data related to theemergency events from the Particle cloud. It is theresponsibility of the central server to handle duplicateSOS messages pointing to a single emergency event,which occur due to publish of an SOS message frommultiple relay boards in the mesh network (a redundancyby design). The server maintains logs of all theemergency SOS messages and store related data inan SQLite database. The server also provides RESTAPI endpoints to connect with the Particle cloud andto synchronize the monitoring application with thedatabase.

5.5. Central Monitoring Application

The Central Monitoring Application enables theadministrator to view all the details related to emergencyevents. The application also provides Spatio-temporalinformation of the events. The application is designedto be simplistic, informative with a focus on efficientoperation management. The application can list allthe emergency logs at once or show them filtered intothree different categories viz., medical and security.After receiving an SOS message, the administrator canclick on the log ID to view the details of individualevents and process them, if necessary (Figure 5a). Thetimestamp field shows the time at which the eventoccurred, and the emergency field displays the typeof incident that occurred. The status contains labelsto show message category wiz., New, Processing, andResolved. The action field allows the administrator totake necessary actions. Additionally, the applicationdisplays the location of the incident on a map and theshortest route to the location of the event from a fixedlocation (Hospital or Police Station).

Figure 5b represents the Analytics tab whichprovides a 3D visualization of the data events on amap. The height (and colour gradient) of the columnsrepresent the number of cases in a geographical region.The administrator can hover the mouse pointer over acolumn to view the number of events in the region.The administrator has the option to modify the locationof the emergency response centre, and this updatedinformation reflects across the system immediately.Additionally, the map will centre around the updatedemergency response centre location, and the startingpoint of the shortest routes to the event location will bechanged instantaneously.

Page 3909

(a) Event Details and Route Planner (b) Spatio-Temporal Information

Figure 5: Central Monitor Application Visualization

6. Performance Evaluation

To evaluate the performance of our proposed system,we have performed field experiments by deployingmultiple prototype units in a geographical region. Fordiversity, we have used both broadband WiFi andmobile hotspots to provide wireless connectivity to theprototype units. To further diversify the environment,we have varied the network bandwidth from 120 Kbpsto 50 Mbps. The firmware of Particle Argon boardsis modified to automate the message sending for fieldexperiments. A total of 15,000 events are triggered anddata is recorded at the central monitoring application.We evaluate the performance of our emergency responsesystem in terms of Round Trip Delay (RTD), EventResolution Time (ERT), and Delivery Failure Ratio(DFR). RTD is defined as the time required for an SOSmessage to travel from source board to server plus thetime needed for an acknowledgement (ACK or NACK)to travel from server to the source board. In case ofunreliable network connectivity, prototype units maytake multiple attempts to successfully deliver the SOSmessage at the central monitoring application or markdelivery as failed. ERT is the sum of RTD of all theattempts (successful or failed). DFR defined as thepercentage of emergency messages fail to deliver at thecentral monitoring application.

Figure 6 represents the RTD and ERT for the casewhen the source board is connected to the Particle cloudusing a WiFi connection. Each point on the horizontalX-axis corresponds to an emergency event (Buttonpress). Y-axis represents the time in milliseconds. Notethat, to avoid clutter in the graphs, we have plotted only200 points which are randomly selected from 15,000data points collected during a field experiment. Figure6 represent the RTD and ERT values for emergencymessages when prototype units are connected to theInternet. In some occasions, an erroneous SOS message

gets delivered to the server and NACK is returned to thesource board. The sharp peaks in the ERT represent suchoccasions where multiple re-transmissions are requiredbefore receiving an ACK from the server. This causesERT to have a higher value than RTD. The observedDFR for this case is 1.2% resulted from timeoutshappened during location fetch operations.

Figure 6: Source board is connected to the Internet

Figure 7: Source board is not connected to the Internetbut has the location information

Figure 7 represents the RTD and ERT values for thecase when the source board has the location informationbut does not have an active Internet connection to updatethe location to the cloud. In this case, avoiding locationfetch (as shown in the sequence diagram) saves some

Page 3910

Figure 8: Source board neither has Internet connectivitynor the location information

time. However, message delivery takes extra time asit travels through the mesh network to reach the server.The observed DFR for this case is 0.08%, which is thelowest among all the cases. This is due to the factthat location fetch operation is not required before SOSmessage transmission. In case of absence of Internetconnectivity and location information, the values of ERTare almost double of RTD, as shown in Figure 8. This isdue to the fact that when the first SOS message sent tothe server without any location information, a NACK isreturned. In the second attempt, the relay board appendsits own location information, and the server returns anACK. Due to this second attempt, the ERT values arealways higher then RTD values. The DFR for this caseis around 1.68% which is the highest among all cases.

The average RTD and ERT values for all three casesare shown in Table 1. As can be observed that theaverage RTD values are always lower than average ERTvalues for all the cases. Additionally, average ERTvalues are the highest when the source board neither hasthe Internet connectivity nor the location information.

Case RTD ERTInternet access 1348.68 1781.15No Internet access with location info. 1395.84 2077.88No Internet access without location info. 1784.67 3779.15

Table 1: Average RTD and ERT values

6.1. Real-World Deployment Analysis andImplications

To analyze long-term feasibility and profitabilityof our proposed system in real-world deployments, itis necessary to examine its performance in terms ofrobustness, energy, and cost. Due to the rarity ofemergency events, and a limited number of prototypeunits and WiFi access points, we have performeda numerical simulation along with field experiments.Simulation region is logically partitioned into 20 blocks,

creating a grid of size 5 × 4. All the prototypeunits within a block are connected to a WiFi accesspoint deployed at the centre that block. Prototypeunits not connected to WiFi can use mesh technology,if available. On average, seven prototype units arerandomly distributed in each block. The communicationrange of WiFi is considered to be four times the rangeof single-hop mesh communication. We analyze therobustness of the system in terms of percentage ofprototype units connected to the Particle cloud (andconsequently, the central monitoring application) eithervia WiFi or mesh networking.

Figure 9: Connected Prototype Units

For performance evaluation, we have compared twodifferent emergency response systems. First is theTraditional system where prototype units are equippedwith WiFi only. The second is the Proposed systemwhere prototype units are equipped with both WiFi andmesh to support multi-hop (max five hops) transmissionof SOS message from prototype units to the Particlecloud. The simulation starts with 20 active WiFiaccess points. In the beginning, both traditional andproposed systems perform the same because all theprototype units are connected to the Particle cloud viaWiFi. As the number of active WiFi access pointsdecreases, the number of connected prototype unitskeeps decreasing for the traditional system, as shownin Figure 9. However, for the proposed system,the number of connected prototype units remainsconstant when at least 50% WiFi access points areactive. This is due to the fact that even with a lowernumber of WiFi access points, mesh communicationguarantees network connectivity to prototype units viamulti-hop communication. Deactivating more than 50%WiFi access points reduces the number of connectedprototype units for both the systems. However, ourproposed system is always providing connectivity to ahigher number of prototype units, and hence, has higherrobustness compared to the traditional system.

Page 3911

In our proposed system, to provide connectivity toall prototype units, we require a lower number of WiFiaccess points which directly translates into a better costand energy efficiency. For example, Figure 9 reveals thatthe proposed system reduces the one-time deploymentcost (i.e., cost of WiFi access points) and recurrentoperational cost (i.e., electricity charges) to half bydeploying only 50% of WiFi access points as comparedto the traditional systems. This will accelerate thelarge-scale deployment of emergency response systemsto realize the smart city initiative.

7. Conclusion

In this paper, we proposed an emergency responsesystem for handling medical and security-relatedemergencies. Our proposed system consists ofmesh-enabled IoT prototype units which allow usersto request for assistance even in the absence of anInternet connection. Additionally, a central monitoringapplication is developed to provide a simple and efficientevent management portal to the relevant authorities.In the future, we plan to integrate LTE/LoRaWANcommunication capability into prototype units toprovide long-range communication capabilities.

Acknowledgement

This research work is supported by the FacultyInitiation Grant (FIG) of Indian Institute of TechnologyRoorkee, INDIA.

References

[1] Comptroller and Auditor General, “Compliance andperformance audit on general and social sector ofgovernment of kerala.” [Online]. https://bit.ly/2DOMBZr, 2015.

[2] V. Venugopal and S. Yilmaz, “Decentralization in kerala:Panchayat government discretion and accountability,”Public Administration and Development: TheInternational Journal of Management Research andPractice, vol. 29, no. 4, pp. 316–329, 2009.

[3] National Health Systems Resource Centre, “Study ofemergency response service - emri model.” https://bit.ly/36p0cCH, 2010. [Online].

[4] Y. T. Michelle, B. Ramesh, R. V. Srinivasan, V. Arun, andH. P. TAN, “Aging-in-place: The journey ahead,” tech.rep., Tata Consultancy Services Limited, October 2020.https://on.tcs.com/3cZDqmj.

[5] L. Chen, C. Tsai, W. Chang, Y. Cheng, and K. S.Li, “A real-time mobile emergency assistance systemfor helping deaf-mute people/elderly singletons,” inIEEE International Conference on Consumer Electronics(ICCE), pp. 45–46, 2016.

[6] Y. Liu, K.-F. Tong, X. Qiu, Y. Liu, and X. Ding,“Wireless mesh networks in iot networks,” in2017 International Workshop on Electromagnetics:

Applications and Student Innovation Competition,pp. 183–185, IEEE, 2017.

[7] R. K. Kodali, M. Azman, and J. G. Panicker,“Smart control system solution for smart cities,”in 2018 International Conference on Cyber-EnabledDistributed Computing and Knowledge Discovery(CyberC), pp. 89–893, 2018.

[8] M. Khalil and A. A. Alvi, “Utilizing wireless networksfor public safety: An overview of special use cases,”in 4th International Conference on Emerging Trendsin Engineering, Sciences and Technology (ICEEST),pp. 1–6, 2019.

[9] M. Gao, F. Zhang, and J. Tian, “Wireless mesh networkfor emergency response system based on embeddedsystem,” in International Conference on EmbeddedSoftware and Systems Symposia, pp. 361–365, 2008.

[10] Braunstein and B. et al, “Feasibility of using distributedwireless mesh networks for medical emergencyresponse,” in AMIA Annual Symposium, pp. 86–90,2006.

[11] Yarali, A. . Ahsant, B. . Rahman, and Saifur, “Wirelessmesh networking: A key solution for emergency &rural applications. advances in mesh networks,” inSecond International Conference on Advances in MeshNetworks, pp. 143–149, 2009.

[12] Y. Shibata, Y. Sato, N. Ogasawara, and G. Chiba,“Ballooned wireless mesh network for emergencyinformation system,” in 22nd International Conferenceon Advanced Information Networking and Applications- Workshops, pp. 1118–1122, 2008.

[13] K. Peffers, T. Tuunanen, M. A. Rothenberger, andS. Chatterjee, “A design science research methodologyfor information systems research,” Journal ofmanagement information systems, vol. 24, no. 3,pp. 45–77, 2007.

[14] J. Venable, J. Pries-Heje, and R. Baskerville, “Acomprehensive framework for evaluation in designscience research,” in International Conference on DesignScience Research in Information Systems, pp. 423–438,Springer, 2012.

[15] “Particle Argon: Wi-Fi + Bluetooth.” https://docs.particle.io/argon/. [Online].

[16] “ESP32: A feature-rich MCU with integrated Wi-Fiand Bluetooth connectivity for a wide-range ofapplications.” https://www.espressif.com/en/products/socs/esp32. [Online].

[17] “Partcle Workbench: Professional IoT developmenton Windows, macOS, Linux, powered by VisualStudio Code.” https://www.particle.io/workbench/. [Online].

[18] “Device Cloud: A secure, scalable, and reliable cloudplatform to manage your fleet of IoT devices.” https://www.particle.io/workbench/. [Online].

[19] “Google Maps Platform Documentation.”https://developers.google.com/maps/documentation. [Online].

[20] “Webhooks.” https://docs.particle.io/tutorials/device-cloud/webhooks/.[Online].

Page 3912