Leveraging Blockchain Technology for Secure 5G Offloading Processes ^†

Abstract

This paper presents a secure 5G offloading mechanism leveraging Blockchain technology and Self-Sovereign Identity (SSI). The advent of 5G has significantly enhanced the capabilities of all sectors, enabling innovative applications and improving security and efficiency. However, challenges such as limited infrastructure, signal interference, and high upgrade costs persist. Offloading processes already address these issues but they require more transparency and security. This paper proposes a Blockchain-based marketplace using Hyperledger Fabric to optimize resource allocation and enhance security. This marketplace facilitates the exchange of services and resources among operators, promoting competition and flexibility. Additionally, the paper introduces an SSI-based authentication system to ensure privacy and security during the offloading process. The architecture and components of the marketplace and authentication system are detailed, along with their data models and operations. Performance evaluations indicate that the proposed solutions do not significantly degrade offloading times, making them suitable for everyday applications. As a result, the integration of Blockchain and SSI technologies enhances the security and efficiency of 5G offloading.

1. Introduction

5G has recently enabled the concept of smart cities to become a reality, facilitating the creation and implementation of innovative applications. Before the advent of 5G, smart cities were already under development, using existing 3G and 4G technologies which, while offering limited speeds and capabilities compared to 5G, already enabled the deployment of basic IoT applications and limited connected services [1]. However, these networks could not match the high speed, data capacity, and low latency offered by 5G. This limits the ability of smart cities to handle large volumes of data generated by IoT devices and advanced applications such as augmented and virtual reality or advanced traffic and energy management, or to provide real-time responses as demanded by critical applications such as autonomous vehicles or public safety systems. In addition, pre-5G networks had limited capacity to connect many devices simultaneously. This was a challenge in smart cities, where millions of IoT devices are expected to be connected and operating efficiently [2,3].

In this context, 5G technology has transformed smart cities by enabling a wide range of innovative applications and services [4,5]. It has already played a crucial role in transforming urban environments, making them more efficient, sustainable, and liveable [6]. First, of all, 5G facilitates the deployment of massive numbers of IoT sensors and devices throughout cities. This dense network of connected devices allows the collection of real-time data on various aspects of city operations, including traffic patterns, air quality, energy usage, waste management, and public safety, resulting in more efficient public services which reduce waiting times and improve overall satisfaction. The ability to gather and analyze this wealth of real-time information provides city planners and managers with unprecedented insights to optimize services and operations. Secondly, 5G IoT enables cities to implement more intelligent and responsive infrastructure systems. Smart traffic management systems can use real-time monitoring and AI-powered traffic light optimization to reduce congestion and travel times. Smart grids benefit from more efficient energy distribution and integration of renewable energy sources. Smart water systems can now detect leaks and optimize water distribution, while smart waste management systems use IoT sensors to monitor waste levels and optimize collection routes. These advanced infrastructure systems improve efficiency, reduce costs, and enhance sustainability in urban areas. Third, the low latency and high bandwidth of 5G enable more effective public safety applications. For example, high-definition video surveillance with AI-powered analytics can enhance threat detection capabilities while real-time communication and coordination between emergency responders could improve response times and effectiveness. In addition, 5G enables the faster deployment of drones and robots for search and rescue operations. These capabilities allow cities to respond more quickly and effectively to emergencies and security threats. Finally, regarding autonomous and connected vehicles, 5G-based vehicular communications improve traffic flow and safety, as well as driving experience based on optimized real-time navigation updates and routes, making commuting more efficient and convenient. These advancements lead to safer roads, reduced congestion, and more efficient urban mobility. In summary, 5G helps cities become smarter in terms of safety, functionality, sustainability, and economy.

However, although 5G technology has begun to revolutionize connectivity in smart cities, its deployment is already facing several challenges, especially in terms of quality coverage [7,8,9].

• Limited infrastructure: The 5G network requires a dense infrastructure of base stations and antennas to provide adequate coverage within cities. However, existing infrastructure today is not enough for the large number of current and future services.
• Signal interference: 5G signals, especially in the higher frequency bands, are more susceptible to interference from physical obstacles such as buildings, trees, and other urban elements in the city, resulting in shadow areas where coverage is poor or non-existent.
• Upgrade costs: Extending an existing 5G network is costly, as it requires the installation of new base stations and antennas, and can be prohibitive for some cities.
• Regulations: Installing a new 5G infrastructure (base stations or antennas) requires obtaining permits and complying with local regulations. This process can be slow and bureaucratic, delaying the expansion of 5G.
• Coverage disparity: In many cities, 5G coverage is unequal, with central and busy areas receiving better coverage than peripheral or less populated ones.
• Environmental impact: The installation of additional base stations may raise concerns about the environmental impact on cities.

In this context, offloading-based solutions have already proven to be useful to improve the coverage and efficiency of 5G networks. Offloading refers to the process of transferring data traffic from a core 5G network to alternative networks, such as those from other operators, or Wi-Fi solutions, to provide more robust and cost-effective connectivity. The main advantages of using offloading techniques in 5G are as follows [10,11]:

• Improved Coverage: In areas where the 5G signal is weak, intermittent, or inexistent, offloading to other networks provides an additional reliable connection.
• Congestion Reduction: By diverting some traffic to alternative networks, the load on the core 5G network is reduced, improving the quality of service.
• Resource Optimization: Offloading allows for better utilization of available resources, as alternative networks can handle the additional traffic without negatively impacting the core network.
• Cost Savings: For network operators, offloading can be a more cost-effective way to manage data, as it avoids the need to invest in additional 5G infrastructure.
• Flexibility and Scalability: Offloading offers a flexible and scalable solution for managing data traffic in dynamic urban environments, adapting to changing network needs.

Although offloading techniques have already been extensively investigated in the literature [12,13], there are still some security risks that need to be addressed in order to have a fully secure offloading process. It is currently difficult to guarantee that only authorized users and devices access alternative networks within an offloading process, avoiding Man-in-the-Middle (MitM) attacks [14]. In addition, data exchanged during the offloading process must be trustworthy, unchanged, and private, especially in critical applications such as public safety [15]. For this reason, this paper proposes a novel offloading architecture for 5G systems in which authentication and privacy are enhanced by leveraging Blockchain technology in two different ways: (i) using a permissioned Blockchain network as a secure and private marketplace for available communications resources; and (ii) using Self Sovereign Identity (SSI) as a novel authentication solution in 5G offloading environments.

This paper is organized as follows: Section 2 discusses the state-of-the-art about security in the 5G offloading processes with a focus on operators marketplaces and authentication systems; Section 3 describes the proposed Blockchain-based secure 5G offloading mechanisms based on a Blockchain-based marketplace described in Section 3.1 and an SSI-based authentication system described in Section 3.2. Section 4 presents the increments in the offloading times due to both security solutions. Finally, Section 5 explains the main conclusions of the work.

2. State-of-the-Art

Offloading refers to transferring data from cellular networks to alternative networks to reduce congestion and improve user experience. These alternative networks refer to other technologies, usually Wi-Fi [16], but they could also refer to other existing cellular networks which are not so congested at a given time [9]. In this way, the amount of data transmitted over cellular networks is reduced, thereby freeing up capacity for other users. It is also employed in situations where the coverage is insufficient, enabling users to connect to more reliable services.

