Efficient context-aware computing: a systematic model for dynamic working memory updates in context-aware computing

Context-aware systems

Context awareness is becoming increasingly crucial in pervasive and ubiquitous computing. As early works Schilit & Theimer (1994) illustrate, context awareness was first limited to the location of objects and people. Recent advancements, however, have broadened the concept of context to include additional components, such as the social and physical features of entities and user behaviors (Rakib & Uddin, 2019; Dourish, 2004; Sarker, 2019). To comprehend the many characteristics of context, researchers conducted rigorous evaluations. Studies have examined user identity, social situations, location information, temporal data, and the surrounding environment, including objects and individuals (Schilit & Theimer, 1994; Brown, Bovey & Chen, 1997; Nazir, Sholla & Bashir, 2021; Ryan, Pascoe & Morse, 1997; Brown, 1995; Franklin & Flaschbart, 1998; Ward, Jones & Hopper, 1997; Hull, Neaves & Bedford-Roberts, 1997).

Moreover, the advent of social networks has played a significant role in gathering user information, preferences, and behavioral patterns (Sarker, 2018b; Sarker, 2018a). Gadgets and applications have emerged as valuable sources of user data. For example, the SociaCircuit Platform enables the monitoring of social interactions, facilitating the adaptation of user preferences (Chronis, Madan & Pentland, 2009). Other studies have utilized data mining tools, sociometric badges, and mobile sensors to track user activities, predict job satisfaction, analyze employee interactions, and identify significant locations based on social activities (Jung, 2009; Aly, Eskaf & Selim, 2017; Olguín et al., 2008; Eagle & Pentland, 2006).

Despite efforts to integrate complex expert systems into the Android platform, certain limitations persist. For example, the book “Build Android-Based Smart Applications” describes using rule engines on Android (Mukherjee, 2017). However, these rule engines frequently need more critical characteristics like context awareness, resource efficiency, and dynamic context utilization with preferences. For example, some rule engines do not offer OR operators. In contrast, others require authoring rules in code or storing separate files for each rule, which can be inconvenient for bigger systems. Technical issues arose during the porting of rule engines. Due to Drools’ memory-intensive nature, Eclipse encountered memory restrictions while converting files to Dalvik.

Similarly, Take required a Java compiler at runtime, while Jlisa experienced stack overflows on the Android platform. Furthermore, despite its compatibility concerns and high cost, the Jess rule engine posed challenges due to significant memory usage. Table 1 shows different rule engines available in the literature. Most of them are based on Rete algorithms, which are greedy algorithms that are not recommended for memory-constrained devices due to their memory-intensive nature.

Furthermore, Uddin et al. (2016) needs a systematic method for memory allocation instead of relying on fixed-size memory for execution, which may lead to problems discussed in detail in Ali et al. (2024). Notably, both Uddin et al. (2016) and Uddin (2019) need to incorporate a method for removing previously loaded rules from memory once it has reached capacity. Instead, rules are randomly removed, maybe including essential ones that will shortly be required for execution. This condition could send the system into an infinite loop if a vital rule needed for execution is inadvertently removed. The following subsection goes into preferences in greater detail.

Preferences

The fundamental idea behind preferences is to select a subset of the rule base instead of the entire set. The preferences can have a significant impact on the overall performance of the system. This technique allows the inference engine to iterate through a subset of rules, enhancing the system’s efficiency. This is particularly relevant for personalizing resource-constrained context-aware applications without modifying the primary rule base. Although preferences in multi-agent context-aware systems have received less attention (Brandt, Chabin & Geist, 2015), they hold importance in recommender applications (Abbas, Zhang & Khan, 2015), User Interface (UI) customization (Loitsch et al., 2017), rules for triggering context-awareness (Moore & Pham, 2015), personalizing notifications (Auda et al., 2018; Mehrotra, Hendley & Musolesi, 2016), and acting as tour guides (Manotumruksa, Macdonald & Ounis, 2016).

The basic approach in the methods above involves gathering user preferences and tailoring the user experience accordingly. Preferences were utilized for UI customization in terminals (Loitsch et al., 2017). The flow manager retrieves user preferences from a cloud-based server upon user login, enabling adjustments to the UI based on these choices and relevant information obtained from the user’s device via USB or NFC channel. In Alhamid et al. (2016), preferences were predicted from user-item selections, which can be an application software in the current context. User preferences can be computed based on the relationship between objects to uncover the underlying reasons for user behavior in specific situations. However, this approach may face a cold start problem due to limited initial information. Similarly, Manotumruksa, Macdonald & Ounis (2016) may encounter the same challenge when visiting new places or in situations with limited information. In this article, the technique is context-aware, meaning that context can be derived from the words in the user’s feedback remarks.

