1 Introduction

Current technology claims for a swift change from today’s data-centric model to a network which is proactively adaptive, reprogramming its services to the needs of the users, with the aim of providing a personalized experience and reducing effort when performing their daily tasks. As a consequence, people and their information must play a central role in technology, making their lives easier, and giving them personalized services in a proactive way.

In this context, present-day smartphones have more computing, storage, and communication capabilities than ever before [1]. In fact, smartphones have already become the main source of information transferred to the Internet. For making smartphones truly context-aware, we need to employ inference techniques for handling the information obtained from the environment. Following a mobile computing approach, the processing of information takes place in the smartphone itself, avoiding the need of a server for data processing purposes, thus enhancing privacy and reducing the need of online communication. This allows to generate better and quicker responses to the situations encountered by the user, increasing the interactivity and efficiency of the applications. However, for properly inferring the context of the user and taking decisions on it, we need to process data coming from different sources, including other smart devices in the surroundings.

In this paper, we explore the dynamism and reactive behavior of Mobile-based Collaborative Social Computing (MCSC) systems applying techniques of Complex Event Processing (CEP) [2, 3]. In particular, we present a distributed architecture with CEP nodes running in each smartphone. This way, we create a network through which mobile-deployed CEP engines exchange events to collaborate with each other and also to reach their individual goals. The distributed implementation presented in this work makes smartphones able to collaborate exchanging and processing messages with information coming from other smartphones with their own CEP engines installed on them. These messages are handled as CEP events, and they are used to obtain even more information from other users and reach new collaboration scenarios.

As a result, the smartphone is able to run CEP scripts or sets of rules corresponding to different purpose-specific applications that are installed in it. These scripts specify the behavior required to take decisions or to behave in a certain manner, for instance assisting the user to react to events coming from other smartphones, or to accomplish interactions with smart devices.

Additionally, in previous works we have exploited the capabilities of current smartphones in order to design the Digital Avatars (DA) framework [4]. Digital Avatars builds on a collaborative peer-to-peer architectural model, called People as a Service (PeaaS) [5]. PeaaS promotes the empowering of the smartphones to infer and maintain virtual profiles of their users with information about their context, preferences, habits, moves, etc. On top of that, the DA framework offers different interaction mechanisms for sharing the information in the digital avatar or virtual profile in a controlled way. Thus, the avatar can be used by third-party devices and applications to generate value-added services. In particular, the DA framework allows to interact with smart devices in the environment by downloading and running on-the-fly scripts both for updating the information of the avatar stored in the smartphone, and for configuring IoT devices to the needs and preferences of the user [6].

In this work we take advantage of the DA framework for deploying Collaborative CEP systems.

This integration enables us to consider the information available in the digital avatar, in order to react to the detected situations. Besides, new information coming from monitoring the user context, and from interactions performed by the CEP engine itself can be added to the digital avatar of the user.

As a proof of concept, we provide a Collaborative CEP implementation of a Cops and Robbers game, making the smartphones of the users to behave depending on their role in the game. By means of this case study, we illustrate some of the main features of our proposal, showing how to make smartphones interact showing complex behavior and with a collaborative purpose.

Finally, we evaluate the efficiency of our proposal, which shows promising results for being based on CEP engines running on resource-constrained devices like smartphones. Thus, the framework presented in this work becomes a powerful tool for building MCSC applications, addressing scenarios in which each user reaches their own goals making profit of information coming from other users and IoT gadgets. Each smartphone may be running a different script, attending to the purposes and intentions of their user, but even though the script was the same in all of them, each one may react in a different way by taking into account the user information stored in the avatar.

After this introduction, the rest of this work is structured as follows. In Sect. 2, we introduce the DA framework, while Sect. 3 focuses on the communication architecture of interacting CEP engines which is one of the main contributions of this paper. In Sect. 4, we present the Cops and Robbers case study. Next, Sect. 5 details the evaluation made for this work giving the results obtained from the tests conducted, while Sect. 6 compiles and discusses related works. Finally, we draw our conclusions together with some lines of future work in Sect. 7.

2 Background

The DA framework provides different ways of personalized and dynamic interaction with third-party services and devices. In our proposal, the traditional client/server approach breaks down into a decentralized architecture in which each smartphone node acts as server of its own produced data.

In order to show how CEP fits in the DA framework as an inference engine, we first introduce the architecture of the framework. Then, we focus on the functions of the CEP engine itself, both for providing third-party applications with context information of the user, and for interacting with other people’s avatars and external devices.

2.1 Digital avatars architecture

All the components of the Digital Avatars architecture reside in the smartphone. The whole framework is deployed as a single Android app, so it relies on Android OS calls to access any particular functionality or resource of the smartphone (like Bluetooth connectivity, GPS positioning, or any other sensors available). The only external component needed is a standard push service to exchange messages between smartphones. The framework runs in background in a transparent way. It also provides the user with a management interface so that the framework can be configured and its services switched on/off.