The implementation of 5G technology relies on Software-Defined Networking (SDN) and Network Functions Virtualization (NFV), which provide network virtualization and automation [17,18]. On the one hand, SDN enables centralized and programmable management of network traffic, facilitating decision making on how and when to divert traffic from the cellular network to other networks, thus reducing the load on the core cellular network. With SDN, it is also possible to implement advanced load balancing algorithms that distribute traffic evenly among available resources, avoiding overloads and improving the quality of service. On the other hand, NFV enables the virtualization of network functions that traditionally ran on dedicated hardware, increasing flexibility and efficiency as required by the offloading processes. Therefore, the use of these two technologies allows for the implementation of dynamic policies that divide data in real-time sending a part to other available networks based on the current state of the network. In this sense, resources available in the network must be managed and the load must be balanced.

There are already several studies in the literature discussing data offloading solutions in 5G [19]. Some of them are related to user-initiated offloading techniques in which the user equipment automatically switches from the cellular network to another one, such as Wi-Fi, without having a lot of knowledge of the state of the network. This switching is done without the user noticing, thus improving the connectivity experience [20,21]. However, thanks to the use of SDN and NFV in 5G, it is the network itself that orchestrates the offloading process so as to reduce network congestion or improve the quality of the coverage [22,23]. In this case, the state of the network is known and the decisions are better taken.

In both cases, it is necessary to know the available resources at each moment in order to manage the offloading process in a suitable way. In this sense, there are already some proposals in the literature of marketplaces for bandwidth trading [24,25]. Marketplaces can be implemented through centralized databases, which offer high transaction speed and efficiency but are less secure and transparent than decentralized solutions [26]. Decentralized databases are similar to centralized ones, but data are distributed among several nodes, improving redundancy and availability as well as complexity to manage. However, other options such as Blockchain-based marketplaces [27,28] have started to be considered as they address some of the main disadvantages of marketplaces based on databases.

In addition, during an offloading process, private data are transferred between different networks. Although different cryptographic techniques have already been analyzed in the literature [29], it is still essential to ensure that only authorized devices and users can access these networks to protect data integrity and privacy as well as the security of the network by preventing malicious actors from introducing malware or conducting cyberattacks. Authentication ensures that only legitimate devices can connect to the alternative network, preventing unauthorized access that could compromize the security of the network and the data transferred. This need is already known for 5G general processes, as stated in [30], where several challenges are identified, such as the need for secure authentication, key management, and protection against various attacks. Despite the advancements in 5G authentication [31], several challenges remain, especially when dealing with a high number of connected devices. Additionally, as offloading process mean integration with various networks, secure and efficient cross-network authentication mechanisms are required [32]. Self-Sovereign Identity (SSI) [33] is emerging as a promising approach for authentication in 5G networks, offering enhanced privacy, security, and user control.

2.1. Blockchain-Based Marketplaces

Blockchain is a decentralized and distributed digital ledger that records transactions in a secure, transparent, and immutable way [34]. A transaction is a record of an operation within a Blockchain network which can refer to an exchange of cryptocurrencies, the transfer of digital assets or the execution of smart contracts, among others. Transactions are gathered inside blocks which contain a set of transactions and are linked to the previous block by a cryptographic hash, forming a continuous and secure chain. This structure ensures that once a block is recorded, it cannot be altered without modifying all subsequent blocks, providing high resistance to manipulation and fraud. Each block is verified by the nodes in the network through a consensus process. Once validated, it cannot be modified or deleted.

Blockchain technology has revolutionized several industries by providing a decentralized, secure, and transparent method of conducting transactions [35,36,37]. One of the most promising applications of Blockchain is the creation of secure marketplaces [38,39,40]. These Blockchain-based marketplaces take advantage of Blockchain’s unique features to offer greater security, transparency, and efficiency compared to traditional marketplaces:

• Blockchain removes the need for intermediaries. Unlike traditional marketplaces that rely on a central authority, Blockchain-based marketplaces operate on a decentralized network. This way, costs are usually reduced.
• Transparency is increased as all transactions on a Blockchain are visible to all participants in the network, increasing trust and fairness among users, as they can verify the authenticity and history of transactions.
• Security based on cryptographic techniques used for the link between blocks to provide an immutable ledger. This ensures that all transactions are tamper-proof and verifiable.
• Smart Contracts automatically execute transactions when specific conditions are met, reducing the need for manual interaction and minimizing the risk of fraud [41].

All these features make Blockchain technology well matched to marketplaces where P2P trading between marketplace customers can take place. Inside Blockchain, a secure, fair, and transparent catalog of products can be created allowing search requests execution faster and fairer [42]. In addition, Blockchain allows the definition and automatic application of data access policies, increasing security [43]. Finally, the usage of Blockchain in the bidding process makes it more trusted and tamper-proof—decisions are taken in a transparent and traceable way [44].

Regarding marketplaces considered necessary for offloading processes, there are already several related solutions in the literature. In [45], a Blockchain-based marketplace is designed for secure trading of excess or idle traffic between private individuals. In [46], a marketplace for enhancing vehicular communications is presented. Moreover, in [47,48], marketplaces for secure Federated Learning resources or general telecommunications resources are designed and analyzed, respectively. Although they are not directly related to 5G offloading resources, they can be considered as a reference. Finally, ref. [49] presents a Blockchain-based marketplace especially designed for 5G offloading.

Although all these solutions increase the security of previous marketplaces, there are still some security aspects that need to be addressed. Most of them are usually based on public Blockchain networks, which present some disadvantages for the 5G offloading marketplace [50]:

• Public Blockchain networks usually face scalability issues due to the large number of transactions that need to be processed. This often results in longer processing times and higher transaction costs.
• Although transactions on public networks are transparent, the identity of the participants is not always known, which could be an issue within bidding processes.
• Consensus mechanisms in public networks are usually more energy demanding, reducing efficiency and increasing costs.

These limitations can be overcome by considering a permissioned Blockchain network, where access and participation is restricted to authorized users and, as a result, control and security are increased. There are several alternatives in the literature, such as Hyperledger Fabric [51], R3 Corda [52], and ConsenSys Quorum [53], which offer privacy, robustness, scalability, and improved performance over public technologies. Among all of them, Hyperledger Fabric [51] is probably the most widespread and used technology, it is supported by both official and unofficial channels and it is well documented [54]. Additionally, it is the most prominent modular and extensible open-source system under the Hyperledger umbrella, hosted by the Linux Foundation. Fabric is widely recognized for its flexibility and scalability [55], making it suitable for a variety of industrial applications, including supply chain management, financial services, secure sharing of medical records, or governmental issues [56], which require high throughput and low latency. Additionally, security and privacy are paramount in Fabric. In this sense, Fabric includes (i) identity management that ensures that only authorized participants can access the network; (ii) confidential transactions among subsets of participants; (iii) access control policies which restrict access to resources and operations. For these reasons, Fabric has been widely regarded as a reliable guarantee of integrity, privacy, and transparency for all types of information [57] and is suitable to be considered as the core technology of a marketplace for 5G offloading processes.

2.2. Authentication in 5G Networks

Security for 5G networks is a critical concern and has raised considerable interest in the literature [30,58,59]. Fifth-generation networks have higher security requirements compared to previous generations due to new business applications, network architectures, air interfaces, and user privacy concerns. The integration of new technologies and services in 5G networks has inevitably introduced higher privacy risks [58], necessitating robust security measures.

