Trust‐aware task load balancing in multi‐access edge computing based on blockchain and a zero trust security capability framework

The need for low‐latency service support at the network edge has increased due to new applications such as autonomous vehicles, facial recognition, and augmented reality. Multi‐access edge computing (MEC) has emerged as a promising component of next‐generation 5G and 6G networks that provides additional storage and computing capacity at the network edge to enhance application performance, load balancing, and reduce latency. Security challenges remain, and a zero trust security framework has the potential to reduce risk and improve visibility. A zero trust management module is introduced to authenticate users after a successful registration. This article presents a three‐layer MEC model implementing a trust‐aware load balancing decision process. A Q‐learning algorithm is used to estimate trust values. Task trust and indirect trust relationships are recorded using blockchain technology. Blockchain will enable a transparent and secure mechanism that contributes to secure resource management in an MEC environment. The results provided by a framework simulation highlight the improved security outcome.

3][14][15][16] MEC server deployments currently rely upon security solutions developed for the cloud that may not be appropriate at the network edge.The attack surface at the network edge is growing, and MEC server intrusion points add to existing security challenges. 5,12lockchain technology has unique characteristics that can improve security efficacy in MEC networks. 17Blockchain enables registering and updating transactions securely in a decentralized fashion without relying on a central authority. 18,19Blockchain technology enhances MEC security by providing trust, integrity, secure identity management, data privacy, secure transactions, and distributed threat intelligence, thereby mitigating various security risks and vulnerabilities associated with MEC deployments. 20he rest of the article is organized as follows.Section 2 introduces ZTS model for MEC.Section 3 provides a practical realization of the proposed framework and demonstrates its performance.Section 4 illustrates future work and provides the conclusion.

Contribution
This work contributes to a proposed framework that utilizes blockchain and Q-learning to carry out MEC secure load balancing and introduces a zero trust management module (ZTMM) for effective authentication.The proposed framework leverages an edge authenticator (EA) to optimize and secure tasks distributed among MEC servers.The proposed framework was tested using the OMNeT++ network simulator, and the results and analysis are provided.The main contributions of this article are summarized as follows.
• A trust-aware load balancing system is proposed that utilizes blockchain to validate the trustworthiness of tasks and MEC servers.An EA was developed that allows a trusted communication channel to the blockchain journal and is responsible for estimating the server trust values, making load balancing decisions and monitoring the load balancing requests and transactions.The load balancing selection process is determined based on the trustworthiness of the servers and server capability (i.e., queue capacity) to process the task using the Q-learning algorithm.
• A decision execution method that defines trust values for MEC servers and continuously assesses the trust values using a security policy engine with a Q-learning algorithm was developed.We validated the trust value integrity, a composite of task and indirect trust and stored the results in the blockchain.
• A new component called ZTMM is introduced at the MEC host level.It validates the UE identity before tasks are allocated and processed.The ZTMM is aligned with the zero trust architecture requirements for a multi-layer cybersecurity approach, including defence-in-depth controls. 6The process outcome is to grant trust-aware load balancing from overloaded to underloaded servers.
• Selected proof-of-concept (PoC) experiments in a MEC environment were carried out to validate the proposed solution.Scenarios were created that included UE requests with diverse requirements in a high-mobility environment.The proposed solution aims to maximize task load balancing with improved security that is provided using a zero trust approach.

Related work and research gaps
In this section, we focus on the primary research works relevant to the article.Numerous trust architectures, frameworks, and models have been suggested to create effective trust strategies and task offloading in the MEC network.However, existing approaches that integrate zero trust principles and MEC, as described in Table 1, generally do not consider the use of blockchain and various degrees of trust levels.
In Reference 11, the MEC load balancing process was addressed using a reinforcement learning algorithm to reduce offload cost.A binary variable represented the offload decision, whether in the local or offload server.The Q-learning method was used for offload decision-making.The criteria used in this work were the sum cost and capacity of the MEC server.This method considers two metrics for decision-making, while the trust of the MEC server was not predicted.If the MEC server is untrusted, the capacity may be invalid.In Reference 21, a two-tier zero trust architecture was introduced to improve access control security for MEC applications.User behavior is continuously monitored in the 5G core T A B L E 1 Proposal compared to the literature.