Fig. 1
figure 1

Software architecture deployed in the smartphone

Full size image

Figure 1 shows the architecture of the framework. We distinguish four main components: the Digital Avatar, the Digital Avatar Controller (DAC), the Inference Engine, and the Execution Core.

The digital avatar stores the virtual profile of the user, consisting in both raw and inferred information about them. It also keeps their privacy settings, their contacts, and any purpose-specific information managed by the different DA applications installed in the smartphone. The digital avatar is offered as a service by the DAC, which handles the access to the information in it. For that purpose, it provides an API with operations for managing this information, and preventing unauthorized access by taking always into account the privacy settings established by the user. Thus, the DAC represents a single and easy-to-use point for interacting with the digital avatar.

Next to it, the Execution Core, is designed for context-based interactions. For that, it is able to detect, download on-the-fly, and run in the smartphone scripts that interact with the avatar. A typical script states instructions for querying and/or updating the digital avatar, together with some other actions, such as showing notifications to the user, etc. For more information about the Execution Core and these scripts, we refer to [7].

Instead, in this work we will focus on the interaction between the digital avatar and the Inference Engine. In the implementation of the DA architecture presented in this paper, the information in the digital avatar is modelled as JavaScript Object Notation (JSON) objects which are stored in Couchbase Lite, a NoSQL database system for smartphones. The DAC API exposes the digital avatar as a REST-like service, accessed locally from the smartphone. This way, it can be employed by third-party developers through the Execution Core or through the Android Broadcast channel from their own applications installed in the smartphone. Finally, for the Inference Engine, we make use of CEP. CEP is a cutting-edge technology providing an architecture and mechanisms permitting to discover complex events or situations by analyzing and correlating data coming from different sources [8]. We employ a CEP engine embedded in the smartphone for extracting meaningful information from the raw data coming from built-in sensors, interactions with surrounding smart things, etc., by applying CEP rules that govern the inference and evolution of the digital avatar. A more detailed description of the use of CEP as an inference engine for the digital avatar, which is one of the main contributions of this paper, is presented in the following subsection.

2.2 Running CEP engines in smartphones

CEP is a collection of concepts and techniques that allow real-time analysis of large amounts of data coming from different sources. CEP scripts are sets of rules for the detection of event patterns in data streams. Their purpose is to detect situations of interest, and to react to them according to what is stated in the rules. One of the main advantages of CEP compared with other event analysis software is that it works in real time, reducing latency in the decision-making process [9].

In this work, we use CEP for processing the events and external stimuli in the user context, and for writing the rules that make the smartphone react to them. This way, a Collaborative CEP application is based on a script defining CEP rules for interacting with the user context and for monitoring the user activity. From the analysis of low-level event notifications of raw data coming from the sensors in the smartphone or other smart devices, complex information and situations of interest for the user are inferred, and knowledge is built from them and stored in the digital avatar for the specific needs of Collaborative CEP applications installed in the smartphone.

Mainly, CEP engines are deployed in servers using a centralized model to detect domain-specific critical situations. However, our proposal integrates CEP in the smartphones, propitiating a distributed framework with the aim of building MCSC applications based on CEP engines and digital avatars which infer high-level information on the context, preferences, and habits of the users, and which are stored in their own smartphones. A few similar approaches can be found in the literature, usually under the name of mobile CEP [10]. However, they use an agent-based approach which relies on a single CEP instance, not communicating smartphones—each one endowed with a CEP instance—which are independent and collaborate between them. Anyway, these works show that this smartphone approach has implicit advantages, as there is no need to implement communication between the sensors and the CEP engine.

In our proposal, everything relies on the smartphone, keeping the user information private and coherent. However, smartphones still show computing and battery limitations. Hence, we need a fast, lightweight CEP engine that processes events directly in mobile devices. Asper is an open source mobile version of the Esper CEP engine for Android developed by [11]. This engine worked fine with old Android versions, but at the present time the project has been discontinued, and there is no updated version of Asper compatible with current smartphones, due to dependencies on third-party libraries not compatible with recent Android releases. Instead, we use Siddhi [12], which is an open source feature-rich stream processing platform from WSO2, successfully extended to AndroidFootnote 1 and also Raspberry Pi devices by the use of plugins. The SiddhiQL query language is very similar to Esper’s Event Processing Language (EPL) (which is the SQL-based reference query language for CEP engines), and it includes the main types of operators needed to write CEP rules: select, filter, window, aggregations, group by, having, join, and patterns. Combining these operators, we are able to build applications that infer a person’s behavior and habits.

The behavior of the Siddhi engine relays on the Collaborative CEP applications running on the smartphone. These applications can provide scripts that can be dynamically installed in the engine and are composed by a set of CEP rules for detecting domain-specific event patterns which allow the applications to obtain the desired results and react to certain situations depending on incoming data. The Siddhi IO Android pluginFootnote 2 endowes the engine with additional capabilities inherent to the smartphones, like the management of built-in sensors by the use of sources and sinks.