Location-based social networks (LBSN), such as Foursquare, offer context recommendations for places to visit. To make such a system context-aware, it should consider associated user information like the time of day and location. The authors employed word embedding to infer venue representation, user contextual preferences, and existing user preferences. Zhu et al. (2014) utilized context logs to mine a variety of popular context-aware preferences. However, these solutions require significant resources in terms of memory and computation, making them unsuitable for resource-constrained devices. To address this, Uddin & Rakib (2018) proposes a novel technique where users have control over their choices and are explicitly asked to indicate their interests in the knowledge base, enabling efficient resource utilization. While this approach seemed superior.

Compared to RETE algorithm-based solutions at the time, it lacked support for preferences once loaded. Over time, this approach accumulated significant overhead and consumed excessive memory, which posed a considerable challenge, especially considering the limited availability of memory resources. The current working memory updating technique is discussed in the next section.

Current working memory update methodology

In the current implementation proposed by Rakib & Haque (2014), the working memory is structured as a fixed-size container comprising static and dynamic components. The dynamic memory portion is limited in size, with each memory unit capable of storing a single context. Only facts stored in the dynamic memory are subject to being overwritten, a scenario triggered either by the agent’s memory reaching capacity or the arrival of a contradictory context in the working memory, regardless of its current occupancy. Upon arriving at a newly derived context, it compares with existing contexts to detect any conflicts. If a conflict arises, the conflicting context is replaced with the newly derived one. If the working memory is full, the new context is added by overwriting a random existing context. Due to the finite size of the working memory, the system may enter into an infinite execution loop if a goal proves unachievable without a mechanism to forcibly halt the inference engine. Similarly, the context targeted for removal could be critical and potentially necessary for imminent execution.

The Rete algorithm working memory updating is only the introduction/loading of new rule(s)/context(s) to working memory, as the applications based on the Rete algorithm claim memory almost equal to the rules set provided; due to this, there might not be any chance that a rule does not have sufficient space in memory to be loaded.

Proposed working memory update methodology

The memory size calculation has been proposed in our previous work Ali et al. (2024). We can select one of the three methods (DWM, APS, and SAPS) for memory calculation. After calculating the memory, the currently proposed technique is the final step toward memory-efficient utilization. Algorithm 1 shows the technique in detail.

This algorithm has three major parts: (i) First, the system will check whether the context(s) is loading for the first time through WM Flag. If it is false, there is no data, and the data is loading to the memory for the first time. So, the system will load the data directly without checking the other attributes. (ii) If the context(s) are already there and there is a new incoming context, the system will first check the preference. If the preference matches, then it means that the new context belongs to the same preference set. After this, the system will check the context with the existing contexts. The system will load the context into the memory if its consequent part is distinct. Conversely, the system will overwrite the context over the existing context, which will have the same consequence. (iii) If the preference does not match the existing one in memory, the system will then check if the preference matches any consequent part. If yes, the rule will be appended in memory in the next available free slot. In case of no, it is time to change the context(s) loaded in the memory as the incoming context shows the change of preference set. So, the system will remove all the rules of the old preference set, update the preference in memory, and start loading the rule(s) of the new preference set.

Algorithm 2 completes the framework for which the memory calculation model was introduced in our previous article, Ali et al. (2024). This algorithm minimizes the load over the memory by removing the context(s)that are no longer required, as the preference set has been changed. This algorithm overcomes the issue of critical context(s) removal, as the system now has sufficient memory to load all the required contexts, and there may not be a need to remove context(s) randomly due to lack of space in memory.

Figure 1 (Step 1) illustrates the preprocessing part introduced by the authors of Uddin (2019), where the rule set creation and preference set were introduced and followed in the same manner in this article. Figure 1 (Step 2) corresponds to our previous work published in Ali et al. (2024), where three algorithms, DWM, APS, and SAPS, have been introduced for the calculation of required working memory; these algorithms are also followed in the same context as they are working in the article which introduced it. Figure 1 (Step 3 WMUA) outlines the proposed workflow of this article that removes the preference set, which is no longer required for processing. In the next section, two different scenarios have been discussed to validate the proposed work.

Scenario 1 (patient care system)

The presented scenario is documented in Uddin (2019), encompasses 85 rules, and revolves around a patient care system. The ontology outlining the structure of this scenario is visually depicted in Fig. 2. While varied and extensive sets of steps for annotation and preference sets exist within this scenario, our focus in this discussion is primarily on memory usage. Notably, the creation and execution of preference sets will remain consistent.

The development of the rule set yielded seven preference sets, exemplified by a sample of rules illustrated in Fig. 3. The rules set and preference set were generated following the methodology introduced by Uddin (2019). This snapshot provides a glimpse into the complexity and richness of the rule-based system designed for the patient care scenario, as detailed in the comprehensive case study. For memory calculation, APS was employed, as SAPS and DWM do not align well with the requirements of this scenario  (Ali et al., 2024). Since the standard deviation exceeded 2, it is advised not to adhere to SAPS, as recommended by the authors. The proposed algorithm executed memory updating.