Authentication emerges as a powerful tool in this context, as it can effectively prevent unauthorized access by verifying the legitimacy of devices and users. In this way, authentication helps to mitigate several risks such as breaching data integrity and privacy by avoiding spoofing or Man-in-the-Middle attacks; or Denial of Service (DoS) attacks, particularly from compromized IoT devices, which can flood the network with malicious traffic [60].

Focusing on authentication, the Authentication and Key Agreement (AKA) protocol is used for the key exchange process between the user equipment, the serving network and the service provider. In particular, the 5G-AKA protocol was outlined in third Generation Partnership Project (3GPP) specification number 33.501 [61] and is the primary authentication mechanism in 5G networks, designed to enhance security features compared to its predecessors. It introduces subscriber identity protection through the use of Subscription Concealed Identifier (SUCI) for improved privacy. However, research has identified several vulnerabilities in the 5G-AKA protocol [62,63,64], such as (i) lack of forward secrecy, (ii) vulnerability to linkability attacks, (iii) potential for active attacks by malicious Serving Networks (SNs); therefore, making this protocol not fully secure [31]. To address these issues, researchers have proposed various improvements and alternative protocols, which are enhanced versions of the 5G-AKA protocol. Some examples are as follows:

• 5G-AKA-FS [62]: This protocol aims to provide both forward secrecy and unlinkability. It introduces modifications to the key generation process and implements additional security measures to prevent active attacks.
• 5G-IPAKA [65]: This improved protocol focuses on mutual authentication between the User Equipment (UE) and the Serving Network (SN), as well as enhanced security for the anchor key and authentication vector.
• SUCI-AKA [66]: This variant reuses the Elliptic Curve Integrated Encryption Scheme (ECIES) secret to address linkability attacks.

It is important to know that the 5G authentication framework is unified by the same methods and can be used for 3GPP access and non-3GPP (such as Wi-Fi) access, and extensible, as the use of Extensible Authentication Protocol (EAP) means that new authentication methods can be added in the future [67]. For this reason, researchers have already explored several alternative authentication methods for 5G networks. One of them is Physical Unclonable Function (PUF)-based Authentication. A two-way identity authentication method (2WIAM) using PUF has been proposed to enhance security and privacy in 5G networks. This approach combines user-provided authentication and geolocation data to detect module clones [68]. Another one is based on the use of machine learning techniques for authentication in 5G networks to address challenges faced by conventional authentication methods [69].The delegated authentication concept, related to federated identity management, has also been investigated as a potential solution for secure and effective authentication in 5G networks [70]. Additionally, Public Key Infrastructures (PKIs) have already been also considered [71,72] to improve trust and security. Finally, a secure and effective authentication scheme using Blockchain technology has also been proposed which highly satisfies the 5G frequent authentication requirement [73].

Despite the advancements in 5G authentication, several challenges remain, and more secure solutions are still required. In addition, as the number of connected devices increases exponentially in 5G networks, scalability and distribution are also essential concerns to be considered. Finally, as 5G networks integrate with various non-3GPP networks, secure and efficient cross-network authentication mechanisms (high interoperability levels) are also required [32]. In this context, Self-Sovereign Identity (SSI) [33] appears as a promising approach for authentication in 5G networks, as it offers enhanced privacy, security, and user control, while guaranteeing the required scalability in massive IoT environments [74,75].

Regarding the use of SSI in 5G, on the one hand, SANS (Self-Sovereign Authentication for Network Slices) has been proposed as an innovative authentication protocol for 5G network slicing [76]. This approach grants users full control over their data by allowing them to prove their right to access specific services without leaking personal information. It provides non-linkable protection for issued information and prevents Slice Operators (SOs) or eavesdroppers from tracking users’ activities. SANS uses Zero-Knowledge Proofs (ZKPs) [77] to achieve these privacy-preserving features while maintaining robust authentication. On the other hand, other authors [78] have explored the application of SSI in privacy-preserving contact tracing apps for 5G networks. This approach offers user control over shared information and privacy-preserving authentication with verifiable credentials and a decentralized storage of sensitive data (e.g., COVID-19 test results). In addition, other authors have highlighted the potential of SSI to enhance security and privacy in specialized 5G applications [79]. They investigated the use of SSI for identity management in ship-based 5G devices, where they evaluated the control overhead, verification delay, and identity reconciliation in SSI-based 5G identity management systems, and analyze use cases, technologies, and challenges for SSI in Industrial Internet of Things (IIoT) contexts. Finally, SSI has been proposed as a solution for secure cloud-to-cloud data migration in 5G networks [80]. This approach aims to enhance data security during migration processes by providing user-controlled authentication and authorization and leveraging Blockchain technology for secure, decentralized identity management.

All these works demonstrate the potential of SSI technology for different aspects of 5G. However, its use for authenticating users among different operators in offloading processes has not yet been considered. As 5G evolves towards 6G, research is ongoing to further integrate SSI into next-generation networks [81] to address current limitations and expand the capabilities of privacy-preserving authentication in mobile networks.

2.2.1. Self-Sovereign Identity (SSI)

SSI uses a decentralized registry, also known as a Verifiable Data Registry (VDR), that stores information such as DIDs (Decentralized Identifiers) and DID documents [82], which are used as identifiers of the different users inside an SSI ecosystem. This registry is usually implemented using distributed ledger technologies (DLTs), such as Blockchain, thus improving the overall security of the system by preserving the integrity and availability of the stored information [83]. SSI works with Verifiable Credentials (VCs), which are digital certificates that contain information about an individual’s identity (holder) and are issued by trusted entities (issuers). These credentials are stored privately in the user’s wallets, that allow users to control access to their personal information and share it selectively with websites, applications, and services. A verifier sends a Presentation Request (PR) to the holder and he or she must generate a Verifiable Presentation (VP) and send it back to the verifier, who then can verify it. More Information about how SSI works can be read in the Verifiable Credentials Data Model v2.0 from the W3C [84]. The SSI not only works for people, but also for machines. In this context, several authors have extended its application to IoT devices [74,85,86].

There are several technologies and frameworks that enable the usage of SSI including Hyperledger Aries [87], Veramo [88], Blockstack [89], Veres One [90], and Jolocom [91], among others. Among all these existing SSI technologies, Hyperledger Aries stands out [87] for its high maturity level as well as lower delay and cost. Aries provides a shared, reusable, interoperable toolset designed for creating, transmitting, and storing verifiable credentials. Hyperledger Aries is the evolution of Hyperledger Indy [92]. Currently, Hyperledger Indy remains as a set of libraries and tools that allow to the deployment of a purpose-built distributed ledger for decentralized identity. The key difference between them lies in their functionalities. Aries primarily covers the agent (client) part of a decentralized identity application that is intended to be agnostic to the underlying ledger/DIDs/verifiable credentials layer. However, Indy is a decentralized identity implementation including support for a ledger (VDR), DIDs, and verifiable credentials. Initially, the idea was to move the agents code implemented in Indy to Aries, and so the first working versions of Aries use Indy underneath for the decentralized identity components. Over time, those components will become pluggable, and additional decentralized identity components will be supported. Thus, major parts of the indy-sdk will be deprecated, as they are now being migrated to Aries.