Sources are producers of simple events for the Siddhi engine. In the Siddhi IO Android plugin we find sources for the different sensors present in smartphones, i.e. GPS, accelerometer, gyroscope, or even the step counter software-based sensor. The events generated by a source are sent to the engine by the different streams of data defined in the Siddhi scripts.

On the other side, sinks are the actuators or output streams available to produce an effect when an event is detected by the engine. The Siddhi IO Android plugin provides three different sinks: one to produce a sound in the smartphone; another one for showing notifications to the user with information on the detected event; and last, a BroadcastSink that is used to conduct an event to an Android BroadcastReceiver. This way, Siddhi permits defining purpose-specific receivers to treat the detected situations if we want to go further than just showing a notification. As we will show in Sect. 3, both Siddhi’s sets of sinks and sources can be extended to implement application-specific features and communication means.

3 Collaborative CEP

The main purpose of Collaborative CEP is making easy to build MCSC applications by providing rich interaction services based on the information about a user contained in the digital avatar stored in their smartphone. From these interactions, new context information of the user environment is added to the digital avatar, too. With this purpose in mind, we have implemented an extension of the Siddhi CEP engine to include new features for enabling smartphones to interact with each other by means of push notifications transmitted between them. The resulting framework allows third-party developers to build context-aware CEP applications that support collaboration between smartphones and consequently between their corresponding users.

In this section, we explain how these communications are implemented, and how we have extended the Siddhi engine in order to support this distributed CEP architecture. The full implementation of the Collaborative CEP framework described in this paper is available online in a GitHub repository.Footnote 3

3.1 Communication architecture

Let us consider a collaborative scenario as that shown in Fig. 2, in which several users are endued with smartphones which contain their digital avatars and a Siddhi CEP engine. Each of the engines may be running a different set of rules, corresponding to the different Collaborative CEP applications installed in the smartphone, the user preferences, or their habits. We will show how these users can collaborate either to reach a common goal, or just to obtain new context information exchanging messages between the CEP engines.

Fig. 2
figure 2

Communication architecture of Collaborative CEP

Full size image

The collaboration between users is accomplished by push notifications that are generated in any of the Siddhi engines and received by the rest for processing them. Any Collaborative CEP application script running in the Siddhi engine can send push notifications when some relevant situation is detected. Depending on the CEP rules stored in each engine, it may react in a different way to a given event coming from the outside.

For sending out push notifications, we make use of the well-known Push Notifications Service Firebase MessagingFootnote 4 technology. However, Firebase only permits sending push notifications using an API key that must be assigned to a server. Thus, for sending notifications from smartphones in an autonomous way, we use a Notifications Server provided by the OneSignalFootnote 5 platform. OneSignal is a market leader system for customer engagement, powering mobile push, web push, email, and in-app messages. It provides a cloud service with an Android native API (among several other platforms) to receive a notification from a smartphone, and then it uses the application Firebase API key to distribute it to a set of recipients. In addition, OneSignal offers a free tier with enough capacity for testing our implementation.

In the figure, the Siddhi engine of the smartphone in the left detects a situation of interest that must be communicated to other users (represented by the smartphones in the right). Thus, it prepares the corresponding notification event, specifies its recipients, and sends it to the OneSignal server (top). The server uses the Firebase Messaging API key to send the event as a push notification to all the recipients specified (right). The receiving smartphones get the notification and introduce the event in their Siddhi engine stream in order to process it. The integration of the OneSignal cloud push notification service in the Collaborative CEP framework is possible thanks to the native Android API tools it provides. A NotificationExtenderService must be declared in the Siddhi CEP engine in order to listen to any incoming push notification. This listener handles the messages and extracts all the information they contain.

Moreover, we need to secure the communication and guarantee the identity of the message emitter. For this purpose, we rely on an Authentication Service, Firebase Authentication,Footnote 6 which provides the means for using the OAuth 2.0 and OpenID standards in order to securely authenticate the user who signs the messages sent. This signature is not other than the Firebase token ID which is included internally in every message sent by the user logged into the Collaborative CEP framework.

3.2 Extending sources

Apart from the specific sources provided by the Siddhi IO Android plugin (like AccelerometerSensorSource, ProximitySensorSource, etc.), new components have to be implemented to support additional functionalities such as communication between CEP engines running in smartphones. With that purpose, we have extended Siddhi with two new artifacts: a DAMessageHandler and a DAMessageSource. These are in charge of receiving and parsing incoming push notifications as events for the Siddhi engine, respectively.