Reference
No.

Reinforcement
It is evaluated based on the policy decision engine.Multi-attribute entropy is computed to assess a user's trust score.In Reference 12, a zero trust model was developed to enforce identity verification and location-based authentication to ensure seamless service continuity across edge servers.The model used a lightweight PRESENT algorithm with an 80-bit key size and 64-bit block size and processed 32 cycles per block.In Reference 22, an authentication-based approach, a software-defined virtual perimeter framework, has been proposed to provide secure communications within mobile core networks based on two machine learning classifiers (multilayer perceptron and support vector machine [SVM]).System components are virtualized and placed within a core network to provide a zero-trust environment where only authenticated and authorized core network elements can access each other.In Reference 23, a centralized training and decentralized execution (CTDE) mechanism as a reinforcement balancing strategy was presented in the MEC environment.A decentralized multi-agent reinforcement learning-based balancing model was proposed to coordinate the trust relationships and update the sampling process.The actor-critic network handled the learning process.The CTDE mechanism was responsible for determining the Q-value.Due to centralized management, CTDE mechanisms were subjected to collision (two or more servers balancing the same task).In Reference 24, a SVM algorithm was proposed to minimize the computing power by predicting the hyperplane utilization and minimizing the decision-making process.The prediction was conducted using the radial basis function.The weighted values in the SVM were computed using energy consumption and computational latency.This model utilizes deep learning to classify data based on the traffic type.The "smart contracts" blockchain method allowed specific MEC service providers to participate in a pre-identified permissible MEC network.This can filter out untrustworthy MEC service providers but not individual servers within the permitted MEC network.In Reference 17, three trust computations were involved: entity trust, data trust, and privacy trust.Each trust has a set of attributes in it.The trust blogger was selected, and the transaction was validated using the signature and the trust values.The hashing of device credentials uses the SHA-256 algorithm.SHA-256 requires extensive computations, leading to increased time in the blockchain; hence unsuitable for edge applications.In Reference 25 proposed an authentication mechanism by implementing a blockchain at the network edge using asymmetric cryptography.Elliptic curve cryptography is performed to encrypt data.SHA-256 hashing is used to secure the records in the blockchain.A device registers and receives a digital signature, which is implemented to verify the user's identity.The traditional SHA-256 hashing algorithm consumes significant computing/processing power and imposes a prominent delay response, especially for many simultaneous requests.As a result, it added complexity to the trust hashes validation.A trust evaluation process and authentication mechanism are required for load balancing that minimizes delay and optimizes task processing.The load balancing process challenges are: • To register and authenticate UE.
• To ensure that trust is established and maintained.
• To monitor MEC servers' trust value.
• To manage task priority.

ZERO TRUST SECURITY MODEL FOR MEC
This section describes the ZTS model for MEC architecture in MEC.The design of our proposed architecture can be seen in Figure 2.

Implementation of ZTMM for MEC
The proposed ZTMM at the MEC host level validates the UE identity using credentials, a process called authentication 9 as depicted in Figure 1.The ZTMM comprises policy decision point (PDP) and policy enforcement point (PEP).
The PDP is split into two logical components: the policy administrator and the policy engine.The policy engine is a decision-maker to allow/deny access to MEC resources.It will use the continuous diagnostics system as input to a trust algorithm to make a decision.The policy administrator executes that decision by signaling PEP to shut down or establish the connections between a UE and an MEC resource.The PEP authenticates UE, monitors, and eventually terminates connections.
F I G U R E 1 Zero trust management reference architecture.
F I G U R E 2 Simplified reference architecture.

Simplified reference architecture
The proposed high-level architecture of the blockchain-based trust framework for MEC builds upon the MEC reference model defined by the ETSI in Reference 26.The logical architecture comprises three protect surfaces: UE, edge and cloud, as illustrated in Figure 2.
• UE protect surface: The UE commonly incorporates mobile or wireless technologies and connects with the nearest access point, "eNodeB," to create a distinct identity during registration.Once registered, the UE can collect or interact with data from the edge.
• Edge protect surface: The edge layer has two primary sublayers: the application and the infrastructure.The IT infrastructure incorporates connectivity, computing, and storage in distributed hyper-converged systems.The edge layer securely connects and manages all edge devices, including the blockchain network.Any server, cluster, or gateway that hosts application workloads and shared services at the network edge is called an edge server.The edge node comprises multiple edge servers.
• Cloud protect surface: The cloud layer, whether public, private, or hybrid, provides computing and storage capabilities for applications and services that run on-premises.