The Hyperledger Aries Cloud Agent [93] (ACA-Py) is a component within the Hyperledger Aries project. The ACA-Py specifically focuses on providing a framework for building and deploying cloud-based agents. ACA-Py operates within the second and third layers of the Trust Over IP framework [94], utilizing DIDComm messaging [95] and Hyperledger Aries protocols. The term cloud means that ACA-Py is designed to run on servers, being not intended for mobile device deployment. To interact with ACA-Py, developers need to implement a controller that communicates with it by sending HTTP requests and receiving webhook notifications. Due to this modular design, it is adequate to be used in the IoT, such as 5G user equipment. By minimizing the piece of code that runs on the IoT (controller) it is compatible with constrained devices, and the SSI logic (agent) runs on a separate constraint-free server. It also allows developers to use any language of convenience for implementing the HTTP requests. Finally, running most of the code on a cloud server has some security advantages, that is, servers are typically highly protected and backed by cloud service providers and automatically apply updates and patches, which ensures that the client is always protected against known vulnerabilities. Deeper information about the ACA-Py can be read in the official Github repository [93].

3. Blockchain-Based Secure 5G Offloading Mechanism

This paper extends an existing offloading solution designed for Software Defined Radio (SDN)-based 5G networks which enables operators (named primary operators for the rest of the paper) to autonomously initiate the offloading process based on real-time network conditions and without user intervention [23]. The solution is based on an application with a lateral communication mechanism for exchanging user authentication credentials and offloading information. This solution has already proven to be effective as a basis for more secure and more complex offloading processes such as [49], in which a Blockchain-based marketplace has already been considered to support the offloading process and help to decide which alternative operator (i.e., other 5G operators as well as other kinds of services such as Wi-Fi, LTE, etc.) (named secondary operators for the rest of the paper) to consider. However, this solution presents some limitations gathered in

Table 1. Issues and solutions from the state-of-the-art.

Issues from [23,49]	Proposed Solutions
It does not really deep into the technical details of using Blockchain for offloading processes.	This paper includes deep technical details about Blockchain and SSI techniques considered for enhanced security of the offloading process.
It considers an InterPlanetary File System (IPFS) decentralized storage where private information is stored without guaranteeing its privacy.	The information required for the offloading process is stored in a permissioned Blockchain, taking advantage of its inherent security features.
Lateral communications among different operators are required, meaning that a prior mutual relationship is needed.	Prior communication among operators is not needed as it is orchestrated through Blockchain transactions and events.
The validation is done in an Ethereum public network, where throughput, latency, scalability, and privacy are not optimized.	Hyperledger permissioned network is considered for enhanced throughput, latency, and scalability.
User authentication credentials need to be shared among operators, which increases the likelihood of interception and thus problems of unauthorized access or exposure of private information.	SSI-based authentication will be considered avoiding authentication credentials sharing and letting the user to totally control and manage its identity.

, where the proposed solutions from this research work are also included.

Taking these ideas in mind, an extended secure 5G offloading platform backboned by Blockchain technology is proposed in this paper. Figure 1 shows the updated high-level architecture for both the operators (primary and secondary operators) and the user’s equipment, where (i) blue components refer to already existing logic, (ii) orange components refer to new logic for the Blockchain-based marketplace interaction, and (iii) green components refer to the new logic for the SSI-based authentication.

On the one hand, each operator participating in this offloading approach requires the following new components:

• New offloading manager logic which receives the current network state and manages offloading processes when needed. Once an offloading is agreed, it makes a request for resources de-allocation (for primary operator) and allocation (for secondary operator).
• A wallet for the correct Blockchain transactions creation and signature. It will be used by operators for network state updates and secondary operators searching processes.
• Events listener to receive Blockchain events about the new offloading requests. Each registered operator will receive an event with the offloading characteristics.
• SSI controller which will manage the user equipment authentication in any of the operator networks avoiding credentials sharing and identity thefts. The primary operator will issue a credential to the user equipment making the offloading process to the secondary operator, which will verify the identity of the credential prior to the resources allocation.
• SSI agent which will manage the identity of the user equipment through verifiable credentials. The identity issuance (primary operator) and the validation (secondary operator) are executed.

On the other hand, each user equipment requires new logic related to the SSI-based authentication on secondary operators before connectivity being updated from the primary to the secondary operator:

• SSI controller which will manage the user equipment identity received from the primary operator to be offloaded to the secondary operator.
• SSI agent which will manage the reception and secure storage of the received credential from the primary operator as well as the credential sharing for being authenticated in the secondary operator.

Figure 2 describes the high-level operation of the secure 5G offloading mechanism leveraging Blockchain technology. On the one hand, all the operators (5G or other technologies) participating in this mechanism (those registered in the marketplace) will periodically update their network state in the marketplace in order to keep their availability updated for offloading processes from other operators. This process requires their already existing network discovery logic (this logic will be different for each technology) to periodically notify the new offloading manager about the updates. The offloading manager will update the details in the marketplace through the wallet.

On the other hand, when a primary operator detects that an offloading process for a connected user equipment is required due to a shortage of available resources, low coverage, or low quality detected in the network, an offloading process is requested to the offloading manager, which defines the requirements the new (secondary) operator must fulfill for a particular user equipment. These requirements could be related to minimum resources, location, etc. The request is then sent to the marketplace deployed in a Hyperledger Fabric Blockchain network where the search for the most suitable secondary operator is done (see Section 3 for internal details). Once selected, a Blockchain event is sent from the marketplace to the primary and selected secondary operators to notify them about the offloading process for the particular user equipment.

When the event is received by the primary operator, it issues a new credential with information about the new offloading agreement. This process is managed by SSI logic with interactions with the Hyperledger Indy Blockchain network where information about user equipment DIDs and some additional details are available (see Section 3.2 for internal details). As a result, the credential is created, and issued to the user equipment, where it is securely stored. In addition, it also releases the user resources and updated the associated information about available resources and service in the marketplace.

In parallel, when the event is received in the selected secondary operator, it starts making a proof request of suitable agreement credential to the particular user equipment. This proof request will be automatically answered by the user equipment if it is already available (because it has received it from the primary operator). The received proof is then validated against the information in the Hyperledger Indy Blockchain network in terms of content as well as signature (see Section 3.2 for internal details). If the validation is correct, the agreement is considered suitable and the secondary operator allocates the required resources to the particular user equipment, making the user to be connected to the secondary operator. In addition, it updates the associated information about his available resources and the provided service in the marketplace.

Finally, the appropriate payment needs to be made from the primary operator (the one requesting the offloading process for his user) to the selected secondary operator. This process has been left open to different alternatives to allow compatibility with existing financial systems from operators. However, a Blockchain-based payment system could also be applicable if all operators registered in the marketplace agree on its use [96,97].

3.1. Blockchain for a Secure Marketplace

As already mentioned in Section 3, the offloading process in 5G networks involves the transfer of processing tasks and data from the 5G network to another one. This process is essential to improve the efficiency and capacity of the 5G network, especially in an environment where the demand for data and the number of connected devices are constantly increasing. In this context, a marketplace offers multiple benefits and is necessary for several reasons [24,98]:

• Resource optimization: A marketplace allows operators to select the best available options for offloading (i.e., right capacity, optimal location, lower costs, etc.). By having access to a variety of options, operators can make informed decisions that maximize performance and minimize costs.
• Flexibility: A marketplace allows operators to adapt to fluctuations in data and processing demand. This is crucial in situations where workloads can vary significantly (i.e., mass events).
• Competition: A marketplace promotes competition among operators as other operators can compare prices, which incentivizes providers to improve their offerings and reduce costs. This healthy competition results in better services and lower prices.
• Ease of integration: Operators can access a centralized platform where they can find and offloading services without the need for complex individual negotiations, improving operational efficiency.
• Innovation: The presence of a marketplace encourages the development of new technologies and solutions as operators have an incentive to develop and offer new capabilities and improvements (i.e., better energy efficiency) to attract more users.
• Improved satisfaction: A marketplace allows the definition of filters in order to make the operators to select services that best meet their performance, cost, and location requirements, resulting in improved satisfaction.

In summary, a marketplace in the 5G offloading process is crucial for optimizing resources, enhancing flexibility, promoting competition, facilitating integration, fostering innovation, and improving satisfaction. These benefits can even be amplified if Blockchain technology is considered as the backbone technology of the marketplace, as security and transparency are also enhanced by the design. As already mentioned in Section 2.1, improvements are even greater in terms of security, scalability, and performance when considering a permissioned Blockchain network such as Hyperledger Fabric. In addition, the use of Blockchain also allows different operators to communicate indirectly with each other without the need for prior communication.

3.1.1. Architecture and Components

The marketplace is the place where operators can engage in the exchange of services in offloading processes to keep their quality of service for their customers. The idea is to provide a secure tool for an operator to register their current network state and available services as well as to search for other operators available services and resources if required. In this way, a market of operators resources and services is created. This market requires security and transparency, features which are provided by design by the backbone Blockchain technology.

Figure 3 highlights the high-level architecture of all the elements involved in the marketplace operation in orange. The central component of the marketplace is the Marketplace Smart Contract deployed on the Hyperledger Fabric network, which provides all the logic for the operator to register or update their resources (Operator endpoints) and services (Services endpoints) information; or to search for other required resources or services from other registered operators (Consumption endpoints).

The interaction of the operators with the marketplace will be double. On the one side, all the communications initiated from the operators require the use of a wallet where the cryptographic material required for the Blockchain transactions signing process is securely kept. On the other side, the communications from the marketplace happen through Blockchain events [99] that are received in the events listener component required in each operator. This event listener should be subscribed to the reception of all the events from the marketplace smart contract as it will notify the selected operators for offloading processes.

In addition, the possibility of using external services has also been considered. Some examples of potential useful external services for the marketplace could be included but are not limited to the following: (i) intelligent supply and demand-optimized pricing techniques [100]; (ii) payment processing techniques; (iii) review and feedback management; or (iv) digital agreements creation and signature. These external services are accessible through oracles [101], which provide a bridge between smart contracts deployed on a Blockchain network and external services. Since smart contracts on a Blockchain are inherently limited to the data available within the Blockchain itself, oracles are used to fetch and verify external data, making the smart contracts much more versatile and useful.

Figure 4 shows the architecture of the oracles that could be considered for external services. The oracles have an internal Blockchain events listener subscribed to Blockchain Events emitted by marketplace. The oracle analyses the received event, extracts the required information and sends it to its workflow engine where the specific logic is implemented according to the external service needs. For example, a typical case is the oracle building an HTTP(S) request to a external service API to retrieve the external data needed by marketplace. The workflow engine will process the retrieved data as needed and it is sent to the wallet where a Blockchain transaction to the marketplace is generated and signed, providing the updated information from the external service. The Blockchain transaction will update the information in the marketplace related the external service data.

This event-driven implementation of the oracle allows to decouple the oracle logic from the marketplace implementation. For example, if the APIs of external services change or are implemented in a different way, only the oracle logic needs to be modified, without affecting the marketplace implementation. In addition, if the oracles are not available for any reason, the marketplace operation is not interrupted and automatically resumes when the oracle becomes available again.

3.1.2. Data Models and Operations

As already explained, the marketplace includes the logic for three different functionalities.

• The Operator endpoints, which refer to the logic related to each operator identity as well as available resources. Each operator has a unique identifier id, a name (for identification purposes), and a type that categorizes its role within the marketplace. In addition, a percentage of available resources is also included in terms of RAM, CPU, and storage. The following operations related to the operator are available as follows:

  -

  Create: Registers a new operator in the system;

  -

  Update: Modifies an existing operator information. This must be done periodically to keep the marketplace updated;

  -

  Get: Retrieves the information-related to a given operator;

  -

  Delete: Removes an operator from the marketplace;

  -

  List: Retrieves a list of all registered operators.

• The Service endpoints, which refer to the logic related to the services offered by different operators. Each service has a unique identifier id, an operator id (identifying the operator offering the service), the price, the location, the uplink throughput, downlink throughput, and the status, which refers to the availability status. In addition, the requirements in terms of RAM, CPU, and storage are also indicated. The following operations related to the operator are available as follows:

  -

  Create: Registers a new service of an operator;

  -

  Update: Modifies existing service-related information. This must be done periodically to keep the marketplace updated;

  -

  Get: Retrieves the information related to a specific service;

  -

  Delete: Removes a service from the marketplace;

  -

  List: Retrieves a list of all available services.

• The Consumption endpoints, which refer to the logic which allows an operator to search for additional suitable services from other registered operators and be able to proceed with an offloading process. The consumption request includes a unique identifier id, the identifier of the requester operator requester id, and a list of minimum requirements to be fulfilled by the selected service and related operator. This list is variable and refers to the information related to the operator and service data models (i.e., location should be Paris, UL throughput should be higher than 33 Mbps, etc.). There are only two related operations:

  -

  Search: Initiates a new search of suitable services in the marketplace according to the defined requirements.

  -

  Get Result: It provides the result of the search request. It can indicate it is still an ongoing process or it can provide the selected service as a result when the process has finished. This operation has been included for developers, as the result of the search operation will be notified to the involved primary and secondary operators through Blockchain events.

While the operator and service-related operations and results are clear and organic, the consumption functionality requires the following steps:

• Initiate Consumption Request. The primary operator makes a search request in the marketplace specifying the minimum desired service requirements.
• Service Evaluation Phase. From all registered services whose status is available, the marketplace identifies the suitable services that meet the given requirements.
• Operator Evaluation Phase. For each of the identified services, the marketplace checks if the associated operator has the minimum required resources in terms of RAM, CPU, and storage available.
• Service selection. From the identified services, the marketplace will choose that with the better price.
• Completion of Consumption Process. The marketplace emits a Blockchain event confirming that the process has been successfully completed and indicating the following information:
  • The identifier of the consumption request the answer refers to;
  • The identifier of the primary operator making the request;
  • The identifiers of the selected secondary operator and service;
  • The identifier of the UE whose required resources will be offloaded;
  • A list with the minimum requirements specified in the request by the primary operator;
  • A list of the actual values provided by the selected secondary operator and service for the defined requirements;
  • The price of the offloading process for the selected secondary operator and service.
  This event will be received by the primary and secondary selected operators to indicate that they should proceed with the offloading process according to Figure 2.