Being an open source project, the code of the Siddhi IO Android plugin can be freely downloaded and updated. In order to extend the set of sources, we have defined a new derivate of the generic Source class and implemented its methods. In particular, we have built over the functionality already supported by one of the Siddhi IO Android sources, called BroadcastReceiverSource, which is prepared to listen to any event that occurs in the smartphone through the broadcast stream of Android. Thus, we implemented a new Siddhi source class, called DAMessageSource. Every source class must define a type name. This name is the one used in the script to declare the source. In Code 1, we can see the DA-message declared type which refers to the DAMessageSource class. This way, any instance of a source of this type is prepared to listen to certain events from the Android broadcast stream, in particular the push notifications events which we will call from now on DAMessageEvent.

The DAMessageHandler class implements the already mentioned OneSignal NotificationExtenderService listener provided in its API to receive push notifications. Every time a push notification is received, the DAMessageHandler authenticates the sender using the Firebase Authentication functionality with the email and token ID included in the notification, and then handles and parses it into a DAMessageEvent format.

We can see how a notification looks like in Code 4. Notifications include three main parts. The first one is an email which identifies the sender (line 8). The second is a text field (line 9) which can be employed for showing a message to the user receiving the notification. The third part is a JSON data object (lines 10–13) which contains the attributes of the event emitted by the sender CEP engine together any other additional information, in particular, the receiving application identifier. As it can be seen in Code 1, the additional attributes identify the application to whom the notification corresponds (appID), the signature of the sender (in the title field of the notification), and a body composed of a text and/or a set of event attributes. Indeed, several applications may be installed in the recipient Siddhi engine. As a received notification may correspond to any of them, an application identifier (appID, in line 11) is sent together with the message in the data field to distribute the notification to the correct application stream inside the engine.

Once the notification is parsed, the DAMessageHandler sends the received DAMessageEvent through the Android broadcast stream using the declared application identifier appID. Next, the DAMessageSource receives the message and puts it in the stream of events declared for that particular application.

figure a

With this Siddhi extension, the developers of any Collaborative CEP application need only to declare a source of type DA-message with their application identifier in the Siddhi script. In fact, an example of such an instance is shown in Code 1. Then, the instantiated DAMessageSource detects the DAMessageEvents using that appID, and includes them in its specific application stream (inMessageStream) to be processed. In the example, the events received are simple notifications with the name of the sender in their title.

3.3 Extending sinks

As with the sources, it was necessary to implement a new sink class for sending push notifications through the OneSignal API. This is the DAMessageSink class, defining the DA-message sink type, and which provides the functionality required for sending a push notification to a Siddhi engine running in another smartphone. An instance of the implemented sink is shown in Code 2 using the defined type.

figure b

A sink of type DA-message defines several parameters which correspond to the different fields of the notification. First, we find the application identifier which is sending the message (CopsNRobbers), and the message recipients (players). Then, we find the body of the notification with the event attributes, in the example, we are just using the reserved attribute message for sending a notification, however, if the event had more attributes, they are listed together to be included in the JSON data field of the notification. As an option, the attributes of the received event can be used to complete this message body which can be used later by its receiver Siddhi engine to show a notification. Summing up, the DAMessageSink parses the message attribute as the notification body and the rest of the event attributes into a JSON object which is encapsulated inside the data field of the notification together with the identifier of the application, and the user ID token.

Once the entire notification body is parsed, we include the headers with the recipients specified and the user email. There can be several recipients identified by their email accounts. However, the name of a privacy group stored in the digital avatar of the user (in the example, the players of the CopsNRobbers application) can be given to send the message to all the participants. The sink reads the information from the digital avatar through the DAC API and fulfills the recipients of the message. The sender must be correctly authenticated to sign the message. For that, we use the Firebase user logged email and ID token which are included in the notification.

3.4 Authenticating communications

In the previous subsections we have shown how to extend Siddhi to enable communication through push notifications between CEP engines running in smartphones. In order to ensure the security of the communications in the Collaborative CEP framework, any notification exchanged must be signed by the sender. This way the receivers may decide if they trust the sender and accept the message or not. For determining the identity of the sender of a notification, we rely on Firebase Authentication. This tool makes use of OAuth 2.0 and OpenID standards for user authentication. When users are logged into the Collaborative CEP framework, a Firebase ID token is assigned to uniquely identify them. These are JWT tokens that securely identify a user within a Firebase project. They contain basic profile information such as the user name and email, together with a unique UUID identifier of the user inside the project, and an expiration timestamp. As the integrity of the ID token can be verified, it is possible to identify an user through it.

The Firebase Admin SDK provides tools for verifying and decoding ID tokens. For that, it is required to obtain a project API key, and the whole process is intended to be performed in a server, not in a smartphone. Hence, we have developed a simple NodeJS server that accepts authentication requests from smartphones (see Code 3). The server receives the ID token of a user (line 3), checking its format and integrity, and whether it is up to date (line 4). Then, it decodes the token and obtains the UUID and email of the user, which is compared with that specified in the received notification (lines 5–7).

