1. Introduction
The vast majority of connected devices in UbiComp can process information; however, some are just designed to monitor data and transmit it to another device for computation. Consider a smart thermostat that senses external climate and triggers the Air Conditioner unit to auto-start if it’s too hot and humid or adjusts the temperature while it is running. This sort of smart and pervasive nature attracts customers. These devices can interact in a sort of learning that allows them to acquire and store knowledge, as well as change user preferences. Statistics [1] predicted that, by 2027, 41 billion connected devices will be inducted into IoT mesh, it’s a massive quantity. Their data collecting and processing requirements will need more efficient and reliable edge nodes. They must be capable of managing digital data created inside a safe, trustworthy, and self-regulating ecosystem of smart objects. When neither side has experience or awareness of the other’s reputation, there is always some risk associated with transactions. In the UbiComp ecosystem, a typical connection with a network provider may be obsolete. It may have been substituted with a far more stringent link involving lots of new unknown associations, networking devices, and providers. Furthermore, these devices may be highly mobile. Mobility will affect the dynamics of networks, needing significant modification. To deal with this amount of uncertainty and risk in UbiComp scenarios, it is critical to establish acceptable and effective approaches. These measures should foster trust and aid communicative entities in completing secure transactions.
Experience is a sociological concept that describes what happens when two things interact in the past. As a result of every engagement, the parties involved become more aware of one another’s activities (i.e., whether or not they met expectations). M-Webster dictionary explains experience as “direct observation of or participation in events as a basis of knowledge”. The same dictionary also says the experience is “the fact or state of having been affected by or gained knowledge through direct observation or participation”. Experience is the result of collective awareness of the activity of entities, which depicts their interrelationship. The more experience one has, the more valuable it is in establishing trust.
The human-centered equivalent of experience and trust also applies to D2D interaction in a ubiquitous word. In a nutshell, the experience is subjective and environment-dependent. This implies that the behavior of a single device may vary depending on the environment in which it is used. For the same set of devices, the experience may also differ depending on the situation. When two entities do not have a history of direct communication, a trust link can be built through sentential experiences generated by the recommendations. The experience can be modeled in the ubiquitous environment utilizing device interactions/events. These interactions/events can be logged and analyzed to provide a better understanding of the experience. In our previous work, a trust and context-aware access control framework [2] and an experience model [3] were proposed.
This paper presents an access control framework based on experience and logical device type as context parameters. Logical device types considered are CONSTRAINT, SEMIPOWERFUL, and POWERFUL depending on their networking environment [4]. This model considers the human notion of trust to build experience. As a foundation for modeling experience, trust and reputation are seen as essential. However, a fundamental component or attribute of a node, ubiquity, is given less emphasis [5]. Our approach calculates a node’s experience by weighing ubiquity equally or more. As a result, our model calculates overall experience using attributes including history, reliability, transitivity, and ubiquity, which are discussed in more depth in the next sections.
The remaining sections of the paper are organized as follows: Related work and experience modeling is discussed in Section 2 and Section 3 respectively. Section 4 and Section 5 are about the proposed experience-based access control (EX-BAC) model and EX-BAC framework. Experiment scenarios and results are discussed in Section 6 and Section 7 presents an evaluation of EX-BAC. Section 8 concludes the paper.
2. Related Work
2.1. Trust Management Schemes
Numerous approaches have been developed to formalize trust in a variety of areas, including peer-to-peer networks [6] [7], pervasive computing [8], and the IoT [9]. Recent methods [10] [11] began employing an ML approach to generalize and formalize trust models, in contrast to previous methods that were context or domain-specific. These models may be divided into two types: centralized and distributed models. [12] proposes a distributed way to manage trust based on direct interactions among edge things. The model estimates trustworthiness using the beta distribution and measurement theory. To measure uncertainty in the model, a supplementary characteristic, confidence, is employed in conjunction with direct interactions. In [13], the author presented a trust management approach for IoT (TRM-IoT) sensor device collaboration and inferring decisions based on fuzzy logic. Based on direct and indirect interactions, the final trustworthiness score is generated using fuzzy logic. Models in [12], [13] lacks context-awareness factors.
A strategy for trust-based context-aware access management using fuzzy logic (FTBAC) in the IoT is outlined in [14]. They base trust on three factors: experience, knowledge, and suggestion. The author [15] presented a methodology for evaluating trust that was based on direct and indirect interactions, and knowledge. This method concentrates on the SIoT context and incorporates data from direct observations. The model also considers experience with a global reputation to encompass heterogeneous dimensions of trust. The CBSTM for the IoT [16] is intended to foster collaboration among trusted nodes while limiting malicious node interaction. The significance of the context, compute power, confidence, and feedback all influence the node transaction factor. TAS-IoT model [17] —Device-level message authentication is used in the Internet of Things (IoT) concept. Depending on who sent the communication, the device decides whether or not to authenticate it. In CTMS-SIOT [18], the author adopted a feedback system. In [19] Trust management model based on fuzzy logic is proposed which is a generic model of trust based on behavior, recommendation belief and uncertainty. Evaluation of discussed models is summarized in Table 1
![]()
Table 1. Summary of trust management schemes.
based on whether the following five characteristics are considered or not:
· Context-aware—It refers to the ability of a model to consider context information.
· Direct Trust—Trust based on direct interactions between nodes. This parameter checks whether the model considers historical interaction while calculating overall trust.
· Transitivity—When there is no interaction with a new node, a node may rely on its trusted peer nodes to collect transitive trust of this fresh interaction.
· Reliability—Reliability parameters confirms how reliable a subject is and is calculated based on recent interactions.
· Ubiquity—It refers to the mobile nature of nodes in an access network.
2.2. Access Control Models
Devices were primitive in the early days of computing. Security to those devices was provided using username and password for the device. Only persons with username passwords can access systems. When network-based systems were introduced, and multiple entities started accessing systems, new securities provisions were adapted based on different roles and security concerns. Traditional access control models which were introduced during evolution, such as ACM, ACL, DAC, MAC, role-based access control (R-BAC) are founded on the principle that computers can predict who their users will be. Traditional AC techniques work well in a centralized, reasonably stable environment. In these environments subjects and objects are familiar, their permissions are rarely altered.
In an era of ubiquitous computing, the market is flooded with different types of devices, and new devices are coming at a rapid speed. Mobility in these devices adds the requirement of context-awareness like location, time, and other environmental factors to be considered while designing access control models. This type of environment created a challenge to provide a robust, flexible, scalable AC model.
B. Cha [20] introduced the A-BAC approach, which uses characteristics to determine AC decisions. Scalability and flexibility, making it suited for distributed systems like IoT and UbiComp. Wang et al. [21] and Smari et al. [22] described the problem of using standards (A-BAC) that don’t have provision for context handling and trust attribute. They extended the existing model (E-ABAC) to accommodate context and Trust, which makes the model usable for collaborative computing. Yitao and John [23] introduced key-based encryption and used physical tags to encrypt session keys. The proposed solution achieved high security and context awareness but the solution is not scalable due to the limitation of the number of keys that can be created. Trust between users is achieved as physical tags are used which are considered to be provided by a competent authority but misuse of tags is not considered in the solution.
3. Experience Modeling
3.1. Fundamental Concept
Previous work [3] presented a mathematical model for experience in the UbiComp environment. Quantifying the concept of experience will help us design solutions more efficiently. The requester or subject is the node that makes the request, whereas the service owner or object is the node that fulfills it. B denotes a requester, while A denotes an owner.
The experience score of A on B is indeed a positive integer between 0 and 1 and denoted as.
: Indicates strong positive experience of A on B.
: A had a neutral or no experience on B (default).
: A had a negative experience on B.
3.2. Attributes of Experience Model
Figure 1 shows a model of experience calculation using parameters such as HI, RL, TR, and UB. This model includes novel parameter ubiquity. The experience score (EX) represents a node’s experience with another node. A higher experience score value indicates a better probability of the node’s trustworthiness. The model shows experience is a function of these four parameters: HI, RL, TR, and UB. This can be used to compute the experience as per Equation (1).
(1)
![]()
Figure 1. Components of experience calculation.
3.2.1. History (HI)
History or history attribute [3] is calculated using several previous interactions subject node B has with A. It may be assumed that a target device is more reliable if there are a large number of interactions over time that are both consistent and frequent. Take a scenario, for context c, A needs to compute the HI for B for nth interaction. B to A interactions is denoted by the symbol
, and depending on the time of occurrence, are recorded as positive or negative. A calculates the aggregate of each past positive as well as a negative experience with B. It is denoted as PB and FB. History attribute is calculated as shown in Equation (2).
(2)
where
is confidence,
and is
uncertainty,
.
The success of interactions will always be unclear when little or no knowledge is present. The uncertainty factor is between [0, 1]. There are fewer interactions between A and B as the level of uncertainty approaches one. There are enough interactions to calculate the HI attribute if this value is close to 0.
3.2.2. Reliability (RL)
The term “Reliability” is described as “the ability of an item to perform a required function under stated conditions for a stated time period” [24]. Reliability measures how reliable or trustworthy a gadget is based on an assessment of its prior interactions in a given time. Because sensing, processing, and transmitting information in real-time are critical in UbiComp, reliability is vital for effective communication. If Node B consistently produces successful results for A, a conclusion can be taken that Node B is reliable for node A. Node A can compute the reliability of node B based on recent interactions record between B→A. When node B interacts with node A. A total number of interactions in window W is denoted as nr. Reliability in context c is calculated as shown in Equation (3).
(3)
where,
= Maximum number of previous interactions taken into account for calculating reputation in context c.
= Total interactions such that (
).
= Number of positive interactions in window W in context c.
3.2.3. Transitivity (TR)
In a given context, transitivity indicates a transitive trust link between the subject node and other reliable buddy nodes. In practice, trust is often not transitive and is only useful in limited situations. The work in [25] discussed the importance of having trust objectives that are identical and semantically consistent throughout transitive trust paths. This means that in one context, if A trusts B and in the same context B also trusts C, then only it is possible to build a trust path between A and C, and of course in the same context. If there are not enough interactions between B and A, A can query its other active peers in the network about B’s experiences. Consider, peer node C then
represents the experience of A with C.
is C’s experience about B. When A receives a request from B for a resource or service, A discovers that the two have never interacted before. Because of this, A sends out requests to all of its trustworthy associates, urging them to pass on their experiences to B. C revert backs to A with its EX regarding B. If A feels that this score is sufficient to grant B’s request, B will be granted access. This will create a transitive trust path between A and B and will be denoted as,
.
will be calculated as,
.
is nothing but a transitive experience score. When a node gets transitive experiences from peers
, the transitive aggregate experience is determined as stated in Equation (4).
(4)
3.2.4. Ubiquity (UB)
Ubiquity refers to the degree to which a node is ubiquitous, demonstrating its movable nature. Nodes are more ubiquitous when they are moving; they are less ubiquitous when they are static or move slowly. According to [5], during an interaction, if node speed increases beyond a certain speed, packet drop happens. As a result, ubiquity can be exploited to adjust experience calculations. To illustrate, suppose that A trustor node wishes to send data to a particular location. In case the node remains static for the whole packet transfer, its experience will be computed, considering the node is non-movable. Assuming that node is now moving during packet transmission, effecting increased packet drop and lowering the experience value. Packet loss is related to the node’s speed; the faster the node, the greater the packet loss. Observations show that device ubiquity affects the entire communication experience, hence the ubiquity component UB is included in the experience model.
Theoretically, if the speed of the node is between the minimum speed Vmin, and the estimated average speed Vavg, the mobility factor mf, is set to 1. When this mf is set to 1, no change is made to the experience value. Thus, it can be expected that whether a node is static or moving at the permissible minimum speed, the experience value will remain unchanged. mf decreases as speed increases, and when the node reaches its maximum speed, Vmax, it becomes zero, resulting in low experience. Thus, mf ranges between 0 and 1, (0 ≤ mf ≤ 1). i.e.
where Vcurrent is the current speed of the node. In other words, as speed increases, the experience decreases. This means that if the node is steady, the experience will be good; if the node is moving or at a fast speed, the experience will be impacted proportionally. The mobility factor mf is stated in Equation (5).
(5)
where,
Vmax = Maximum allowed speed of node.
Vmin = Minimum speed of node.
It is also possible to set correction factors based on access networks; for example, if connectivity is Ethernet, the node is static and is 1. Similarly, as shown in Table 2, values can be assigned to various access networks. These values can be adjusted considering application use cases. The ubiquity attribute can be calculated using Equation (6).
(6)
3.2.5. Computation of EX Score
From Equation (1),
. This function works on the weighted average of HI, RL, TR, UB. In general, the formula for weighted
average is: Weighted Average =
Where x is distribution and w is
weight. The
of A with B is then computed using Equation (7).
(7)
4. Proposed EX-BAC Model
From existing literature, it is observed that there is a clear logical grouping of the different assets involved in ubiquitous systems. Based on this grouping, systems
![]()
Table 2. Ubiquity correction factors.
can be categorized as device, network, and cloud. Each logical group in UbiComp have their own needs and security challenges compared to existing internet security challenges. UbiComp devices have unique issues that are distinct from those faced by traditional Internet clients. The diverse form factors, power requirements, and hardware characteristics of devices all provide challenges. UbiComp devices may use little power, lower bandwidth networks than current Internet systems. Often UbiComp devices connect through wireless or cellular technologies. Wireless and cellular networks have much higher latency and more disconnections than fixed networks. The protocols that are used for the world wide web are relatively high data-intensive and power-savvy for resource constraint devices. Security approaches such as encryption and certificates are problematic and, in some cases, unfeasible in tiny devices.
The proposed access control framework is logically divided into three layers of service architecture (See Figure 2).
· Discovery and classification service
· Control and enforcement service
· Data service
4.1. Computation of EX Score
This service acts as first-level security in our access control framework. This service encompasses modules like node classification, node trust establishment, request handler, response handler, and experience evaluator.
![]()
Figure 2. Proposed access control model.
4.1.1. Node Classification
When any node A wants to access the resource of other service node B, it establishes a network connection with the service node. Once the connection is established, node B gets authenticated by the standard authentication process. The authentication process is not discussed as it is assumed that it’s already defined in the network during design time. Once the node is authenticated, the node will be classified based on different criteria. In previous work [4], devices were classified as CONSTRAINT, SEMIPOWERFUL, and POWERFUL based on network parameters like RSSI, Energy, Throughput, and medium. These node types are logical labels and can easily incorporate into the policy framework as one of the context parameters. Other context parameters will be extracted by this module such a device ubiquity,i.e., whether the device is mobile or static as discussed in the previous section.
4.1.2. Node Trust Establishment
This module established primary Trust between A and B. It checks whether the requester is supported by the system or not. This module takes attributes from the classification module and if the node is valid then the request is passed to the request handler. If basic Trust is not formed, i.e. the device is not passed the basic requirement of the system, the access request is rejected from this point.
4.1.3. Request Handler
We consider, the larger scale of devices are present in the network and try to access various resources of each other. As resources are finite and can be accessed by limited requesters at a time. The request handler module checks the availability of resources at request time and if the resource is available for access, then only forwards requests for further evaluation. Request queuing and resource management is assumed to be the core functionalities that any request handler would essentially have, hence detailing out of such functionalities has not been included in this paper.
4.2. Access Control and Policy Enforcement Service
4.2.1. Access Control Module
For access control, the proposed model is leveraging the ABAC framework [26] as the base for the access control module (Refer Figure 3). In ABAC access control policies are formed using attributes groups such as subject, object i.e., resource, action, and context attributes. Access to resources is given based on these policies, and new policies can be added dynamically whenever required. The scalability, fine-grained policy, and flexibility provide more secure access to resources than traditional access methods.
Request from request handler will be forwarded to Policy Enforcement Point (PEP). PIP converts the corresponding request in policy format and sends it to the policy decision point (PDP) for further evaluation. PDP acts as the central processing unit for policies. PDP evaluates incoming requests against stored policies and returns decisions either allow or deny. During policy evaluation,
PDP initiates a request to Policy Information Point (PIP) to retrieve context information like Experience coefficient, device type, etc. Policy Administration Point manages creation (PAP), update, and deletion of policies evaluated by PDP. PAP uses a Policy database managed by a data service to store all policies. PAP is part of the Policy Re-Enforcement Engine.
4.2.2. Experience Evaluation
When PDP requests PIP for context attributes for given Access Control Object, PIP communicates with the experience evaluation module to calculate the experience of the subject. Experience will be calculated as mentioned in the experience model and sent back to PIP. Experience evaluation module access data service to get historical device data as well as communicates with peer nodes if required for transitive experience.
4.2.3. Policy Re-Enforcement
When PDP evaluates policy and creates a response, it sends a response via a policy enforcement engine.
4.3. Data Service
Data service provides interfaces for accessing historical data regarding interactions as well as acts as a storage provider for storing policies created by policy administration points. Storage media and data handing is a node-specific task hencedetails are not considered.
5. Implementation of EX-BAC
5.1. Access Control Elements
In Ex-BAC, the below elements are involved while creating a resource or service request. JSON-based policy language is used to store and communicate different policies which are based on XACML standards.
· Subject: A subject is something that requests access to resources or services. A subject can be anything either user or application or any device in the environment.
· Resource: The object or service which is requested by the subject. These resources are governed by various policies.
· Action: An action that can be performed on the subject when policy executes
· Context: Set of parameters that handle the dynamic aspect of the access control situation.
In Ex-BAC, defined policies contain any condition on one or more attributes of the above for elements. For example, for the subject, the condition can be defined as providing access to a resource only if a node is “Node A” or node name starts with “NODE” or “.*” means any node. If these conditions are met, the PDP will produce an access decision based on an evaluation process.
5.2. Experimental Setup
All experiments are conducted on the system Intel i5@3.4 GHz with 8 GB of memory. The Proposed model is implemented using python with the help of various packages like pandas, py-abac, bottle, pymongo, json, scikit-learn. Various device configurations considered for experimentation are listed in Table 3. Constraint: Only rssi, energy values are considered for determining device type. Experiment simulation is carried out with controlled values as well as random values for various parameters like speed, signal, and movement of the subject towards the resource. Also, for battery-operated devices, simulation is carried out for battery charge and discharge. The Experiment used devices like PC with direct power and with both communication mediumsi.e., Ethernet and WIFI. Elements Involved in Ex-BAC Evaluation.
5.2.1. Subjects
In the experiment, three types of devices like pc, laptops, and mobiles are used. These devices are running either with an uninterrupted power supply or with
*: For rssi values refer to Table 7, +: Resource owner for experiment.
batteries. Compared to PC, devices like laptops that are running on batteries and communicating using WIFI are considered semi-powerful devices, while mobiles with cellular connectivity and low battery are considered as constrained devices. Both cellular and WIFI-connected devices are affected by environmental changes like changes in signal strengths and speed of the device itself, while devices which are connected to Ethernet are static and show strong connectivity. Power supply to fixed devices is uninterrupted while devices running on batteries have constraints that limit their usage of resources.
5.2.2. Resources
Three types of resources considered for experimentation are listed in Table 4. Video resources are always heavy resources when accessed consume heavy bandwidth and energy. On the other hand, audio resources are less power and bandwidth savvy compared to video resources. Text resources show the lowest consumption of bandwidth as well as energy.
Table 5 shows two context attributes, device type and experience. Device type context is derived using contribution two and experience is derived using contribution three. Polices are based on values of these context values. As shown in Table 5, to access resource Video.mp4, which is a video resource, device type must be POWERFUL, and the minimum experience score required is 0.4, while for the same resource if the device is SEMI_POWERFUL, the experience score required is 0.6.
![]()
Table 5. Context attributes and experience values to resource access.
5.2.3. Access Network Connectivity
Devices can used access networks technologies for connection such as Ethernet, WIFI, and Cellular as listed in Table 6.
Some devices can use multiple connections based on their locations. For example, PC and Laptops either can be connected to Ethernet or WIFI and they choose a medium based on availability. Similarly, laptops and mobiles may use WIFI when available and mobiles can connect to a cellular network when on move.
Table 7 shows a mapping of actual RSSI signals values normalized in the range between 0 - 45 [27].
5.3. Default Policies in the Experimental Setup
The considered policy attributes and their respective values are given in Table 8.
5.3.1. Sample Policy Format in JSON
The following snapshot shows how a single policy can be created using simple JSON.
![]()
Table 6. Access networks for device connectivity.
5.3.2. Access Request for PDP
PEP creates an object that represents an access request. This object provides all of the data necessary for the PDP to evaluate policies and make access choices. Sample policy can be visualized in JSON format as shown below.
6. Results
After the implementation of the EX-BAC model, we executed three distinct experimental scenarios for performance analysis.
6.1. Scenario 1
In scenario one, Node 2 requests a video file to Node 1. Node 2 is a static node and connectivity is ethernet, clustering algorithm maps this node to the “POWERFUL” cluster and hence logical device type of Node 2 is labeled as “POWERFUL”. There is no previous interaction history between Node 2 to
![]()
Table 8. Policy attributes and values to access resources.
Node 1. In scenario1 weight for the UB, the factor is 0.4 hence it is directly reflected in EX. Experiment results show, how experience grows when interaction grows. Results of scenario 1 are plotted in a graph as shown in Figure 4.
The graph in Figure 4 visually validates our mathematical model presented in Equation (7). For this scenario to calculate RL, W = 20, i.e., Maximum 20 number of previous interactions taken into account for calculating reputation.
Figure 5 shows how HI and RL contribute to experience calculation. With positive HI and RL scores, experience grows logarithmically. After the interaction count passes the W window, the experience moves proportionally with history and reliability.
Figure 6 shows a snap of the first 24 interactions of the scenario. With positive interactions, reliability increases logarithmically. After 20 successful interactions, RL reaches 1, which indicates node 2 is fully reliable.
The graph also indicates, positive experience builds with the increase in HI, RL factors. In scenario 1, the device is stationary hence Ubiquity factor (UB) is always maximum i.e., 1. For first interaction contexts for access control module are DeviceType = “POWERFUL” and EX = 0.56. When PIP sends a request with these contexts to PDP for evaluation, policy results in “GRANTED” as it has “allow” permission for the requested resource.
![]()
Figure 4. Number of interactions vs. experience.
6.2. Scenario 2
In scenario two, Node 4 requests a video file to Node 1. Node 4 is a semi-mobile node and connected to a WIFI network, clustering algorithm maps this node to the “SEMI_POWERFUL” cluster and hence logical device type of device is labeled as “SEMI_POWERFUL”. There is no previous history between node 4 to node 1. In this scenario, UB and RL directly affected the EX.
Figure 7 shows the first 122 interactions of the scenario. For the first 17 interactions, Node 4 falls in the “SEMI_POWERFUL” cluster, and experience ranges between 0.5 to 0.46, hence, according to the policy matrix resource request is “denied”. On the 18th interaction, the Node 4 moved from SEMI_POWERFUL to POWERFUL cluster with an experience score of 0.46. For this interaction, PDP returns’ allowed’ response, hence resource is granted to Node 4. On 40th
![]()
Figure 6. Effect of HI and RL on EX detailing initial 24 interactions.
![]()
Figure 7. Scenario 2: Semi-mobile node with WIFI connectivity.
interaction, the speed of Node4crosses 80 which is the maximum allowed speed. Even though Node 4 was POWERFUL, the experience score lowered below 0.4, and thus PDP “denied” the request. On 62nd interaction, device signal drops below −110 dBm i.e., 10, Node 4 get labeled as “CONSTRAINED” and policies for constrained devices with low experiences are applied by PAP. When Node 4 returned back to the POWERFUL cluster in interaction 121 with an experience value of 0.5, the resource is “granted”.
6.3. Scenario 3
In scenario three, Node 5 requests a text file to Node 1. Node 5 is a mobile node and connected to a cellular network, clustering algorithm maps this node to the “POWERFUL” cluster because of good signal strength and energy. Hence, the logical device type of Node 5 is “POWERFUL”. There are no previous interactions between Node 5 and Node 1. For this scenario weight of the Ubiquity attribute is adjusted to 0.4 which directly affects experience calculation.
Figure 8 shows the results of scenario 3, i.e., the status of resource requests and the impact of environmental attributes like mobility, a communication network. Based on the values of HI and RL, PDP grants access to the resource. With the increase in device mobility and speed, experience decreases due to the UB which carries high weight in experience calculation. On the 25th interaction when Node 5 crosses max speed, the UB attribute becomes 0 and PDP denies request for the resource. Thus, it can be concluded that, reliability and mobility factors in experience calculation will play a crucial role due to a large number of mobile devices in UbiComp systems.
![]()
Figure 8. Scenario 3: mobile node with cellular connectivity.
7. Discussion and Analysis
In this section performance analysis of the EX-BAC model is discussed in three different ways as follows.
· Access request processing time: Effect on access request processing time when the number of policies are increased for different storage types.
· Policy decision-making time: EX-BAC model is compared with T-ABAC in policy selection.
· Experience calculation time: Total time required to calculate experience value with an increase in a number of history records.
7.1. Access Request Processing Time
To check the performance of the access control algorithm, the experiment checked performance with several policies created in data storage. The experiment was evaluated with two persistent storage and one in-memory storage. For the persistent storage, we selected MongoDB and the File system of the node.
Figure 9 shows comparison results for evaluation criteria. The evaluation results show that:
1) With the increase in policies, the time required to evaluate policy increases with persistent storage. Compared to the file system, MongoDB took considerably extra time when the number of policies crossed 1000. With the initial 20 policies, evaluation time for PAP was 24 ms which increased to 119 ms for 100
![]()
Figure 9. EX-BAC time evaluation for policy storage.
policies and reached 900 ms for 2000 policies. For file system-based storage, the trend shows a similar pattern but the time required after 1000 policies is lower than that of the MongoDB database. Both systems have their pros and cons, the file system is faster but the implementation and retrieval of data are complex.
2) The experiment observed much higher performance with in-memory storage compared to persistent storage. Policy evaluation time with 20 policies to 2000 policies ranged between 4 to 5ms which shows policy evaluation algorithm is faster but performance depends on storage used to store policies. There is the scope of using in-memory databases like Redis which might give the mixed performance of in-memory and persistence storage.
7.2. Policy Decision Making Time
To demonstrate the validity of EX-BAC, the experiment results are compared to those of T-ABAC [21]. The main reason to choose T-ABAC to compare with EX-BAC is that both based on ABAC and experience also counts direct trust as one of the attributes.
Figure 10 shows the comparison for the relation between the number of policies and average decision-making time for EX-BAC and T-ABAC.
Both EX-BAC and T-ABAC show similar performance when policies are limited. Both show comparative performance till 200 polices. But EX-BAC outperforms T-ABAC when policy database size increases. For 500 policies EX-BAC
![]()
Figure 10. Performance evaluation EX-BAC vs. T-ABAC.
![]()
Figure 11. Time evaluation of EX-BAC for intercation count.
shows 50% more efficiency compared to T-ABAC. Though T-ABAC uses trust in the model but lacks reliability and ubiquity factor, which is proved very critical in ubiquitous scenarios by our work in this paper.
7.3. Experience Calculation Time
One of the major attributes in experience calculation is HI, i.e., History of interaction. The results show that the time for the request evaluation is largely impacted by the number of interactions (See Figure 11).
Response time for requests change from 26 ms to 42 ms, when the number of interactions increased from 10 to 5000 for 20 policies. It is obvious that during the lifespan of the device there will millions of interactions can happen, hence there is scope for optimization for historical data storage. This optimization can be achieved by maintaining cumulative values of positive and negative interactions.
8. Conclusions
The proposed EX-BAC model shows how history, reliability, transitivity and ubiquity contribute to experience in UbiComp. This model shows device speed is inversely proportional to Ubiquity. From the results, it is observed that EX-BAC is flexible to accommodate different contexts. It is scalable also as policies can be added and removed whenever required. Model is also time efficient as compared to T-ABAC.
In the future, it will be interesting to tokenize experience using blockchain and make it available universally because blockchain has created a new business network that combines ease of use with low costs and excellent security. We can see numerous possibilities to use the EX-BAC model in blockchain and distributed IoT.