As mentioned before, this process could be extended at any point with external services. In these cases, as already explained, events must be emitted in order for the oracles to get the required external information. In addition, new methods need to be defined in the marketplace smart contracts in order for the oracles to share the external information with the marketplace smart contract. Each external service consideration requires a different event definition and a new method in the smart contract. For example, let us consider the case in which some external feedback or ratings about the different operators is considered for the most suitable service selection instead of the minimum price. For this example, step 4 should be updated as follows:

• The marketplace sends a new Blockchain event with the information (identifier) about the operators of the suitable identified services after the three previous steps.
• The oracle receives the event, processes it and extracts the list of operators identifiers whose rating values are needed. It also makes a request to the external service with the list of operators.
• The external service operation happens and, as a result, the rating value for each operator in the list is obtained and sent back to the oracle as response.
• The oracle processes the received information and creates and signs the suitable transaction to invoke the new method to update the rating internal information to be considered by the marketplace most suitable service selection.
• The new method in the marketplace smart contract will be executed providing as a result the most suitable service in terms of associated operator rating values.
• Step 5 is then executed in the same way as explained, resulting in a Blockchain event to notify the primary and secondary selected operators.

The process needs to be repeated for each external service, creating a new Blockchain event and a new associated method in the marketplace smart contract. This event-driven approach ensures flexibility, allowing service consumption to continue asynchronously even if certain oracle components experience temporary unavailability.

3.2. Blockchain for Secure Authentication Among Operators

As already explained in Section 3, once the event is received in the primary and selected secondary operators, the offloading process starts in the primary operator. The primary operator releases the resources dedicated to the user involved in the offloading process and issues him a verifiable credentials with information about the offloading process that is to happen. This credential will allow the secondary selected operator to securely identify the user without needing to share any pre-existing authentication information.

3.2.1. Architecture and Components

The SSI-based authentication system for 5G offloading processes follows the traditional set-up of an SSI-based solution, including three main actors: issuer (the primary operator), holder (the user equipment), and verifier (the secondary operator). As already stated in Section 2.2.1, the combination of Hyperledger Aries and Hyperledger Indy is the most widespread and evolved SSI solution. For this combination, the three users require the SSI agent (ACA-Py) with the credentials logic and the SSI controller with the authentication control logic. For the operators, which usually have servers with no computational constrains, both the SSI agent and the SSI controller can be deployed on their premises. However, in contrast, 5G user equipment can refer to all kinds of IoT devices, including devices with very limited features. For this reason, the SSI agent is deployed in the cloud, being always accessible from the user equipment, where the associated SSI controller needs to be deployed. Taking this into consideration, Figure 5 shows in green the high-level architecture of all the elements involved in the SSI operation for 5G user authentication among different operators involved in an offloading process.

As mentioned, the deployment of the operators with both the SSI agent and controllers in servers on their premises is the usual one [102,103]. However, the implementation in limited devices such as IoT can present challenges as they present limited capabilities in terms of resources and performance, which often complicates applying security measures on them, including identity management procedures [104].

Some authors [105] have acknowledged the limitations of IoT devices and consequently propose a proxy-based solution for those extremely constrained. The proxy approach is shared by other authors [106]; for example, by presenting another proxy-based design, termed as IoT Exchange, to connect IoT devices with users. Despite all these works, there is still a need for a performance evaluation focused on IoT devices running SSI solutions. Note that although some works delve deeper into the performance evaluation of SSI [107,108], none of them considers IoT devices. Other works specifically provide measures for devices such as a Raspberry Pi [75], but not for more constrained devices such as Arduino broads, which are commonly used for different IoT devices [109].

Implementing an ACA-Py SSI controller in an Arduino device has a drawback. ACA-Py uses webhooks to connect the agent (installed in the cloud) with the controller (installed in the 5G user equipment, in this case, an Arduino board). Therefore, end devices need to deploy a webserver that listens to incoming communications to receive the information from the ACA-Py agent and take decisions according to the authentication control logic from the SSI controller. Regretfully, Arduino is not capable of deploying any webserver, which limits the implementation capability for ACA-Py. To address this challenge, two alternatives could be considered:

• Automatic mode. ACA-Py agents might be configured in an automatic mode that implies that there is no need to ask the controller what to do. In this case, the Arduino SSI agent would always automatically accept all the received credentials and would always automatically respond with a proof from the credential to every verification request. This would release the SSI controller of the 5G user equipment (Arduino) of any control action. However, this approach is very limited, as the user equipment could not take any decision.
• Polling. In this case, the controller would periodically poll the ACA-Py agent to check if any action needs to be performed. This would allow the SSI controller (Arduino) to make decisions according to any specified authentication logic. This includes that it could decide whether to accept or not a credential and if sending or not proof as a response to a verification request.

The decision between one alternative or the other will be use-case-dependent and therefore there is not a better alternative over the other. However, a rule of thumb is to let the ACA-Py SSI agent manage most of the tasks, thus reducing to the minimum the amount of code that needs to be run in the SSI controller. This is congruent with IoT architectures where most of the computation is extracted of the final devices. For the authentication of users among different operators involved in an offloading process, the second alternative is considered more appropriate because it keeps the possibility for the user to refuse the offloading process if for any reason it does not suit him.

3.2.2. Operation

Figure 6 shows the authentication related operations (credential issuance from primary operator and verification from secondary operator) considering the polling alternative among SSI controller and SSI agent. For simplicity, it is supposed that DIDs for all the agents have already been created and they have already been on-boarded, and therefore they can communicate with each other.

As previously discussed, the SSI controllers are periodically polling their respective ACA-Py agents, allowing the user and operators to make conscious decisions. On the one hand, the credential issuance operation requires the following steps:

• The SSI controller of the primary operator receives the information by the offloading event with all the information required to issue the identity credential.
• The SSI controller of the primary operator notifies the SSI agent to create the credential with the required attributes.
• The SSI agent obtains the schema and DID information of the UE from the Hyperledger Indy Blockchain network.
• The SSI agent of the primary operator issues the identity credential to the UE SSI agent.
• Periodically, the SSI controller of the UE is polling the SSI agent for news.
• For the polling request in which the SSI agent of the UE has already received the credential, the UE SSI controller decides to accept or not the credential.
• If the credential is accepted, the SSI agent locally stores it and the release of resources can happen in the primary operator.

On the other hand, the credential verification operation to happen on the selected secondary operator requires the following steps:

• The SSI controller of the secondary operator receives the information from the offloading event with all the information required to request an identity proof to the particular UE (UE identifier).
• The SSI controller of the secondary operator notifies the SSI agent to create an identity proof request to the UE.
• The SSI agent obtains the schema and DID information of the UE from the Hyperledger Indy Blockchain network.
• The SSI agent of the secondary operator sends the identity proof request to the UE SSI agent.
• Periodically, the SSI controller of the UE is polling the SSI agent for news.
• For the polling request in which the SSI agent of the UE has already received the identity proof request, the UE SSI controller decides to accept or not the issuance of a proof response.
• If the proof request is accepted, the SSI agent lof the UE sends the associated proof response to the SSI agent of the secondary operator.
• Periodically, the SSI controller of the secondary operator is polling the SSI agent for news.
• For the polling request in which the SSI agent of the secondary operator has already received the proof response, the SSI controller decides to accept or not it.
• If the proof response is accepted, the SSI agent of the secondary operator verifies the signatures of the received proof response against the Hyperledger Indy Blockchain network to be sure of its authenticity.
• The SSI controller of the secondary operator continues polling its agent periodically.
• For the polling request in which the SSI agent has already verified the proof response, the SSI agent sends the verification result to the SSI controller, which analyses the offloading parameters and provides the required and agreed resources to the UE.