figure c

4 Case study: a cops and robbers playground

Once we have described the Collaborative CEP framework for MCSC applications, in this section we present a simple implementation of a Collaborative CEP application in order to illustrate the technical details of the proposal.

4.1 Overview

We have developed a simple case study based on the Cops and Robbers game for showing the viability and validating the proposal. The full implementation of the Cops and Robbers application is available in GitHub .Footnote 7

In this simplified version of the game, the players are divided into two groups: cops and robbers. The game is played in an open air playground, where loots are scattered around. Robbers will try to steal as many loots as possible, while cops will try to catch and put the robbers under arrest before they do it. A robber will be able to steal a loot if he is close enough to it and there are no cops around. A robber will get arrested if there are at least two cops close enough to him. The game finishes whenever the robbers have stolen all the loots, or all of them have been arrested by the cops.

4.2 Implementation

The Cops and Robbers game is implemented through a Collaborative CEP application deployed in the smartphones of the players. Every situation or use case of the game is implemented using CEP rules for detecting the event patterns which allow the game to progress. The rules of the game can be easily changed without need to modify the Collaborative CEP framework itself.

Additionally, we have implemented a simple Cops &Robbers Android app which interacts both with the Collaborative CEP framework, and with the user of the smartphone, through a simple GUI. This app is in charge of maintaining the local state of the game in the player’s smartphone, including the role (cop or robber) of the player, the loots stolen, etc.

In the Collaborative CEP implementation of the Cops and Robbers game, loots are represented by a Bluetooth Low Energy (BLE) beacon. The players bear their mobile phones, whose Bluetooth sensors are able to detect the proximity of the loots. Additionally, both cops and robbers regularly broadcast a BLE signal too, with their role and ID for other players to detect them. These signals are generated by the Cops &Robbers application using the Android Beacon Library.Footnote 8 Moreover, an additional Siddhi source (named BeaconSource) was specifically implemented using the same library for the purpose of receiving these beacon signals from the loots and other players. We make use of the Eddystone protocol to configure the BLE transmitters both for the loots and the smartphones. We use the URL payload field of the protocol to encapsulate information about the role and the identifier of the transmitter.

From the point of view of the Siddhi CEP engine in the players’ smartphones, the detection of a BLE signal from a loot or another player is a primary event (receiveBeacon). When a player receives one of these signals, the CEP engine consumes the event and classifies the signal by the role in its payload field. Then, a secondary event is generated, indicating that a cop, a robber, or a loot is in the vicinity of the player who has received the signal. These events are called copDetected, robberDetected or lootDetected, respectively, and they are sent back to the engine stream to process them. Each one of these detection events are handled by separate CEP rules in the CopsNRobbers Siddhi script.

The sequence of actions that taker place when a robber detects a loot near him is shown in Fig. 3. The robber first makes sure that there are no cops around, checking that he has not received a copDetected event during the last minute. The corresponding CEP rule is shown in Code 6. In that case, an event is put in the LootStolen stream, which corresponds to a BroadcastSink for communicating the attempt of robbery to the Cops &Robbers app through the Android broadcast channel.

Fig. 3
figure 3

Sequence diagram for stealing a loot activity

Full size image

In Code 7 we show an excerpt of the BroadcastReceiver implemented in the Cops &Robbers app. First, it checks that this particular loot has not been stolen yet (line 4). In that case, the robber is able to steal the loot, which is stored in the digital avatar of the robber, and the counter with the number of remaining loots is decremented (line 5). Additionally, a push notification is issued to the rest of the players announcing them the theft (lines 9–11). As you can see, this is done by creating a new Status event which is sent back to the Siddhi engine for the sink in Code 2 to receive it. When a robber steals the last remaining loot and the counter is set to 0, robbers win the game and the corresponding synchronization push notification is sent to the rest of the players (lines 13–15) with a game over message (shown in Code 4).

Cops react in a similar way when they receive a robberDetected event, triggering in the CEP engine an arrest event if the cop also detects another cop’s signal in the following minute. The corresponding CEP rule is shown in Code 5. Its activation implies that the cops outnumber the robber and the latter can be arrested. Hence, a push notification is sent to the robber to let him know that he has been arrested, showing a notification to the corresponding user (rule arrestedNotification, not shown in Code 5).

As we see, the implementation is based both on BLE signals and push notifications. BLE events are processed by CEP rules for detecting the proximity of both players and loots, updating the local state of the player receiving them. Push notifications are used for updating the global status of the game (that is, the local state of the rest of the players) communicating them the detected situations through the Cops &Robbers app running in the smartphone of each player, and making the game to progress. The implementation is fully distributed and loosely coupled.

An example of push notification sent through OneSignal is shown in Code 4. As it can be seen, we set the CopsNRobbers app ID, and then identify the channel being used (in this case with the -Status suffix). This is useful if we have different types of messages inside the same application for treating them in a different way, defining a DA-message source for each channel.

