MCEP: A Mobile Device Based Complex Event Processing System for Remote Healthcare A. Dhillon† , S. Majumdar† , M. St-Hilaire† and A. El-Haraki§ † Dept.
of Systems and Computer Engineering, Carleton University, Ottawa, Canada § TELUS, Ottawa, Canada Email: {amarjitdhillon,majumdar}@sce.carleton.ca,
[email protected],
[email protected]
Abstract—This paper introduces an edge-computing based Complex Event Processing (CEP) architecture for Remote Patient Monitoring (RPM) which is an important issue in the context of remote healthcare. In this architecture, the detection of complex events, that may indicate impending health problems, is performed on a mobile device that receives data from sensors attached to the body of a patient. The detected complex events are sent to a back-end hospital server running on a cloud for further processing. Current state-of-the-art RPM techniques use the mobile device as an IoT gateway agent to forward data streams from health sensors to a remote hospital server where complex events are detected. A drawback of this existing methodology is that the mobile phone always needs to remain connected to the hospital server. Also, the mobile network consumption is increased while transferring large volumes of sensor data streams thus leading to an increase in the user cost. Additionally, it leads to an increase in the workload at the hospital server that serves multiple patients. This research investigates a mobile device based CEP system for addressing these issues and demonstrates its viability through a proof-of-concept prototype. A thorough performance analysis is performed using a synthetic workload that provides insights into system scalability and the relationship between system/workload parameters and performance. Index Terms—Mobile Complex Event Processing; Remote Patient Monitoring System; Internet of Things; Smart Healthcare
I. I NTRODUCTION The integration of low-cost health sensors with smartphones have increased the popularity of smart healthcare and enabled healthcare providers to offer Remote Patient Monitoring (RPM) as-a-service. A survey1 in 2015 showed that nearly 84% of the service providers use mobile devices for remote patient monitoring. RPM enables health service providers to remotely monitor diseases such as sleep apnea, arrhythmia and Congestive Heart Failure (CHF). In RPM, the sensor data is sent as sensor data streams using bluetooth or Wi-Fi to a mobile device where various events are co-related using Continuous Query Language (CQL) [1] constructs in order to detect higher level Complex Event (CE). Generally, a CE correspond to the occurrence of multiple sensor events each of which may correspond to the crossing of a specific threshold by a sensor event for example. The mobile-based embedded sensors such as a gyroscope, accelerometer and Global Positioning System (GPS) are also fused with health sensor datastreams for providing context enrichment. A wearable Radio Frequency 1 www.spyglass-consulting.com
Identification (RFID) tag based real-time locating technology described in [2] can be adopted for tracking the location of a patient. Cooking Hacks2 provides cheap and efficient bluetooth and Wi-Fi enabled wireless health sensors which can forward physiological signals to an Android or iOS application by using its Application Programming Interface (API). Some other commercial health monitoring devices include Zeo Sleep Monitor which monitors sleep disorders like sleep apnea and ViSiMobile which can measure vital parameters such as Heart Rate (HR), Respiration Rate (RR), Oxygen Saturation (Spo2) and skin temperature. Current RPM methodologies collect the health signals using a mobile device such as a tablet or a smartphone and forward them to a remote hospital server for complex event detection. Such a technique necessitates the mobile device to be connected to the network at all times. Moreover, such a system can lead to large network usage leading to a high mobile network cost incurred by the user, service unavailability in case of no network condition in rural areas, out-of-order delivery of different data stream tuples and performance bottlenecks at the server due to queuing. The research presented in this paper introduces a Mobile device based CEP (MCEP): a novel CEP technique which leverages edge computing for performing remote patient monitoring. We have adopted an empirical approach for analyzing the viability and efficacy of MCEP through a proof-of-concept prototype built using an embedded Siddhi CEP engine [3] on the mobile edge device. The Siddhi CEP engine is an open source and lightweight CEP engine used by many fortune 500 companies including UBER which uses it to process 20 billion events/day. It provides Siddhi streaming SQL which uses SQL like grammar to write CEP queries. To the best of our knowledge, this is the first mobile RPM system in which the entire CEP is done within a mobile device and the detected complex events are sent to an IoT server for generating notifications as well as further processing. The key contributions of this paper include: 1) A novel edge-computing based CEP technique that has a number of benefits over existing centralized CEP approaches that include: • The ability to inform the patient of an impending health problem even when the phone is unable to connect to the hospital server due to poor network connectivity. 2 www.my-signals.com
A multi-tiered architecture that can allow the distribution of the workload between the edge device and the hospital server. 2) A proof-of-concept prototype using an Android smartphone to demonstrate the effectiveness of the technique. 3) Insights into system performance and system behavior based on experiments made on the prototype. The rest of this paper is organized as follows. Section II describes a representative set of related work and Section III discusses the system architecture. Implementation details for the proof of concept prototype are discussed in Section IV and Section V presents a performance analysis of the system. Finally, Section VI provides our conclusions and directions for future work.
data is collected using MySignals wearable sensors and sent to a RaspberryPi device, which forwards the data to a WSO2 Data Analytics Server (DAS)5 for historical analysis. Triggered alarms are sent to cardiologists using a web-based console and to caregivers using a mobile-based visualization module. The major limitation of the aforementioned techniques is that the mobile device is simply used as a forwarding agent while CEP is done on a remote server and thus the techniques rely on the availability of network connectivity at all times. None of these existing works can raise an alarm notifying a health problem for the patient when the network becomes unavailable. This problem is effectively addressed by the methodology and system proposed in this paper.
II. R ELATED W ORK
The system architecture6 is explained in the context of the proof-of-concept prototype built using the embedded Siddhi CEP engine on the mobile device and the WSO2 IoT server7 on a back-end hospital server. As shown in Figure 1, the system is three-tiered consisting of various sensors, a mobile device and a remote IoT Hospital Server (IHS). Various sensors can send health sensor data streams to the mobile device using a bluetooth or Wi-Fi connection whereas the mobile device can communicate with the IHS using the Wi-Fi or cellular network. The WSO2 agent is a firmware application which enrolls the mobile device with the IoT server and further provides various authentication and authorization mechanisms for communication between the device and the IHS.
•
Kamel and George have proposed a Remote Patient Tracking and Monitoring system (RPTM) [4]. In their system, medical sensors send health sensor data streams to an Androidbased mobile device, which are then encrypted using the Advanced Encryption Standard (AES) encryption mechanism and forwarded to a General Packet Radio Services (GPRS) server for detecting complex events. Stipkovic et al. [5] developed a mobile CEP prototype system using an unofficial port of the Esper CEP engine on Android called Esper-Android. Unfortunately, the project is incomplete as support for Esper-Android has been discontinued due to third-party library dependencies not supported by Android. Banos et al. have built a ubiquitous RPM system called PhysioDroid [6] which consists of wearable monitoring devices, a mobile device such as a smartphone and a remote persistent storage system. The mobile device acts as an edge gateway to collect and upload sensor data to the remote persistent storage. Pathak and Vaidehi [7] have developed a CEP-based Remote Health Monitoring System (CRHMS), that can receive various biological parameters such as heart rate, respiration rate, and blood pressure using Zephyr Bio Harness3 sensors. These sensor data streams are sent to an Android phone which forwards them to JBoss Drools Fusion CEP Engine4 for complex event detection. Kakria et al. [8] have developed a server-based RPM system for monitoring cardiac issues such as Tachycardia and Bradycardia. They used a 3-tier architecture consisting of physiological sensors, an Android mobile device, and a web portal. An event forwarding application runs on the Android device, which receives sensor data using the Bluetooth Low Energy (BLE) technology. This data is then transferred to a web server using the eXtensible Messaging and Presence Protocol (XMPP) and complex events are predicted using fuzzy logic. In 2018, Rodriguez et al. have made a Complex Event Processing system for Heart Failure Prediction (CEP4HFP) system which uses predictive analytics on patient’s historical database to predict a possible heart stroke [9]. They used a 3-tier architecture consisting of a monitoring, analysis and visualization modules. The health
III. S YSTEM ARCHITECTURE
Broker Mobile CEP Sensor data streams Patient
WSO2 Agent
Core Agent-IHS communication
CE stream Sensors
Mobile Device
Analytics (ELS)
Dashboard IHS
Figure 1: System architecture Figure 2 shows a high-level sequence diagram of the system architecture. Initially, the mobile device is registered with the IoT hospital server using a WSO2 agent application. Once device registration is successful, a device management service is started on the IHS core and the agent application. This service is responsible for various functions such as authenticating the device periodically, managing phone calls, device information, device location and sending the required information to the IHS in an encrypted manner. The mosquito broker is started on the IHS broker which is responsible for sending CE from mobile device (Publisher) to the hospital server (Subscriber). The mosquito broker uses the Message 5 docs.wso2.com/display/DAS310/Introducing+DAS
3 https://www.zephyranywhere.com/system/components
6 Some
4 https://www.drools.org/
7 https://wso2.com/iot
of the icons used in the paper are taken from www.flaticon.com
:Sensors
:MCEP
:Agent App
Strict
:IHS Broker
:IHS Core
:IHS Analytics
Send Device Enrollment Request Start device management service
Sensor data streams
Start mosquitto broker
Start device management Start service ELS
(b)
Subscribe to a topic
Start CEP service loop [CE detected == true] Publish complex events to topic
Publish CE stream to subscriber
Update dashboard
Figure 2: A sequence diagram of the system architecture
Queuing Telemetry Transport (MQTT) pub-sub system in which publishers send data to subscribers using topics. The Event Listener Service (ELS) that starts running inside the IHS analytics tier subscribes to a topic: topicpid where pid is the unique patient id. Device registration is a one-time process after which each time the device is rebooted, it is authenticated using device-specific stored information on a server such as International Mobile Equipment Identity (IMEI) number. Now, the patient can select a CEP query from a drop-down menu using the Graphical User Interface (GUI) and the MCEP application will automatically check network availability. If the network is available, then the MQTT service is started in the background along with the CEP service. Otherwise, only the CEP service is started. The CEP service will open input sockets to receive sensor data streams and detect complex events according to the selected CEP query. Every detected complex event is timestamped with detection time and sent to the mosquito broker on a-priori determined topic. These events are then updated to the dashboard running on the IHS analytics tier to notify hospital staff. IV. I MPLEMENTATION D ETAILS The implementation details for the mobile CEP application as well as the IoT server are discussed below. 1) Mobile CEP Application: A proof of concept prototype for MCEP is built using Android Studio 3.1.1 Integrated Development Environment (IDE) using Gradle build tools version 27.0.3. Figure 3 shows the various components of the mobile CEP application. These components have been labeled with a superscript ranging from a to j, that correspond to the order of event flow in the system. Solid lines represent multiple parallel data streams while dashed lines represent a single data stream. The various components that have been shown as stacked over one another indicate multiple instances of that component running in parallel. The basic functionality of each component is explained next: (a) Query Repository: Prior to running the CEP engine, the appropriate query from a drop-down menu needs to be selected using phone GUI. Each CEP query should be written by a health professional and should correspond to a particular disease such as CHF and arrhythmia. The
(c)
(d)
(e)
(f)
selected query is parsed into a query tree which is further converted to an execution plan [1] [10]. Socket Objects: Note that there is a tuple for each event that is generated when a sensor output is sent to the mobile device. Multiple sockets receive input data streams from various sensors concurrently, de-serialize streams and parse the respective streams into JavaScript Object Notation (JSON) tuples. Further, event arrival time is appended to each tuple which is enqueued at a threadsafe LinkedBlocking queue that processes it in a FirstIn-First-Out (FIFO) order. Thread-safe Queue: Every stream is associated with a separate queue. A producer-consumer queue paradigm is used in which tuples are added by a worker 1 thread at the tail of the queue and are removed from the head by worker 2 thread in a concurrent fashion. The worker 2 thread continuously checks whether there is any tuple to process in the respective queue. If so, it fetches the tuple from the head of the queue and then appends the event ingestion time using the mobile device system clock and sends it to the source mapper. Source Mapper: The mobile CEP can receive streams in multiple formats which are mapped to a common Siddhi event format using the source mapper. Multiple instances of the source mapper perform mapping of various input streams in parallel. Input GUI Handler: In Android, a handler provides communication between the main GUI thread and the other background threads. Multiple input handler instances (one for each sensor) update live sensor data to the GUI in a parallel fashion. CEP Execution Plan: The CEP execution plan is the query representation used by the CEP engine for processing events. A CEP query can be of two types: a pattern query or a non-pattern query. A pattern query is used to detect a pattern based on the sequence of events as well as by matching CEP predicates from multiple streams. On the other side, the non-pattern query only involves c Worker 2 Thread-safe Queue
Source Mapper
d e
Input GUI Handler
Worker 1
b Socket
Sensor data streams
CEP Service CEP ExecutionPlan
Sink Mapper
MQTT Service (Sink) Complex event stream to IoT server
h
f
Query Repository
a
g
Statistics Computer
i j
Output GUI Handler
Figure 3: Components of the mobile CEP application
(g)
(h)
(i) (j)
the CEP predicates such as filter, projection, selection and join [11]. For a pattern query, a Non-deterministic Finite Automaton (NFA) representation is used by the CEP engine. On the other hand, for a non-pattern query, an operator tree is formed such that the leaf nodes receive tuples from multiple sensor data streams and the root node emits the CEP event stream. Multiple execution plans corresponding to different diseases can also run in parallel such that each execution plan has an isolated event processing environment. Sink Mapper: It converts Siddhi events to JSON events which are then forwarded to a statistic computer and a sink such as the MQTT service. MQTT Service: This service publishes JSON complex event stream on a particular topic to the mosquito broker running on the IHS broker. Statistics Computer: It computes various CEP statistics and sends them to the output GUI handler. Output GUI Handler: Multiple parallel instances of the output GUI handler update various CEP statistics on the mobile phone GUI.
Algorithm 1 shows the high-level logic used for devising the mobile CEP application running on the mobile device. Here, it is assumed that before the algorithm runs, the patient has already registered with the hospital server. As soon as the MCEP application is started, the availability of the wireless network on the device is checked automatically. If the network is available line 1 , then login to IHS is performed. If the login is successful line 3 , then three services are started: device management service, MQTT service, and CEP service. The device management service is responsible for authentication, authorization, and encryption of data exchanged between the mobile device and the IoT sever. The MQTT service forwards complex events corresponding to a particular topic to the hospital server using the mosquito broker. If the login is not successful, only the CEP service is started line 8 . If the is not available, only the CEP service is started network line 11 and network availability is checked periodically such that device management service and MQTT service are started if network becomes available. Once the CEP service is started, then the patient is prompted to select a particular type of query related to his/her problem. This query is pre-programmed in the application and can be changed by a medical professional from IHS. An application runtime is created based on the selected query line 19 . The selected query is responsible for detecting the complex event that depends on the condition of the patient being monitored. This is discussed further in section V. For receiving the input stream from sensor y , a socket object (sockety ) is created on a new thread line 23 . Further, an InputHandlery is created which is responsible for receiving a stream and send it to the CEP engine. Various sockets receive the sensor streams in parallel and perform deserialization of stream data from binary to JSON event tuple for each received tuple line 27 . Event arrival time is noted using a nanosecond precision system clock and appended to
Algorithm 1: Mobile CEP Algorithm 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
if Network is available then Login into the server using valid credentials if Login is successful then Start Device management service Start MQTT service Start CEP service else Start CEP service end else Start CEP service Check network availability periodically if Network is available then Start MQTT service Start Device management service end end Queryy ← Selected query from the drop-down menu AppRuntime ← CreateSiddhiAppRuntime(Queryy ) IsAppRunning ← True AppRuntime.start() foreach Sensory do Sockety ← Create socket object InputHandlery ← GetInputHandler(Streamy ) while IsAppRunning do Sockety .receive(T uple) foreach Tuple do Perform de-serialization ArrivalT ime ← System.nanotime() Append T uple to a thread-safe FIFO queue Update GUI using InputHandlery end end end foreach Queuey do while AppRunning do if Queuey .isEmpty == False then IngestionT ime ← System.nanotime() InputHandlery .send() Queuey .remove() end end end foreach Complex event detected do Use sink mapper to change event format Send an event to StatisticComputer() Call M QT T service() end
the event tuple line 29 . Then, the tuple is en-queued to a thread-safe LinkedBlocking queue following a FIFO order and the GUI is updated. A thread-safe queue is preferable in a producer-consumer scenario as it provides concurrency
control mechanisms such as mutex problems due to to avoid race conditions. For each queue line 35 , another thread runs in parallel which checks whether the queue contains any tuple and if so, it appends the event ingestion time line 38 before sending the tuple to the engine using the respective input handler: InputHandlery . Finally, that event is de-queued from the LinkedBlocking queue. As soon as the complex event is detected, it is sent using a stream callback to a statistic computer which computes the necessary metrics and updates the GUI. Also, detected CE is sent to the MQTT service which forwards it to a mosquito broker on a specific topic in order to forward it to the IHS. 2) IoT Hospital Server: The IHS is built using an open source WSO2 IoT Server (IoTS) and can be deployed in a standalone mode on a single server, on a High Availability (HA) cluster or a cloud. It provides support for batch, realtime, interactive and predictive analytics. The hospital server has a 3-tier architecture consisting of the broker, core, and analytics components as shown in Figure 1. Further, a dashboard plug-in is installed in the analytics tier to generate notifications for the hospital staff. Due to the length constraint of this paper, further details on the hospital server could not be provided. V. P ERFORMANCE A NALYSIS As shown in Figure 4, the experimental setup includes three components: a computer workstation, a mobile device, and a wireless router. The sensor simulator module and the IHS are deployed on a computer workstation having 16GB RAM, a 3.5 GHz Intel Core i7 Processor and a 1TB SSD running on High Sierra MacOS. A Google Pixel smart-phone having 4GB RAM, 32GB storage, an AArch64 quadcore processor running Android Nougat is used as the mobile device. A 5 GHz AC1750 Tp-Link dual-band wireless router with a maximum bandwidth of 1350 Mbps is used to transfer data between the workstation and the mobile device. WSO2 IoT server version 3.0 was used along with its compatible Android agent version 3.1.27 on the mobile device. Siddhi streaming SQL version 4.0 is used to define CEP queries. In Figure 4, we can see that both sensor simulator and the IHS components are running on a single computer workstation. The rationale for running them on the same machine is the fact that event time-stamping is done using the same clock and hence end-to-end latency can be computed when this system will be compared with the server-based CEP system (a scenario to be considered in future research). The complex event use case considered in the performance analysis is presented next.
Sensor Simulator IoT Hospital Server Workstation
Sensor data streams Complex event stream Mobile
Router
Figure 4: Experimental setup for mobile CEP system
A. The Complex Event Use Case Modeling The pattern query presented in Table IV is used for detecting complex events from the two streams of events Stream A and B generated by the sensor simulator. Note that an event from stream A and stream B are referred to as A and B respectively in the following discussion. The query leads to the detection of a complex event if CountA instances of event A with tuple values larger than or equal to T hA are followed by CountB instances of event B with tuple values larger than equal to T hB . Count A and Count B is an integer
lying in the range bounded by minA : to maxA : and
:min B to :maxB respectively. Special cases such as minA : and :maxA correspond to the situations in which event A must occur at least minA times or at most maxA times respectively. The within Twin construct used at the end of the query signifies that the computations described earlier are made for events occurring within a time window size of Twin . Streams A and B are used to model the output of a heart rate and a respiration rate sensor respectively. A complex event that corresponds to both the heart rate and the respiration rate going above their respective thresholds specified through T hA and T hB can be detected by specifying the appropriate threshold values for A and B. Such a CE may signal an impending heart problem requiring a notification for the health service provider. More complex queries are required for handling more complex situations (e.g. a person falling down) detected with the help of multiple sensors [12]. A detailed description of the sensor simulator module is presented next. B. Sensor Simulator This module is used to generate sensor events by using a synthetic dataset and send them to the mobile device. The synthetic dataset is used because of the ability to control various tuple values for each stream that in turn controls the number of complex events that will be generated. In the synthetic dataset, the tuple values are uniformly distributed integers ranging from 1 to 100. The event tuple generated by the sensor simulator in the JSON format consists of meta-data and payload data as shown in Table I. Patientid is required at the IHS in order to uniquely identify a patient when multiple patients are enrolled to RPM service. Also, a combination of Patientid , Sensorid , and Tupleid can be used to uniquely identify any event received at the IHS when multiple patients are enrolled. The various event times captured during the the experiments are shown in Figure 5 and described in Table II. It is important to note that Ta , Ti , and Td are timestamped at the mobile device using the same nanosecond precision clock whereas Tg and Tn are timestamped at the sensor simulator and the IHS respectively. In Figure 5, the multiple instances of input streams (one for each sensor) are shown in parallel such that tuples in the nth sensor data stream (where n ∈ 1 . . . y) are denoted by Tan and Tin as arrival time and ingestion time respectively. However, as complex events generated from a pattern involves multiple sensor data events, only one complex event is shown on the right hand side of Figure 5. Note that only Ta , Ti , and Td that are generated at the mobile device
are used in the determination of the performance metrics used in the performance analysis. Table I: Tuple format Field
Type
Description
Patientid Sensorid Tupleid Value Tg
metadata metadata metadata payload payload
Unique to each patient Unique for each sensor for a patient Auto-incrementing integer for each tuple Uniformly distributed integer A nanosecond precision time-stamp
End-to-End delay Transmission delay
Queuing delay
CEP latency
Transmission delay
tuple queuing latency (Q). Let Tax and Tix be the arrival time and ingestion time respectively for the earliest arriving event among all the events from the different streams that led to the complex event. The CEP specific metrics are explained as follows: 1) Average complex event processing latency (L): A complex event is the result of the arrival of multiple sensor data events. The latency of a CE is measured from the time of ingestion (Ti ) for the first event (from any stream) that leads to a complex event to the time at which the complex event gets detected (Td ). If the total number of complex events detected during an experiment is N , then the average CEP latency is given by Equation 1. N P
Mobile device
~
~ ~
Figure 5: Various event times Table II: Various times associated with an event Event time Tg Ta Ti Td Tn
Description Event Event Event Event Event
generation time arrival time at the queue ingestion time by CEP engine detection time by CEP engine notification time
Timestamped at Respective sensor Mobile device Mobile device Mobile device IoT server
L=
x=1
(1) N 2) Average CEP Queuing Delay (Q): An event upon arrival at the mobile device waits in a FIFO queue before it gets ingested by the CEP engine. The average queuing delay for a complex event is defined as the average of the queuing delay corresponding to all the N complex events as given by Equation 2. The expression within the summation term on the numerator of Equation 2 is the queuing delay for the xth complex event and is determined as the difference between the ingestion time for the earliest event that led to the xth complex event and the arrival time for the same event on the mobile device. N P
C. Workload and System Parameters A synthetic workload comprising two streams A and B is used in the performance analysis. Factor-at-a-time experiments were performed on the system in which one parameter was varied in a given experiment while other were held at their default values. The various values for the workload parameter λ and the system parameters such as CountA , CountB , T hA , T hB and time window (Twin ) used in the experiments are presented in Table III. The value in the boldface for each parameter corresponds to the default value of the parameter. Note that tuples corresponding to each stream (A or B) are generated by using a constant inter-arrival time of λ1 milliseconds. D. Performance Metrics CEP specific performance metrics used in the analysis are average complex event processing latency (L) and average Table III: Workload and system parameters Parameter
Description
Units
λi CountA CountB T hA T hB Twin
100, 500, 1000, 1500, 2000, 3000 500, 1000, 1500 500, 1000, 1500 10, 30, 50, 70, 90 10, 30, 50, 70, 90 0.05, 0.1, 0.2, 10, 20, 30
Events/second Integer Integer Integer Integer Seconds
Tdx − Tix
Q=
x=1
Tix − Tax
(2) N 3) Average CEP Throughput (µ): It is the rate at which the complex events are emitted by the CEP engine. E. Analysis of experimental results Each experiment was repeated 5 times and the resulting values of a given performance metric were found to be close to one another. The performance metrics used for generating the graphs are averages of the respective values measured in the different runs. The results of the experiments that capture the relationship between the system/workload parameters and various performance metrics are discussed next. 1) Effect of CountB and T hB on L: The effect of threshold for event B (T hB ) on the average CEP latency is presented in Figure 6. Note that in the graph legend, the minimum and maximum values of CountA and CountB are presented. Given a specific value of CountB , L is observed to increase with respect to T hB . In the synthetic workload, the sensor data values corresponding to stream B are uniformly distributed between 1 and 100. Thus, as T hB increases, the time it takes to receive tuples with values higher than or equal to T hB increase as a result of which L increases. For a given T hB , the average CEP latency seems to increase with an increase in the value of CountB . As CountB increases, it takes more time for the CE to occur as a result of which L increases.
Table IV: CEP Query Name P attern1
Description
every A V alueA ≥ T hA minA : maxA → B V alueB ≥ T hB minB : maxB within Twin
to wait for a longer period of time in the queue, as the CEP engine is processing the events that arrived earlier. This leads to an increase in Q with an increase in λ.
Figure 6: Effect of T hB and CountB on L 2) Effect of λ on L: As shown in Figure 7, the variation in L with the arrival rate λ displays a non-monotonic behavior.
Figure 8: Effect of λ on Q 4) Effect of λ on µ: As shown in Figure 9, with an increase in the arrival rate, the CEP throughput increases as more arrival rate means that more possible combinations of event A followed by event B resulting in a higher CEP throughput. When the arrival rate is increased to more than 2000 events/second, no further increase in CEP throughput is observed due to the CEP engine saturation which is also captured in Figure 7 in which the CEP latency is increased exponentially at λ ≥ 2000 events/second.
Figure 7: Effect of λ on L There seem to be two counteracting factors that determine the value of L. The first is the time for the required number of tuples that can trigger a CE to arrive on the system and the second is the queuing delay experienced by the tuples before they can be processed by the CEP engine. At very low values of λ, there is very little queuing and the first factor dominates the system performance. Thus, as the arrival rates increases, the complex events are detected more quickly and L decreases. At higher values of arrival rate, the system contention increases and more and more queuing starts occurring in the system. Once a certain value of λ is reached, the second factor starts dominating the system performance and L starts increasing with respect to λ. 3) Effect of λ on Q: Figure 8 shows the effect of event arrival rate on average CEP queuing latency. As arrival rate increases, the number of complex events generated per unit time increases. As a result, the events that lead to a CE need
Figure 9: Effect of λ on µ 5) Effect of Twin on L: The impact of the size of the time window on L is presented in Figure 10. Initially, with an increase in the size of the time window the L is observed to increase. Note that as soon as a window expires, the events accumulated in the previous window are flushed and the system starts looking for CE using the new events arriving on the system. Thus, increasing the size of the window allows
complex events with higher latencies to occur on the system. Thus, with an increase in Twin , more CE with higher latencies seem to occur on the system resulting in higher values of L. It is interesting to note the value of L tends to flatten off after a window size of 100 milliseconds is reached.
We believe that with modest effort, the proposed architecture can be extended to other systems that use sensors connected to a mobile device. Directions for further research include the following: • Performing performance analysis of a system in which the hospital server is connected to multiple mobile devices each of which corresponds to a specific patient. • Comparing the existing mobile CEP system with a server CEP system in which the entire CEP is done on the IHS. • Designing a methodology to partition the query workload between the mobile device and the hospital server. • Investigation of a hybrid architecture that performs streaming analytics on the mobile device and predictive and batch analytics using stored data on the hospital server. VII. ACKNOWLEDGMENTS
Figure 10: Effect of Twin on L
We are grateful to TELUS and Natural Sciences and Engineering Research Council (NSERC) of Canada for providing financial support for this research. R EFERENCES
VI. C ONCLUSIONS AND F UTURE W ORK This paper describes an architecture and a prototype for a mobile device based CEP system for remote patient monitoring. The proposed MCEP system uses edge-computing and performs the detection of complex events on the mobile device and sends the results to a back-end hospital server for further processing. Experimentation with a synthetic workload demonstrates the effectiveness of the technique and also leads to a number of insights regarding the impact of various system and workload parameters on system behavior and performance, that are summarized as follows: • Increasing the threshold for events in stream B and CountB have a similar impact on the average CEP latency (see Figure 6). Increasing any of these parameters increases the time of occurrence for a CE that leads to an increase in L. • It is interesting to observe the non-monotonic relationship between λ and L. Initially, as λ increases the L decreases, but after the value of 500 events/second is reached, any further increase in λ leads to an increase on the average CEP latency (see Figure 7). • As the arrival rate increases, contention for system resources increases and the average queuing time for events increases (see Figure 8). The system throughput is also observed to increase with an increase in λ but tends to flatten off when λ reaches 2000 events/second (which corresponds to the saturation point for the system). This indicates that for the system and workload parameters experimented, the system is scalable for arrival rates lower than 2000 events/second. • An increase in the size of the Twin tends to increase L (see Figure 10). After a window size of 100 milliseconds is reached, any further increase in the time window size does not produce any significant changes in L.
[1] Shivnath Babu and Jennifer Widom. Continuous queries over data streams. ACM Sigmod Record, 30(3):109–120, 2001. [2] Daqiang Zhang, Laurence Tianruo Yang, Min Chen, Shengjie Zhao, Minyi Guo, and Yin Zhang. Real-time locating systems using active RFID for Internet of Things. IEEE Systems Journal, 10(3):1226–1235, 2016. [3] Sriskandarajah Suhothayan, Kasun Gajasinghe, Isuru Loku Narangoda, Subash Chaturanga, Srinath Perera, and Vishaka Nanayakkara. Siddhi: A second look at complex event processing architectures. In Proceedings of the 2011 ACM workshop on Gateway computing environments, pages 43–50. ACM, 2011. [4] Mohammed Kamel and Loay George. Remote Patient Tracking and Monitoring System. International Journal of Computer Science and Mobile Computing, 2(12):88–94, 2013. [5] Sebastian Stipkovic, Ralf Bruns, and Jurgen Dunkel. Pervasive computing by mobile complex event processing. In e-Business Engineering (ICEBE), 2013 IEEE 10th International Conference on, pages 318–323. IEEE, 2013. [6] Oresti Banos, Claudia Villalonga, Miguel Damas, Peter Gloesekoetter, Hector Pomares, and Ignacio Rojas. Physiodroid: Combining wearable health sensors and mobile devices for a ubiquitous, continuous, and personal monitoring. The Scientific World Journal, 2014, 2014. [7] Ravi Pathak and V Vaidehi. Complex Event Processing Based Remote Health Monitoring System. In Eco-friendly Computing and Communication Systems (ICECCS), 2014 3rd International Conference on, pages 61–66. IEEE, 2014. [8] Priyanka Kakria, NK Tripathi, and Peerapong Kitipawang. A real-time health monitoring system for remote cardiac patients using smartphone and wearable sensors. International journal of telemedicine and applications, 2015:8, 2015. [9] Afef Mdhaffar, Ismael Bouassida Rodriguez, Khalil Charfi, Leila Abid, and Bernd Freisleben. CEP4HFP: Complex Event Processing for Heart Failure Prediction. IEEE Transactions on NanoBioscience, 2017. [10] Arvind Arasu, Brian Babcock, Shivnath Babu, John Cieslewicz, Mayur Datar, Keith Ito, Rajeev Motwani, Utkarsh Srivastava, and Jennifer Widom. Stream: The stanford data stream management system. In Data Stream Management, pages 317–336. Springer, 2016. [11] Arvind Arasu, Shivnath Babu, and Jennifer Widom. The CQL continuous query language: semantic foundations and query execution. The VLDB Journal, 15(2):121–142, 2006. [12] Mohammad Ashfak Habib, Mas S Mohktar, Shahrul Bahyah Kamaruzzaman, Kheng Seang Lim, Tan Maw Pin, and Fatimah Ibrahim. Smartphone-based solutions for fall detection and prevention: challenges and open issues. Sensors, 14(4):7181–7208, 2014.