4. Performance Evaluation

The time it takes for a 5G offloading process can vary depending on several factors, such as the specific network infrastructure, the traffic load and the specific technology used for offloading. In general, the 5G offloading process is designed to be very fast and efficient, minimising latency and ensuring a smooth transition between networks. For this reason, it is important that the two new systems proposed to be included to secure the process do not degrade its performance to undesirable values.

4.1. Blockchain-Based Operators Marketplace

The central component of the marketplace testbed is a Blockchain network based on Hyperledger Fabric 2.4.8 [110], known for its robust, modular architecture, and strong security features. The test environment is built on a hardware platform featuring 16 x Intel^® Xeon^® Platinum 8268 CPU @ 2.90GHz (CPU), 16 GB of RAM, and a 400 GB HDD for storage, ensuring sufficient resources to handle the computational demands and persist the required data of the marketplace. The test Blockchain network is organized into three organizations, each one hosting a single peer and a Certificate Authority (CA) to manage digital identities and secure access. Additionally, three orderers have been deployed to coordinate transaction ordering and commit operations across the network, ensuring high availability and fault tolerance. This is an example setup to carry out reference performance evaluations. However, in a real scenario, there should be a dedicated Blockchain network composed of as many organizations as operators participate. The particular number of peers and orderers can be adaptable for each one.

This section evaluates the additional time required in an offloading process because of the consideration of the proposed marketplace. This additional time could mean a degradation on the service quality because it could be perceived as a noticeable cut in service. For this purpose, a script simulating the interactions of an operator with the marketplace deployed in the example Hyperledger Fabric Blockchain network has been developed as shown in Figure 7. As Google Remote Procedure Call (GRPC) [111] procedures are commonly used in Blockchain networks to enable nodes to request and execute procedures or functions on remote servers, the required GRPC procedures for the different operations have been implemented to interact with the different Blockchain endpoints from simulated operators. In this context, the following operations have been evaluated:

• Prior to the offloading process:

  -

  An operator registration process. The Create operation from the Operator endpoints is executed by an operator administrator. This process execution time is negligible in comparison with the time required for one block to be aggregated to the Blockchain network, which is variable according to some configuration parameters. In the considered example Blockchain network, this time is around 2 s. It is an example value that could be optimized in a real deployment. Anyway, the impact of this time is not relevant as it will happen only once, when the operator decides to participate in the marketplace, prior to any offloading process.

  -

  A service registration process. The Create operation from the Service endpoints is executed for each available service by an operator administrator. As in the previous case, this process execution time is also negligible in comparison with the time required for the block aggregation in the Blockchain, which takes also around 2 s. This process will also happen only once per service, when the operator decides to participate in the marketplace, prior to any offloading process. Different services could be registered in the same Blockchain block, reducing and optimizing the services required registration time.

• Periodically and for each offloading process:

  -

  Each operator inside the marketplace must periodically update the percentage of available resources as well as the availability status of its services. The Update operation from the Operator and Service endpoints is executed, respectively. As in previous cases, this process takes also around 2 s due to the block aggregation time to the example Blockchain network as the operation time is negligible. This process will happen periodically and in parallel to other activities of the operator, so the offloading process quality is not degraded as the cut-off time is not increased.

• For each offloading process:

  -

  The primary operator in the offloading process makes a search request to the marketplace of the most suitable secondary operator. The Search operation from the Consumption endpoints is executed. This process happens just before the release and new provision of resources happen so the quality of service is not affected.

  Table 2. Execution time of secondary service search.

  Simultaneous Requests	Requirements	Registered Services	Search Time (s)
  1	2	10	2.18
  		50	2.25
  		100	2.21
  		1000	2.30
  	4	10	2.17
  		50	2.21
  		100	2.22
  		1000	2.43
  	7	10	2.17
  		50	2.21
  		100	2.22
  		1000	2.57
  10	2	10	0.44
  		50	0.49
  		100	0.45
  		1000	0.41
  	4	10	0.44
  		50	0.47
  		100	0.48
  		1000	0.47
  	7	10	0.44
  		50	0.48
  		100	0.49
  		1000	0.46
  100	2	10	0.29
  		50	0.18
  		100	0.15
  		1000	0.47
  	4	10	0.30
  		50	0.18
  		100	0.15
  		1000	0.41
  	7	10	0.31
  		50	0.19
  		100	0.15
  		1000	0.44
  1000	2	10	0.35
  		50	0.26
  		100	0.28
  		1000	0.89
  	4	10	0.41
  		50	0.39
  		100	0.46
  		1000	0.90
  	7	10	0.49
  		50	0.53
  		100	0.51
  		1000	1.00

  gathers the execution time for the search for different registered services in the marketplace, different requirements in the search request and different simultaneous search requests from different operators. The search time column refers to the average time per request taking into account that simultaneous requests can be included in the same block to be aggregated to the Blockchain network. In addition, the associated event generation time is also considered inside the search time.

  *

  It is important to notice that in the case of a single request, the search time is mainly influenced by the time required by a block to be aggregated to the example Fabric network. The number of requirements considered in the request or the number of already registered services on which to search has a low impact on the search time.

  *

  When 10 simultaneous requests are considered, around 0.4–0.5 s average search time is obtained, as the block aggregation time is shared by all the requests. Anyway, the number of requirements and the number of registered services still have no significant impact on the search time, which is still more influenced by the block aggregation time.

  *

  The situation starts to look different for 100 simultaneous requests. On the one side, the average search time for 50 and 100 registered services is around 0.15–0.19 s. However, the number of registered services starts to influence the search time with 1000 registered service, which increases the average search time up to 0.41–0.47 s. On the other hand, the situation for 10 registered services is different, as it requires a higher average search time of 0.3 s, which is higher than for 50 and 100 registered services. This could be because the search time is still mainly influenced by the time required by a block to be aggregated to the example Fabric network.

  *

  Finally, the parameters start to influence the search time when 1000 simultaneous search requests are considered. In this case, as in the previous case, the search time for 10 registered is higher than for 50 and 100 registered operators, probably due to the higher influence of the block aggregation time. However, the search time slightly increases with the number of requirements defined in the request, moving from 0.35 s for two requirements up to 0.45 s for seven requirements. The search time increases also with the number of requirements as well as with the number of registered services for 50, 100, and 1000 registered services.

  *

  As a summary, for a maximum number of 100 simultaneous requests, the search time is mainly influence by the block aggregation time to the particular Blockchain network, which can be optimized as required. However, for a higher number of simultaneous requests, such as 1000, the search time increases with the number of requirements and the number of existing registered services in the marketplace.

In conclusion, the Blockchain-based marketplace adds an additional execution time in exchange for providing security, transparency and trustworthiness to the offloading process. However, it does not affect the service quality as its complete operation happens prior to the release and new provision of resources. As a consequence, it could be deduced that the offloading process using the proposed Blockchain-based marketplace should be started earlier than in the standard solutions from 5G.

4.2. SSI-Based Authentication of UEs