5 Evaluation

The Collaborative CEP framework is designed to continuously run in background in the user’s phone. However, smartphones are resource constrained devices in terms of battery life and computing capabilities. Thus, it is important to perform an evaluation in terms of efficiency and performance that proves the feasibility of the system and validates the proposal. Consequently, we have run a series of tests on the Collaborative CEP framework presented in this work. The tests were designed for evaluating the performance of the push communication architecture added to the framework, and the CPU and battery usage associated to the whole framework.

In a previous work [13], some of the authors of this paper have presented an exhaustive evaluation in order to compare cloud costs, data traffic, and energy consumption of MCSC applications using a cloud-centered, mobile-centered, and hybrid architecture running in mobile phones. The results showed that there are many situations in which a mobile-centered architecture –like that of the Collaborative CEP framework– performs better and more efficiently in terms of resource consumption. Nevertheless, in this section we evaluate how adding new elements such as a Siddhi CEP engine, BLE signals, and push notifications impact in the Collaborative CEP framework.

In order to validate our proposal we have conducted two different kinds of tests. First, we focused on the performance of the proposed communication architecture. Second, we evaluated the battery consumption of the Collaborative CEP framework. For the tests, we used the tools Android Profiler,Footnote 9 which provides real-time data about how an app uses CPU, memory, network, and battery resources, and Battery Historian,Footnote 10 which visualizes battery related information of either the whole Android system or any given application.

5.1 Performance of the communication architecture

In this subsection we evaluate the behavior of the communication architecture of Collaborative CEP under stress situations. Our aim is to study the limits of the developed proposal and see its viability to execute in computing and energy constrained devices. For a system permanently running in the background, we shall consider it not acceptable if it affects the overall user experience with their smartphone causing performance problems in it. In particular, we formulate the following research hypothesis for this evaluation:

  • RH1: The communication architecture does not have a relevant impact on the smartphone resources even under stress situations.

  • RH2: The transmission times for the messages must not be relevant for social purpose applications working in real time.

  • RH3: No message loss should occur on good connectivity conditions.

We measured the time required for transmitting push notifications between the smartphones, checked if they arrived in order, and whether some of them were lost in the way. We also measured their impact on CPU and battery usage.

To evaluate the system performance, we have conducted several experiments in which we sent out a large number of messages in batch using the push notification schema presented in Sect. 3.2. In order to make an accurate estimation of the transmission time, the messages need to be reflexive—sent and received by the same device. The experiments were deployed using two different smartphones: a LG G5 and a Redmi Note 8T, representing old or low range specification smartphones. This will evidence if the system is viable for running in the majority of actual smartphones which have better specifications.

We performed experiments with 100, 300, and 500 messages sent at once, repeating the tests ten times on each smartphone, so statistical information could be obtained.

Fig. 4
figure 4

Android Profiler CPU trace during a reflexive 300-message stress test of the Collaborative CEP framework

Full size image

Looking at the traces recorded with Android Profiler when performing the experiments, we observe an overload produced when sending the whole batch of messages, as they are sent and received by the same smartphone, as previously said. Hence, there is a time in which the smartphone starts receiving messages before having sent all of them yet. This phenomenon can be observed at Fig. 4, in the magnified bottom part of the image. There we can see how the gdigitalavatars thread, which is in charge of sending the messages is still active while the AsyncTask3 task starts receiving the first messages. For analyzing the behaviour of the system avoiding this situation, we decided to conduct another experiment, this time sending the messages between the two smartphones (one sending, one receiving). Now, as can be observed in Fig. 5, the overload at the beginning of the test disappears and the CPU usage peaks does not even reach a 20% of the computing capabilities of the device. Hence, we conclude that even in stress situations, pushing the system to its limits by sending/receiving up to 500 messages at once, there is no evidence of notable impact on smartphone resources, validating RH1.

Fig. 5
figure 5

Android Profiler CPU trace during a 300-message stress test of the Collaborative CEP framework, using two different smartphones

Full size image

Now, we can statistically analyze the data obtained from all the tests made. The results obtained are shown in Table 1. We start with the 100-message test. For the LG phone we obtained a total delivery time of 17.61 s with a mean delivery time for each message of 0.155 s. With the Redmi phone we obtained similar results, with a mean of 14.36 s for transmitting the 100 messages with 0.133 s as mean time between two consecutive messages. The difference can be explained as the LG is a 2016 smartphone with a 4 cores CPU and the Redmi is a 2019 smartphone with an octa-core CPU. If we move to the 300-message tests, the numbers go in the same direction: the LG took 52.85 s to deliver the 300 messages showing a similar delivery time per message, while the Redmi presented a mean total delivery time of 39.98 s with 0.126 s between messages. One thing to remark at this point is that in two of the ten LG tests, one and four messages were not received and went lost, respectively. Finally, for the 500-message tests, we observed that both smartphones progressed more or less in a linear way showing very similar mean delivery times compared to the 100 and 300-message tests. Additionally, in the 500-message tests we appreciated similar message losses in both smartphones, with no more than 10 messages.