UE registration and authentication
UE registration and authentication in MEC refers to the process by which a user's device establishes its identity and gains access to the MEC environment.This process ensures that only authorized devices can utilize the MEC platform's services and resources.The UEs are employed dynamically; they have different mobility profiles. 1Let U be the UE, and n be the total number of UEs.
and each U has a unique identity ID and fingerprint biometric characteristics B.
B is an individual's physical traits used to identify or verify a person's identity.It can grant access to MEC services and authenticate the identity of users and devices in the MEC network.
At first, every UE registers with these two security credentials.The B in binary values extracts two 4-bit binary in random and performs the XOR Boolean operator.After registration of U n , they are authenticated each time while submitting requests.The UE authentication takes place in ZTMM based on the following logical sequence and as illustrated in Figure 3.  fingerprint biometric. 27.The ZTMM verifies the UE's identity and credentials.After successful registration, the ZTMM assigns a unique UE identifier UEID to the registered UE.Now, UE must authenticate to establish its authenticity.4. The ZTMM verifies the UE with ID 1 (C 0 ) and timestamp t (2) .Then it provides the corresponding UEID 1 (R 0 ) for the UEID 1 (C 0 ) request to the ZTMM.Here C 0 is the challenge in the authentication process and R 0 is the corresponding response of it.5.The ZTMM receives (C 0 , R 0 ) from device D 1 and verifies t (3) , if valid it then verifies (C 0 , R 0 ).After verification completion, the D 1 is successfully authenticated and marked as a legitimate UE. 6. UE can now access authorized MEC services and resources based on granted access rights.
According to the above steps, only legitimate UE with successful authentication is granted access.Suppose cybersecurity attacks hit eNodeB.In that case, the compromised eNodeB will process the authentication requests ordinarily and allow a threat actor's lateral movement within the network, which acts against the proposed prototype.
UE registration and authentication in MEC are crucial for establishing a trusted and secure environment.By verifying the identity of UEs and granting access based on authentication mechanisms, ZTMM can ensure that only legitimate devices can interact with the MEC infrastructure and utilize its resources effectively.

Blockchain and edge authenticator
The blockchain stores the states and performs hashing techniques using the SHA-256 algorithm in each block. 25In our work, the states define trust values (task and indirect trust).As illustrated in Figure 4, the blockchain structure encompasses sequential blocks.The EA within the edge layer represents a trusted communication channel to the blockchain and is responsible for estimating the server trust values, making balancing decisions and monitoring the balancing requests and transactions.Figure 4 presents the blockchain transaction structure and its trust values.