Arduino boards are commonly used for simulating IoT devices when prototyping and testing solutions [112,113,114]. In this case, the device used for the performance evaluation of a constrained IoT device for its SSI controller is an Arduino SP32-C3-32S. It has a single core 32-bit RISC-V Microprocessor with clock frequency up to 160 MHz and 400 KB of SRAM. The testbed has been completed with a Dell Latitude 5580 equipped with an Intel^® Core™ i7-7600U and 8GM of RAM memory, where three Hyperledger Aries SSI agents (ACA-Py) have been installed in three docker containers: issuer representing the primary operator, holder representing the UE, and verifier representing the secondary operator. To implement the VDR, an Hyperledger Indy network has been deployed in another machine, with four nodes in their respective docker containers. Finally, the ACA-Py controller has been programmed and deployed in the Arduino SP32-C3-32S. The same Arduino controls the three ACA-Py agents (issuer, holder, verifier) as their operation is not parallel and occurs at different (sequential) times. Taking this into consideration, Figure 8 shows the implemented testbed.

This section evaluates all the relevant SSI methods, including credential issuance, proof request, proof response, and proof verification [115]. The relevant SSI methods refer to the basic methods defined by the W3C [84] that allow to complete a full verifiable credential lifecycle. It is important to take into account that some of the SSI methods are related to the primary operator (credential issuance) and secondary operator (proof request and proof verification), which are implemented in servers with no computing limitations, and their performance has already been analyzed in the literature [75,108]. However, all the methods performances are evaluated in an Arduino board as a reference. In addition, the polling method introduced in the proposal is also evaluated. Each method has been launched 100 times and their performance results distributions have been measured.

• Issue verifiable credential (Issue VC). The Arduino SSI controller invokes the ACA-Py issuer SSI agent (simulating the primary operator) to issue a credential to the holder SSI agent (simulating the UE).
• Send a proof request (Send PR). The Arduino SSI controller invokes the ACA-Py verifier SSI agent (simulating the secondary operator) to send a proof request to the holder SSI agent (simulating the UE), asking for the credential issued in the step 1.
• Polling. The Arduino SSI controller polls the ACA-Py holder agent (simulating the UE) for an incoming proof request. This polling activity is the same in other points of the SSI operation flow from Section 3.2.2.
• Send a verifiable proof response (Send VP). The Arduino SSI controller invokes the ACA-Py holder SSI agent (simulating the UE) to generate a proof response that match the received proof request from step 2 and sends it to the verifier SSI agent (simulating the secondary operator).
• Verify the verifiable proof response (Verify VP). Arduino invokes the ACA-Py verifier SSI agent (simulating the secondary operator) and verifies the received proof response from step 4.

The code implemented in the Arduino device uses 877.190 bytes, 66% of the program storage space. Timers are set to measure the time elapsed from the moment the method is invoked to that in which the corresponding response is received, thus including the computation done by the agent. The obtained performance evaluation results from these tests are shown as boxplot diagrams in Figure 9 for the different SSI methods:

It is important to notice that the credential issuance (Issue VC) and the proof response verification (Verify VP), which are the most time-demanding methods will be executed in servers with improved capabilities and the performance will be much better. So, the important method to be considered is the proof response (Send VP) which will be executed in a potentially constrained UE. In this case, the additional time to the offloading process is of around 80 ms.

Anyway, considering the complete flow is executed in constrained devices, the identity agreement credential issuance process would mean a maximum increment of around 425 ms (400 ms for Issue VC and 25 ms for Polling) to the already existing offloading execution times. This time is not an issue as it happens before the resources from the primary operator are released.

In the case of the identity agreement credential verification process, which is executed after the primary operator releases his resources and before the secondary selected operator provides the new resources to the UE, the offloading execution time will be increased to a maximum of around 545 ms (40 ms from Send PR, 80 ms from Send VP, 350 ms for Verify VP and 75 ms of three different pollings). This maximum value will affect the service cut-off time during the offloading process. However, it could be acceptable and not significantly affect the user experience for some everyday applications such as web browsing weather sensors data sharing or even video camera transmissions which do not demand real time. However, it is better to consider more powerful devices for the operators to improve performance and allow more critical services. It is also necessary to consider that there are three polling cycles in the identity agreement credential verification process. Therefore, the speed of the process depends on the polling time. Reducing the polling time ensures that the response time is faster. However, it must be considered that a lower polling time implies a higher power consumption in the Arduino device. In case they are battery powered, this element would be critical, although rechargeable batteries are common in UEs, which are significantly more durable. However, we have estimated the energy cost of sending a polling message based on the tables of energy consumption and taking into account that a polling message and response take 25 ms in average, consuming 295 mA on every transmission. Thus, the consumption would be 1.88 uAh. Let’s suppose that the three polling cycles last a maximum of 1.5 s. On a normal battery of 5200 mAh, that would imply that this battery would last around 16 days with no charging, which is more than acceptable in an environment such as the one considered. Therefore, an optimal solution is to use the authentication mechanism in a UE that is connected to power, but where the connection is not reliable it can be backed up by simple or rechargeable batteries.

5. Conclusions

This research work introduces a secure mechanism for 5G offloading processes, leveraging Blockchain technology and SSI authentication systems to address their critical security and privacy challenges. The proposed solution enhances the resource-sharing processes in offloading by introducing a Blockchain-based marketplace and decentralized identity-based user authentication mechanism, resulting in improved security, flexibility, and user control.

On the one hand, utilizing a permissioned Blockchain (Hyperledger Fabric) as the backbone of the marketplace allows for secure, transparent, and efficient resource allocation among operators. The marketplace automates the matchmaking process between primary and secondary operators, optimizing service delivery and enhancing operational flexibility and scalability in offloading environments. On the other hand, the integration of SSI ensures decentralized, trustworthy, and privacy-preserving authentication during the offloading process. SSI eliminates the need to exchange user credentials between operators, reducing the risk of unauthorized access and data breaches. The ACA-Py’s ability to abstract the logic of SSI methods through its REST API has proven to be highly effective in this context. Furthermore, the modular design of the ACA-Py by minimizing the code deployed in the final user equipment suggests that it could be deployed on a wide range of IoT devices. Both technologies performance has been evaluated with adequate results in terms of additional service cut-off time. On the one hand, much of the additional complexity happens prior to the offloading process itself, so offloading processes management should start earlier than with current implementations to cover an additional required time of around 2 s. On the other hand, the cut-off time increases in around 0.5 s, which makes the solution more suitable for 5G applications where real time is not demanded.

In the case of future work, the performance analysis should be extended for a higher number of existing operators and services in order to better analyze the scalability of the system. Different block sizes and consensus protocols should be evaluated in Fabric, as well as the possibility of considering the horizontal scalability of Fabric nodes in terms of computing, storing, and validation for highly demanding scenarios. Regarding SSI, different DIDs and ligther SSI agent solutions could be evaluated as well as analyze the possibility of optimizing the signatures validation processes (i.e., using a cache). Moreover, although payment mechanisms were left open, future implementations could further utilize Blockchain also for secure and automated financial transactions. Additionally, Blockchain could also be taken into account for secure, transparent, and trustworthy service feedback for improved operator selection. Finally, the proposed solution should be integrated into currently existing 5G equipment for better interoperability and performance analysis.

The proposed architecture is compatible with offloading processes for both 5G and non-5G networks, making it a versatile solution in heterogeneous network environments. The approach is well-suited for evolving any kind of 5G applications, showcasing the potential for integration into future 6G networks and beyond.