Table 1 Results obtained from performance testing in LG G5 and Redmi Note 8T smartphones
Full size table

We observe that the system behavior conforms to RH2 and RH3 with a limit on between 300 and 500 messages sent at once, obtaining times of less than a minute to deliver all the messages and not appreciating losses at least in one of the smartphones.

A relevant aspect to note at this point is that we did not receive the messages in order in any of the tests made. Preserving message order is not ensured by the platform, and this must be taken into account while developing Collaborative CEP applications. Another fact that can be observed in the results obtained is that the first message always takes longer to arrive, and this delay increases with the number of messages sent at once. However, the mean time between messages is maintained through all the tests. This is due to the overload period previously observed.

Fig. 6
figure 6

Android Profiler traces for Collaborative CEP framework during stress tests using batching windows operators

Full size image

Making the Siddhi engine evaluate more complex time operators may impact on the results obtained in our tests. Thus, we repeated the experiment using batch or sliding windows, measuring again the average time between messages. We obtained very similar results which are shown in Fig. 6. There we can observe how using this kind of operator still does not suppose an evident impact on CPU usage. More and more complex rules may be studied, however, at this point we are interested in abstracting from the Siddhi’s engine performance, to focus on our communication architecture, which is the contribution of the paper.

5.2 Battery consumption

Battery consumption is a critical issue in mobile devices and one of the concerns that may prevent users to install a new app in their phones. Thus, in relation to RH1 we have also performed different tests for estimating battery usage of the Collaborative CEP framework. With these experiments, we wanted to simulate the normal activity that an application using the framework may cause to see the real impact that using the framework may have on the smartphone energy consumption.

The first experiment consisted on running a prototypical MCSC application for an extended period of time. The application was repeatedly sending one single message every 10, 5, 3, 2 and 1 s. Second, we conducted two more experiments with the framework running the Cops and Robbers application for 3 and 6 h, respectively. During these executions push notifications were received by the application at a rate of about one message per minute, additionally to the background BLE process of scanning and broadcasting the players’ beacons. For the experiments, we used the Battery Historian tool for analyzing the usage of smartphone resources.

The results obtained in all tests were similar. No message was lost, they arrived in order, and the mean delivery time was 0.7 s. In Fig. 7 we observe how the transmission of messages has no visible effect in the energy plot, and is very little appreciated in the CPU plot.

Fig. 7
figure 7

Android Profiler trace for Collaborative CEP framework during a reflexive test of one message each five seconds

Full size image

In Fig. 8 we show the results for the 6-hour experiment. At the bottom, we can see the jobs scheduled, being the BLE scan job active for the 6 h of the test, while the message handler was activated 307 times for receiving messages during the run. In the analysis made by Battery Historian, these jobs caused a usage of a 0.05% of battery resources, which is a very low figure.

Fig. 8
figure 8

Battery analysis for the 6-hour run of Cops and Robbers in the Collaborative CEP framework

Full size image

The experiment shows that the Collaborative CEP framework works at an acceptable performance level being able to send and receive more than 300 message events in batch without loss and causing a light use of the smartphone resources. These tests prove the feasibility and validity of the framework conform our three Research Hypothesis, demonstrating a very good efficiency even with a CEP engine deployed in the smartphone. Again, all the recordings and results of the experiments can be found in the evaluation folder inside the GitHub repository .Footnote 11

6 Related work

A number of research and applied projects about Mobile and Distributed CEP can be found in the literature. However, most of those works are devoted to how to deal with the increasing amount of data generated that have to be processed as complex events and the challenges posed by non-standard nets, with low reliability or evolving topology, and made up of heterogeneous mobile devices with scarce resources that join and leave the network unpredictably.

[14] propose a decentralized CEP system to process BPMN events in commercial organizations. Two solutions are proposed to scale to a large number of events coming from varied sources: divide operators in simple operations, and placing specific operators in specific nodes and multiple clusters, scaling up the servers and allowing any server to process any type of event, by dividing the incoming data among the servers. A similar approach is presented in [15]. There, the authors propose a common platform to deal with events coming from different service providers which, indeed, can be incompatible among them. Their service platform could integrate different process execution engines by using a CEP engine, even if process execution services are based in different models or notations. These works are meant for standard networks, with nodes deployed on workstations and a sound infrastructure.

[16] deal with operator placement for distributed CEP in mobile ad-hoc networks. The main goal of their placement algorithms is to minimize energy consumption, as these kind of nets are usually made up of small nodes with limited batteries.