The RETE algorithm poses a challenge due to its memory-intensive nature, loading almost all 85 rules into memory without considering preference sets (on Raspberry PI 3B, it consumed 405 bytes). In contrast, the preference-sets-based method, as observed in our case, demands a minimum space for 40 rules with a memory requirement of 220 bytes. Notably, the absence of a memory requirement calculation technique in the preference-sets-based method leads to random memory allocation, an issue effectively addressed in our prior work Ali et al. (2024).

While the preference-sets-based method exhibits a nearly 59% reduction in memory requirements in this instance, it encounters difficulties when the available memory lacks space for incoming rules or contexts. This method lacks a mechanism to remove preference sets no longer in use. Consequently, when a new context emerges, the method randomly removes existing contexts to accommodate the incoming one. This random removal process introduces the risk of discarding critical contexts, potentially leading to unforeseen issues or, in some cases, causing an infinite loop.

In our prior article, Ali et al. (2024), we introduced three distinct methods, DWM, APS, and SAPS, enabling the calculation of memory requirements. For the same set of rules, these methods yield memory requirements of 45 rules (236 bytes), 30 rules (136 bytes), and 30 rules (136 bytes), respectively (APS employed here). Integrating these methods with the currently proposed one forms a comprehensive framework. This framework excels by eliminating preference sets no longer needed for processing, ensuring a systematic approach. Consequently, this technique eradicates the necessity for random removal of contexts, enabling the system to operate seamlessly. Notably, it exhibits a remarkable efficiency with a percentage difference of 22.22% compared to the Preference-Sets-Based-Method and 78.82% compared to RETE-Based-Algorithms, contributing to a significantly improved system performance described in Fig. 4.

Working memory updating results for scenario 1

Table 2 presents working memory update steps that were utilized for the comparative analysis of three algorithms, WMUA, RETE, and PSBM, based on the number of rules involved at different steps of their execution. Some of the steps can run in parallel in the patient care scenario. However, to better understand the results, we implemented it sequentially in Table 2. In total, there are 30 steps in the scenario. The Rete and the proposed WMUA algorithm were implemented per the algorithm recommendation. However, as the PSBM algorithm claims memory randomly, we implement it with different memory claims three times for better understanding and comparison. The memory required first for ten rules, second for 20 rules, and third for 40 rules, as shown in Figs. 5, 6, and 7, respectively. The figures show that the more we increase the memory size, the more PSBM behaves like the Rete algorithm regarding memory consumption. In Fig. 7, both are exact matches.

Similarly, suppose we chose less memory for the PSBM algorithm. In that case, rules need to be randomly removed from the memory to make room for incoming rules, which leads to other issues that have been thoroughly discussed in Ali et al. (2024). WMUA consistently demonstrates the lowest number of rules among the three algorithms across most steps.

This suggests that WMUA is adept at managing and processing rules with almost no redundancy, making it an attractive choice for scenarios where computational resources are limited or speed is critical. The average percentage difference in Rete and WMUA algorithm results is 103.49%, meaning WMUA needs almost half of the DWM compared to Rete. Similarly, WMUA also outperformed the PSBM algorithm with a minimum average percentage difference of 74.45%. However, when the memory size for PSBM increases, the difference also increases. These results make the WMUA algorithm better for memory and processing-constrained devices.

Scenario 2 (smart home)

The smart home scenario has also been published in Uddin (2019). The total number of rules in this scenario is 32, and the number of preferences sets in this rule set is 2. The ontology outlined in Fig. 8 shows the structure of the scenario. Table 3 shows the steps involved in scenario 24 in number. Here, we also consider the sequential fashion for simplicity and a better understanding of the scenario’s results. These 24 steps were utilized to analyze the performance of the three algorithms.

Working memory updates results for scenario 2

The Rete and WMUA algorithms were implemented as per the recommendation of the algorithms in both the results shown in Figs. 8 and 9. However, for the PSBM algorithm in the first experiment, the memory was fixed for 10 rules and in the second for 20 rules, respectively. In these results, PSBM and WMUA perform similarly till step number 16; after this step, there is a preference change, and the WMUA algorithm removes the rules and clears space for upcoming rules. The PSBM memory limit in the first experiment is 10, and it reaches its limit on step number 14. After that, the algorithm needs to remove a rule randomly for each new upcoming rule, which may lead to different problems discussed in our previous article (Ali et al., 2024) in detail. In experiment number 2, shown in Fig. 9, it did not reach its limit (that is 20 rules at most) and continuously moved up word by introducing new rules to memory. The Rete algorithm showed its memory-intensive nature from step number 4 and onward in both results shown in Figs. 8 and 9.

The average percentage difference here in this scenario also follows a similar trend. That is the average percentage difference between Rete and WMUA in this scenario is 54.34%. Similarly, the minimum difference between PSBM and WMUA calculated for the result shown in Fig. 8 is 25%, and it will increase for the result shown in Fig. 9 which becomes 34.57%. Here, in this scenario, the WMUA also outperformed both algorithms.