Q-learning
The Q-learning performs load balancing decisions in the MEC environment.It is a reinforcement learning algorithm that operates with an initially constructed Q-table composed of states and actions.The states are considered input, and the Q-function selects the predefined action from the Q-table to process the load balancing decision.The Q-function then estimates the benefit of the executed action and performs load balancing.The Q-function updates the action and states attributes in the Q-table, eventually taking the corresponding action according to estimated trust values.This approach allows efficient decision-making based on learned experiences and adapts to changing network conditions.The Q-learning algorithm has a learning capability that receives a trust value and information about server load states. 28,29The primary purpose of the Q-learning algorithm is to validate the trust value of the overloaded server.The indirect trust (IT) is the sum of successfully processed offload tasks and the credit score (C) the neighboring servers give.
The C is calculated based on various factors, such as the server's reputation, the quality of service provided in the past, and the level of risk associated with offloading tasks to the server.In our work, the C rating of a neighboring server is calculated primarily based on the number of successfully processed overloaded tasks.A higher C indicates a greater level of trustworthiness, while a lower C indicates a higher level of risk.
The IT is illustrated in Equation (1).
where S i is the number of offload tasks received by an MEC server and processed successfully, i denotes the number of tasks, and C is the credit score.The task trust (TT) is the number of tasks processed (including delay constraint).Each task's delay constraint depends on the application's delay tolerance.For instance, a task request for a video call has low delay tolerance, while for a file transfer, the delay tolerance is comparatively high.Let TC be the task count, max delay be the maximum delay tolerance, and task delay represents the individual task's delay.The TT function is defined in Equation (2).
TT ⇒ (TC(max delay) ≥ TC(task delay). ( The server with a lower load is selected to receive an offloaded task.This work uses blockchain to ensure that the trust values are not altered.Managing the server trust values in the blockchain provides efficient and secure selection.The trust value is not recomputed every iteration but is calculated when a server overloads.After this trust computation, the load balancing decision proceeds.In this work, the action will be to decide whether the server can offload the task to the underloaded server.A Q-function decides whether to offload a trusted task to an underloaded server. A Q-function was designed and constructed as a table with a set of N states and actions that are represented as Q(s N ,a N ).The states are found from the trust values, and the corresponding action is whether to select an offload server or not.A Q-learning can process multiple states and produce more than one action for the corresponding states.The Q-learning operates with the initially constructed Q-table composed of states and action.The states are considered input.The Q-function selects the predefined action from the Q-table to process the load balancing decision.Then it estimates the benefit of the executed action and performs the load balancing.The Q-function will update the action and states attributes in the Q-table.Eventually, the Q-function will take the corresponding action according to estimated trust values.
The queue capacity is the maximum number of tasks an MEC server can process with no performance impact and is pre-defined.In our work, the queue capacity limit is ten tasks.A server with insufficient queue capacity to handle the queued tasks is considered an overloaded server.In contrast, the underloaded server has available queue capacity.The queue capacity of servers is updated based on a specified time interval after the task arrival and the processed task count.In the case of task overload, the server sends a request to the EA to make a task offload decision.MEC servers update the task load in a particular time interval and predict the coming task load based on its queue capacity.The server checks its queue capacity for a specified time interval.Once overloaded, the identified server submits a request to the EA for a trusted server for load balancing.The EA utilizes the blockchain for trust validation.The trust value is determined by task and indirect trust computation. 30The workflow of the Q-learning is demonstrated in Figure 5.
Let s t be the initial state, and s t+1 be the next state, as the state changes occasionally.The Q-learning is illustrated in Equation (3).where R denotes the benefit, the benefit is a credit added for a particular action executed successfully.The  indicates the discount factor, the  is the learning rate, and a is the greedy policy. 29The pseudo-code for the Q-learning is illustrated in Algorithm 1.
The message flow for trust-aware load balancing with service continuity can be illustrated as follows: • Accurate timing prediction to initiate a trust-aware load balancing process.
• The EA checks the overloaded server queue capacity.
• The overloaded server requests EA to offload tasks and submits its trust parameters, that is, S i , C, TC and task delay.
• The EA will extract the trust parameters, apply the Q-function, and estimate the trust.
• The blockchain will validate the request against its stored trust values repository for the overloaded server and reply with an action.If the action is determined to proceed.Then, • The EA decides to grant the trust-aware load balancing to the underloaded server.
• Depending on the application scope, the overloaded server offloads the queued tasks to release its queue capacity and resources.
Figure 6 shows the detailed message flow of the proposed framework.

TRUST-AWARE AUTHENTICATION AND TASK LOAD BALANCING IN MEC
This section uses the OMNeT++ simulator to provide a working implementation of the proposed framework.

Simulation model
The proposed MEC model was developed in a popular research-based network simulator, that is, SUMO, 31 Veins, 32 and OMNeT++. 33The simulation consists of UEs, MEC and a cloud layer.Network switches are deployed as edge devices to integrate ZTS models.The OMNeT++ standard package provides the network connectivity used in the simulation.The wireless connectivity that has been implemented relies on LTE technology.The main simulation parameters are summarized in Table 2.
In our scenario, the UEs are mobile devices.The ZTMM is used to authenticate connected UEs and permit authenticated UEs to access MEC applications and services.There are consistent message flows between the eNodeB and UEs.We have discussed the details in our previous work. 34Our PoC experiments aim to evaluate the practicality and promise of our proposal in upholding the ZTS guiding principles for offloading tasks between trusted and reliable MEC servers.We present the EA role to deploy a Q-learning algorithm for the trust-aware load balancing decision process and select an available underloaded server for task fulfilment.The simulated architecture is independent of the underlying connectivity and can be implemented in 5G or 6G networks.
The tasks from the overloaded server are offloaded to an underloaded server based on the estimated trust value.The EA estimates this trust value and executes a Q-learning to select the receiving server.The queue capacity is the maximum number of tasks a server can process with a minimal performance impact.A server with insufficient queue capacity to handle the queued tasks is considered an overloaded server.The server queue capacity is updated based on a specified time interval after the task arrival and the processed task count.In case of task overload, the server requests the EA to make a task offload decision.

Computation model
We consider that each UE has computational tasks with strict latency requirements.Therefore, the user needs access to a specific service from the MEC server to meet its stringent performance requirements via computational offloading.The computational model can be defined in three steps following the models introduced in related works. 9,25,34First the UE requests access by uploading a specific size of data that needs to be processed by the MEC server through the radio access network.The radio access network forwards the request for registration and authentication to ZTMM.The proposed approach registers the UE and authenticates it using PRESENT protocol. 34Finally, the processed results from the MEC server are returned to the UE.Accordingly, the computational model could be defined by the processing delay of all these steps.

MEC processing delay
When the UE u requests a specific service s from the MEC server m, the communication delay is dependent upon the achieved data rate, the wireless channel conditions, and the size of the requested service.The channel gain between the UE u and MEC server m at time t is represented by g t um , and the signal-to-noise ratio can be defined as:

Q-learning
Learning rate () .5 Discount factor () .5 Data size per task 500 MB

Maximum occurrence 300
The greedy factor range .4-.9 where p m represents the MEC server transmit power,  2 represents the noise power, and the I ′ M represents the accumulated interference from neighboring MEC servers.The achieved data rate can be defined as: where b m is the bandwidth allocated by the MEC server m.The communication delay between the MEC server m and the UE u requesting a specific service at time t can be defined as: where s u represents the size of the service requested by the UE u.The downloading delay of the processed service requests also depends upon the size of the processed results and the download data rate of the UE u.The success rate is defined as the successful completion of tasks by the servers during the execution of the load balancing process.It could be defined as the ratio of the number of tasks accepted by the MEC server to the total number of requests received by the MEC server: where SR m represents the success acceptance rate of the MEC server m, N m represents the number of tasks accepted by the MEC server m, and N total m represents the total number of tasks received by the MEC server m.The failure rate presents the rate of failed UE requests and can be defined as: where FR m represents the failure rate of the MEC server m, F m represents the number of unsuccessful tasks by the MEC server m.

Authentication time
Calculating the authentication time involves considering the time the UE takes to initiate the authentication process, the time taken for the ZTMM to process the request, and the time taken for the UE to receive the authentication response.
Here is a step-by-step approach for calculating authentication time 12,36 : • Start time measurement.Begin measuring the authentication time when the UE initiates the authentication request.
• Request transmission time.Measure the time it takes for the UE to transmit the authentication request to the ZTMM.It includes network latency and transmission delays.
• Request processing time.Measure the time the ZTMM takes to process and validate the authentication request.It includes necessary checks, that is, verifying UEID and performing authentication algorithms.
• Authentication response transmission time.Measure the time it takes for the ZTMM to generate the authentication response and transmit it back to the UE.
• End time measurement.Stop the authentication time measurement when the UE receives the authentication response.
• Total authentication time.Calculate the total authentication time by subtracting the start time from the end time.
The authentication time has minor variations since the EA extracts the credentials and completes the verification process.However, a lightweight PRESENT algorithm has been used, and this should reduce the cipher conversion time.A generalized relationship occurs between the number of UEs (authentication requests) and authentication time.Additionally, network conditions and system load can influence the overall authentication time.However, this is not a formal linkage, as the computing and storage resources are shared with other tasks and processes.

Experimental evaluation
The simulation results were evaluated for success rate, failure rate, load balancing delay, and authentication time.
The time interval defines the fixed time interval for UEs to submit requests to the servers to perform a task; in this simulation, it is 5 s.

Success rate
Each UE can submit only one task at a time.After task completion, UE can submit the subsequent task request.The selection of a trustworthy underloaded server using a Q-learning reflects the improvement in the success rate.The success rate performance measured is depicted in Figure 7A.Blocking unauthorized access requests presents an improved success rate since the submission of forged and compromised identities is reduced.The improvement in success rate can be further increased by deploying a lightweight authentication algorithm.

Failure rate
The failure rate represents the server's unsuccessful tasks.If the server's queue capacity is full, the tasks fail and the failure rate increases.The failure rate performance is depicted in Figure 7B where UEs increase in the network; a Q-learning is applied to process received tasks.The proposed model will consider only the verified UE identity for processing.All received requests, including illegitimate, or malicious requests, are processed in the SHA-265 blockchain model.For instance, if a flooding attack is launched, massive UE requests will be submitted for processing, so it takes longer for the SHA-265 blockchain model to authenticate legitimate UE requests.Our model achieves a reduced failure rate from the results than the SHA-265 blockchain model.The failure rate of our model is about 28%.On the other hand, it is around 65% for the SHA-265 blockchain model.The difference in failure rate is circa 37%, indicating that the compromised UE can access the edge servers and potentially breach data privacy.This method attains efficient load balancing results that decrease the failure rate.The average success rate achieved is 87%, and the average failure rate is 28%.The practical measures in the increase in success rate and decrease in failure rate are because a trustworthy server is selected to fulfil the requests with accurate information about the workload and trust value.

3.3.3
Load balancing delay Load balancing delay is the time tasks take to move from an overloaded to an underloaded server.It should be minimized while ensuring that the trust and security requirements of the application are met.The acceptable load balancing delay will depend on factors such as the sensitivity of the data being processed, the criticality of the application, and the expected response time.Our proposed model demonstrates optimized delay in load balancing as depicted in Figure 7C.The load balancing delay may increase when the task size (bytes) and the number of tasks change.The proposed framework was found to have an average load balancing delay of 7.8 ms.The simulation result in Figure 7C shows a gradual change related to an increasing task size.The reasons for efficient load balancing delay are: • Underloaded servers can process offloaded tasks promptly.
• Server load is predicted.The server trust is estimated, permitting successful load balancing.
• The Q-learning can carry out an analysis in parallel for each of the arriving load balancing requests.
• Executing a Q-learning in parallel permits efficient metric calculation.

Authentication time
The authentication time depicted in Figure 7D is the time the EA takes to authenticate the UE task.It was observed that the average authentication time found was 45 ms.Implementing a trust-aware framework demonstrates that the proposed approach is a practical solution to enhance security and mitigate trust-related risks.However, there is scope for additional research on algorithms that can be optimized for MEC environments to improve reliability and security further.

CONCLUSION AND FUTURE DIRECTION
This article presents a layered architecture for MEC networks that utilizes blockchain and an edge authenticator to assess trust for MEC servers.This article also introduces a "UE registration and authentication" mechanism that leverages ZTMM to authenticate UE after a successful registration.
The proposed framework will be expanded to include an SDN-based cloud-native model for MEC federation scenarios and a multi-factor authentication framework to strengthen the authentication process and mitigate attacks on MEC servers.Future research explores ways to facilitate multiple identity factors across MEC servers, such as biometric (single or hybrid) and physical unclonable functions.Given the limited resources of MEC servers, efficient authentication algorithms must be developed to ensure smooth service continuity while performing UE authentication and identity verification.

F
I G U R E 3 UE registration and authentication workflow.

1 .
When a UE wants to connect to the MEC environment, it initiates the registration process.Let U be a UE submits an authentication request with [ID 1 and T (1) ], where T (1) is the first timestamp created during the request's transmitting.First, the ZTMM checks timestamp is valid or not.If T (1) is valid, then it validates ID 1 .2. The ZTMM requests ID 1 to provide B 1 , where B 1 = (b 11 ⊕ b 22 ) in which b 11 and b 22 are 4-bit binary extracted from

F I G U R E 6
Message flow for trust-aware load balancing.
Simulation parameters.
TA B L E 2