In [17], the authors present COMET, a solution to detect complex events in delay-tolerant networks, usually decentralized, with long delays, and frequent losses. Their work, that uses CED techniques for building trees that define the connections among nodes, lacks any implementation support.

[18] propose a pattern sensitive stream partitioning model capable of keeping a predictable buffer limit for large scale IoT applications. The model ensures a high degree of parallelization to deal consistently with a wide range of CEP operators, and allows a dynamic adaptation to the changing conditions of the incoming workload.

[19] present a solution to improve processing of events in sensor networks, where the volume of primitive events is very high and the transmission of data along the network has to be minimized to save as much sensors’ battery as possible. Their solution is based on In-Network Distributed CEP, assigning to the sensors more responsibility to process complex events. This proposal allows to detect distributed events based on disseminating distributed plans, for which the authors provide optimization techniques.

[20] present a simulation framework for distributed CEP to evaluate the performance of distributed CEP solutions which must process a huge quantity of data, with multiple brokers, and complex policies. The simulator tool has been designed to support a broad range of case studies and to behave in the same way for all of them. It relies of NS-3, a well-established network simulator.

A survey of proposals and methodologies on Distributed CEP is presented in [21]. Both this paper and the works surveyed in it focus on two main problems related to Distributed CEP: operator placement and in-network processing for handling with large amounts of data, fragile networks and mobile data sources. Most of works included in the paper are based on simulations.

CEP-Wizard is presented in [22] as a tool to make easier for users the deployment and configuration of distributed CEP engines, in order to process large amounts of incoming data. Users would only have to provide the data specification, rule definition, and cluster specification, and the tool’s rule allocator determines the optimal allocation of the rules in the machines that belongs to the cluster, optimizing resources.

In [23] the authors focus on privacy and security aspects for Distributed CEP operators placement using a trust-based approach. In fact, in this paper the developed Distributed CEP system is smartphone-based, too.

Focusing on Collaborative Computing, we have found only a few works that deal with the willing of the users to share their data proactively with the CEP server (see for instance [24]). Additionally, in [25] a mobile CEP system is proposed for searching the relevant users in a community to perform a collaborative analysis over the data collected by the whole community and giving precise and reasonable recommendations. However, in both cases, a centralized server equipped with a CEP engine is needed to aggregate the data from the relevant users found. Again smartphones are treated as mere gateways that transfer the information to the server to be processed, instead of promoting a real distributed collaboration among users as we propose. As far as we know, in the literature there are no works about communicating smartphone-based CEP engines for building distributed and collaborative systems, which is the focus of our work. This fact remarks the novelty of our proposal, that goes in an alternative direction from the related works reviewed.

7 Conclusions and future work

In this paper, we have shown how to use CEP as an inference engine for building MCSC applications, enabling the smartphones to monitor users’ activities and their context. By means of the Collaborative CEP framework, users can install and run purpose-specific applications providing context-aware services. Additionally, we have presented a communication architecture over the mobile CEP engines, allowing smartphones to collaborate with each other by exchanging push notifications, which are treated by the CEP engine as any other input event from the environment.

The framework takes the digital avatar of the user as the base to personalize the interactions with their digital environment. The information stored in the digital avatar is shared in different ways to allow third-party services to be context-aware, adapting to the preferences of the users.

As the CEP rules run in each engine may be different, our proposal makes it possible to build loose-coupled distributed systems with arbitrarily complex emerging behaviour. This way, each smartphone—taking into account the information it has about the user—may react in a different way to the events received, for reaching their user goals taking into account their preferences and context. We have called the resulting framework Collaborative CEP.

A case study consisting on a simplified Cops and Robbers game has been implemented with the framework, using the CEP engine to validate the rules of the game. With this implementation we were able to conduct an evaluation of the Collaborative CEP framework and the proposed inference engine and communication architecture in terms of performance and resource costs for the smartphone, which is a very important aspect when working this kind of mobile-based architectures.

The results of the experiments showed that the framework behaves reasonably even up to 500 messages transmitted in batch at once. Moreover, very low CPU usage is caused by message reception. Only a peak load for a short time period has been detected when sending hundreds of messages at once through the inference engine. In terms of battery consumption, we obtained very good results from the tools used for the analysis of long period executions of the case study. The average estimated battery consumption is 0.05% in 6-hour use, a very low impact in a normal smartphone usage along the day.

As future work, we plan to carry a more thorough evaluation involving a larger number of devices so the reliability and robustness of the system can be effectively validated. Additionally, we plan to land the Collaborative CEP framework in more complex and real world case studies such as remote health monitoring and home assisted living, as we believe it has demonstrated to be a technology that can perfectly fit in these environments. Moreover, we want to deepen in the security and privacy aspects of the framework to protect the sensible information of the user. To this extent, applying multilevel security policies (see for instance [26, 27]) that allow the classification of data and users based on a system of hierarchical security levels and trust will be considered.