Multi-Party Collaboration in 5G Networks via DLT-Enabled Marketplaces: A Pragmatic Approach

—To fully cope with the requirements of innovative 5G use cases, evolving business models and ﬂexible networking scenarios spanning multiple administrative domains are envisioned. In this context, transparent and trusted frameworks that enable network service providers and infrastructure providers to advertise, negotiate and acquire, in real time, 5G resources and services, distributed over various geographical areas, are extremely valuable. To address this goal, emerging Distributed Ledger Technologies (DLTs) arise as well-suited solutions to ensure distributed security and trust, as well as effective and agile transaction management across the various parties involved in the 5G service chain implementation. Following this vision, this paper presents the design of a DLT-enabled Marketplace aimed to foster the secure trading of heterogeneous resources in dynamic 5G ecosystems. The performance of an initial implementation as proof-of-concept is also analyzed. The results of this proof-of-concept validate the feasibility of a decentralized marketplace implementation in the context of 5G resource trading.


I. INTRODUCTION
Among all pillars of digital evolution, next-generation technologies (5G and beyond) play a pivotal role as new networking paradigms conceived as truly converged network environments. Such environments encompass fixed and wireless network technologies, as well as cloud infrastructures, to create ubiquitous and sustainable network services with very high Quality of Service (QoS). The challenges to be overcome by these communication systems include extremely high speeds and capacity, ultra-low latency and power consumption, multi-tenancy, on-demand service-oriented resource allocation and automated management and orchestration [1].
In 5G terminology, an end-to-end composite service or slice is a fully-fledged solution that satisfies all requirements of a vertical industry in terms of coverage, networking and computing resources, as well as Virtual Network Functions (VNFs) [2]. From a pragmatic perspective, such a heterogeneous and multidimensional service package can hardly be supported by a single provider without a partnership or multi-party collaboration, especially for ubiquitous scenarios spanning wide areas or requiring specific pervasiveness. As a matter of fact, a European-wide end-to-end pervasive service needs to be composed of 5G services and resources coming from different providers, each with certain capabilities, characteristics and geographical footprint [3].
While appealing, such heterogeneous and multi-stakeholder 5G ecosystem poses high requirements to current business models and traditional management systems. In this scope, Distributed Ledger Technologies (DLTs) (commonly referred by its most popular supporting technology, Blockchains (BCs)) are expected to play a relevant role in beyond-5G developments for several use cases like spectrum sharing and resource trading [4]. In particular, as DLTs do not rely on preestablished trust among involved parties and agile settlements can be realized by using Smart Contracts (SCs), they represent a unique opportunity to address the challenges of distributed security, trust and automation required for the implementation of 5G service chains involving multiple parties. However, there is a lack of frameworks supporting multi-party collaboration in dynamic 5G ecosystems. This paper presents a DLT-enabled Marketplace that allows stakeholders the trading of heterogeneous resources in order to facilitate the establishment of fully pervasive services across different domains. To this end, Section II revises existing work targeting the use of marketplaces in 5G environments. A detailed description of the proposed architecture is then presented in Section III, together with the main supported functionalities and addressed challenges. Finally, a Proof of Concept (PoC) implementation focused on VNFs trading, together with its performance evaluation, is provided in Section IV.

II. RELATED WORK
With the goal of facilitating the interaction between different stakeholders involved in multi-party 5G service delivery,centralized marketplaces have been introduced by previous research efforts. For instance, the Matilda project [5] proposed a marketplace acting as common repository for VNFs, where the referred applications can be exchanged, extended and/or instantiated. Similarly, dynamic offerings of infrastructure resources meeting specific compute and connectivity requirements from multiple providers are made available to slice tenants in [6]. However, these centralized approaches have known limitations such as single point of failure, need of a trusted party as marketplace operator, and reduced transparency and flexibility of operational rules.
To overcome the aforementioned challenges, DLT-based solutions are becoming a common trend for the realization of distributed marketplaces. In particular, the work presented in [7] investigates the use of SCs deployed in a BC for VNF verification (in terms of integrity, accountability and provenance) before uploading them to a Network Function Virtualization (NFV) repository for further usage and exchange. Nonetheless, this work provides only a description of the proposed architecture, without implementing it on a real BC solution.
A hybrid centralized/decentralized marketplace built upon Ethereum BC is proposed in [8]. The proposed architecture is composed of a set of consumer and provider nodes, each one associated to several clients. By using SCs, two marketplace features are implemented, namely offer creation and offer query, with the later also supported by an external array maintained in the consumer nodes. Given the not fully decentralized nature of this approach, if a consumer node fails, the marketplace functionalities become unavailable to a subset of consumer clients.
Finally, the idea of exploiting the benefits of the BC technology in a federated environment of network providers for dynamic resource exchange and management has also been evaluated in [9]. The proposed solution is based on SCs written in Solidity and deployed in a Quorum network to perform three main operations: adding a new provider, get matching offers and resource reservation. While the suitability of BC technologies for distributed resource management is validated, this work does not focus on the full design of a marketplace.
The design of a DLT-enabled 5G Marketplace in the 5GZORRO project addresses the aforementioned gaps, and how it enables the sharing of heterogeneous types of resources across multiple operators and resource providers is described in the following section.

III. DISTRIBUTED MARKETPLACE FOR 5G ECOSYSTEMS
The 5GZORRO architecture [10] aims at facilitating multi-party collaboration in dynamic 5G environments where operators and service providers often need to employ 3rd party resources to satisfy a contract. To achieve this, resource providers make their resource offers available for sharing by advertising them through the 5G Marketplace. In general terms, the proposed Marketplace enables the creation and acquisition of product offers that represent a variety of exposed telco digital assets. These offers include individual resources such as infrastructure components, VNFs and Cloud-Native Network Functions (CNFs); as well as composed bundles in the form of services and slices.

A. Concept and Architecture
Given the targeted decentralized nature, the proposed Marketplace platform is the result of a mesh of distributed instances like the one depicted in Figure 1. This figure shows the main internal components of the Marketplace, while it also illustrates the Governance Platform and supporting Distributed Ledgers, as key pillars of the proposed framework the Marketplace needs to interact with.

1) DLT & Smart Contracts:
The Marketplace Platform leverages the use of DLTs and SCs technologies to enable the trade of 5G resources. By leveraging a decentralized architecture, thus removing a single trusted entity, stakeholders converge on a mutual trust in the distributed state of the application. However, in addition to the foundational trust that underpins the marketplace, privacy, performance and the capability to implement the necessary business rules are fundamental enterprise requirements placed upon the supporting DLT infrastructure.
Furthermore, two essential DLT requirements were identified, one to support marketplace resource and service trading and the other to support cross-domain identity and permissions. Whilst it seems reasonable to satisfy both requirements using one DLT, the decentralised identity requirement represents an opportunity to leverage a supplementary DLT developed specifically to address this use case. As such, a Marketplace DLT network supports the trading and Service Level Agreement (SLA) management requirement and a Governance DLT and associated libraries underpin the management of Distributed Identifiers (DIDs) and the issuance/verification of Verifiable Claims (VCs) to support identity and permission requirements (cf. Section III-A2). Each marketplace stakeholder operates a DLT node and interfaces with it through the hosted marketplace instance. A Governance Board (marketplace administrator stakeholders) also host a governance DLT node and oracle services, utilised by marketplace traders and regulators. SCs encapsulate the business rules that govern ledger state transitions for marketplace transactions, allowing potentially oblivious stakeholders to form commercial agreements without a trusted 3rd party intermediary. The adoption of these technologies to underpin both the marketplace but also its associated governance model gives rise to a trusted platform such that all bilateral or multilateral transactions are automated and non-repudiable owing to their storage on an immutable decentralized ledger.
The Marketplace DLT is utilised to support the realisation of a decentralized Catalogue of product offers and the subsequent trading of these resources (cf. Section III-A3). Thanks to the privacy features of the DLT implementation, stakeholders only have sight of requests and all associated transactions and state on a need-to-know basis. SCs facilitate a trusted negotiation process between consumer, provider and -as needed -regulator, that aligns with agreed business rules through an eventual agreement.
2) Governance Platform: The Governance Platform comprises a set of software modules deployed by the Marketplace Administrators (members of the Marketplace Governance Board) that have permissions to take decisions according to the Marketplace Governance Model. A major Governance feature is the decentralized management of global (cross-domain) unique identifiers that are compliant with the emerging W3C DID Working Group (WG) [11].
The Governance Platform is able to identify providers, consumers, services, resources, stakeholder, etc., using DIDs. DIDs do not need a centralized registration authority since they are created and/or recorded using cryptographic proofs. Furthermore, DIDs provide characteristics such as decentralized control, privacy, security, interoperability, and extensibility, making it able to address some of the shortcomings of current identity management systems. Related to DIDs, the Governance Platform also provides the management of W3C compliant VCs [12], representing statements made by the Marketplace Governance Board in a tamper-evident and privacy-preserving manner.
In overall, services provided by the Governance Platform include marketplace governance management, decentralized identity & claims verification, and a managed repository of legal prose templates, which are made available by the following software modules: • Identity and Permissions Manager: is in charge of securely handling different types of identifiers and credentials required to support trustworthy trading of offers in the 5G Marketplace via DID agents. For non-admin stakeholders, the provided agent may play two roles: a) as a Provider Trading agent, it requests offer credentials to Admin agents that will be securely stored in its Governance Wallet; and b) as a Consumer Trading agent, it requests Provider Trading agents a presentation of the offer credential to verify its cryptographic proofs.
• Governance Manager: is responsible for facilitating and coordinating marketplace governance in a decentralised manner. Administrators of the platform (Marketplace Governance Board) are responsible for partaking in reviewing and voting on proposals subject to governance. This decentralized process will be underpinned by the Governance DLT in order to ensure full transparency and auditability.
• Legal Prose Manager: provides smart legal contract templates, that can be queried by stakeholder marketplace platforms to build concrete SLAs, Agreements and Licence Terms. Stakeholders can propose new templates and updates, which are then subject to a consortium governance process prior to being approved for use.
• Governance Portal: provides a web user interface to enable the usage of the Governance features by endusers including management of legal proses, tools to take governance decisions and management of Identities and Permissions.
3) Marketplace Platform: The Marketplace Platform provides the tools for the on-boarding of assets and offer composition; the sharing of offer updates among participants; the on-demand order capture and agreement settlement for offer purchase/consumption; and the continuous SLA management to ensure the fulfilment of agreed conditions. More in details, in order to trade product offerings, a provider must first compose their product offering. An offer encapsulates the resource technical specification and corresponding SLAs, agreements, pricing and licensing terms. For instance, in the case of a spectrum offer, a SC -utilising a DID Oracle Service -verifies the publishing provider has the necessary spectrum rights as part of the business rules that govern a valid advertisement of a Catalogue offer. This DID Oracle Service takes VC presentations and verifies them, providing external, trusted attestation before the transaction can be committed. Once successfully published to the DLT, a new product offer or update is then propagated to all trading nodes so their own Catalogue can be updated.
Stakeholders acting as asset consumers interact with the Marketplace to obtain the set of product offers available and suitable to satisfy their needs. The lifecycle of an offer request (i.e. product order) is also governed by the DLT-based Marketplace. Having compiled a product order consisting of the required product offers, a consumer places its request via the Marketplace to be published to the DLT. Subsequent management of the workflows for resource provisioning, setup/teardown of SLA monitoring infrastructure, permissioned recording of SLA violations & licensing actions (e.g. scale up/down), and ultimate teardown of service agreements and remuneration on completion of a contract is all automated thanks to SC execution. Finally, a Resource Proxy Oracle service plays an integral role in the activation phase of the agreement by attesting to (or rejecting) the fact that a resource has indeed been provisioned.
To provide the above mentioned capabilities, the following modules compose the proposed 5G Marketplace.
• Marketplace Portal: Storefront for offer composition, searching and selection to enable a business-complaint and user-friendly offer design, discovery and display.
• Resource and Service Catalogue: Portfolio of available resource and service digital assets and corresponding product offers for stakeholders to register, browse and request within the marketplace. This decentralized and multi-category repository defines how assets and products are modelled through the use of standard open Application Programming Interfaces (APIs) [13].
• Smart Contracts Lifecycle Manager: The central focus of this module is to manage lifecycle of entities (i.e. offers, SLAs and commercial agreements) deployed to the underling ledger through SCs, as well as to expose the necessary abstract interfaces for managing these SCs on the DLT publishing associated lifecycle events for subscribing apps to consume.

B. Marketplace Functionalities
In the following the most relevant functionalities of the distributed 5G Marketplace are described.
1) On-boarding of Resource Assets: Resource providers on-board and store in the Marketplace the technical description of available assets. Given the diverse nature of considered resources, this description includes, but is not limited to, resource category (cloud, edge, spectrum, ran, etc.), geographic location and main physical and virtual characteristics that outline the offered capabilities.
2) Composition and Publishing of Product Offers: Based on onboarded assets, product offerings can be quickly assembled at the Marketplace. Following a consistent and standardized component definition, properties like the productoffering price, can be created once and reused many times as part of new product offerings. SLAs corresponding to the conceived product are also associated to the offer, which are conformed based on suitable contract templates. Once the product offer is assembled, the Marketplace triggers the deployment and commitment into the ledger of the SC related to the new product offering.

3) Retrieval of DLT-announced Product Offers:
In order to keep a consistent and distributed awareness about available offers, Marketplace instances subscribe to DLT-events relating to offer registration/update/removal. After such events are advertised, shared information is processed, and every peer's storage is updated. Considering for instance the case of new offers, data exchanged via the ledger are consumed for offer composition and storage, leaving them available for lookup at each participant instance.

4) Offers Discovery and Capture of Orders:
Stakeholders acting as customers (e.g. Communication Service Providers) will access the Marketplace in order to find an offer suitable for their needs. Advertised product offers can be searched by filtering them based on several criteria such as category, provider, and geographic location, among others. After performing a selection, the customer places a request specifying the corresponding offer, which is translated as an update of the associated SC. This new record triggers a feasibility check at the provider instance, which is delegated to the associated resource management entities, to confirm whether the corresponding product (i.e. availability and sufficient capacity of the involved resources to support the product order) can still be delivered. The result is then propagated back to the customer, which, if feasible, proceeds with the required orchestration actions.

C. Addressed Challenges
The multi-party nature of the proposed 5G Marketplace brings with it numerous challenges that must be met by equipping the solution with advanced technological features. These challenges are related to potential threats to the Marketplace operations, whether in terms of security, trust, privacy, etc. Thus, the following items constitute the most pivotal challenges tackled by the proposed DLTenabled Marketplace, which are critical to ensure the proper functioning of this solution.
• Zero Trust. Zero trust is a security principle focused on the idea that stakeholders ought not to rely implicitly on other stakeholders, previously known or unknown, inside or outside their perimeter. Thus, a zero-trust network management allows dwindling security risks and attack surface at both intra-and inter-domain levels. In this vein, the proposed Marketplace involves a set of zero-trust requirements and features such as compulsory identity management before granting access, or the application of least-privilege rules as a basis, by means of intra-and inter-domain policies to ensure access control.
• Privacy-preserving. Data privacy is a paramount principle in telecommunication networks. In this regard, the proposed DLT-enabled Marketplace preserves consumer privacy by generating a secure and trustworthy communication channel among multiple domains that relies on the cryptographic material stored in DIDs and VCs to originate the shared keys. Hence, the marketplace platform also assures privacy and integrity without sacrificing performance.
• Distributed nature. Pervasive and scalable resource sharing in 5G and beyond-5G networks is making centralized approaches to be replaced by distributed solutions. This distributed approaches boost collaboration between multiple parties for ondemand service provisioning. Ergo, the presented Marketplace covers the distributed nature including the use of DLTs to enable the trade of resource and service offers and the design of a decentralized Catalogue architecture.

IV. PRACTICAL IMPLEMENTATION
To demonstrate the suitability of the proposed DLT-enabled Marketplace, this section presents an initial implementation as PoC that focuses on a trusted VNF Marketplace, in which properties such as data digitalization, traceability of transfers, transparency, verifiability, and immutability of the register (Ledger) are guaranteed by using R3 Corda Blockchain technology [14]. In addition to achieving high transaction throughput, Corda is ideally placed to ensure privacy and has a strong focus on legally enforceable smart contracts.

A. System Architecture
The VNF Marketplace has been designed starting from the concept of Corda Network, i.e., a peer-to-peer network where each node represents a legal identity and run Corda software: an instance of the Corda platform and one or more Corda distributed applications (CorDapp). The Corda release used in the PoC is the Open Source 4.6 version. As depicted in Figure 2a, the Network consists of four peers, logically divided into Repository, Developer, Buyer, and Notary. The Repository is the entity to which all other peers on the network communicate to perform Marketplace operations. The Developer has the purpose of establishing an agreement with the Repository to submit its VNF offers on the Marketplace, so that the latter can be viewed and purchased by the Buyer. The Notary is a network service that prevents double-spending events, by working as time-stamping authority, and can also validates transactions. The Marketplace uses as VNF package storage a VNF Catalog [15] to allow the registration, update and purchase of the packages which have been onboarded to it.
The Notary is a pure Corda Node and it is deployed as is, while the other peers encompass it internally along with other modules, sharing the same structure, as depicted in Figure 2b. A Corda Node consists of three main components, namely Vault, Flows and RPC Endpoint. The Vault contains data relevant to the Node's owner, stored in a relational model that can be easily queried and worked with. It keeps track of both unconsumed and consumed States, i.e., immutable objects representing a fact known by one or more Corda Nodes at a specific point in time. Flows are programmable entities that allow the communications between the Corda Nodes and the automation in the process of agreeing Ledger updates. They encapsulate a programmable business process that regulates the behaviour of the Corda Nodes involved into certain operation. The RPC Endpoint provides the communication with the Corda Node through calls to remote functions thus allowing the launch of Flows, querying the Vault and so on.
In the deployed scenario, the Marketplace GUI allows enduser interactions with the Marketplace. User actions are sent to the Web Server, which exposes a RESTful interface to enable the interaction with the Corda Node and carry out the operations of the VNF Marketplace. Incoming requests on the Web Server are translated into RPC calls to the Corda node. During the management operations (registration, update and removal) of package offers the Web Server constantly interacts with the VNF Catalog in order to verify the packages involved in each operation are already onboarded.
The main operations, and consequently the Flows that implement them, made available by the CorDapp(s), and performed by Developer and Buyer towards the Repository, are described in Table I.

B. States on Ledger
The values of the States are saved on the Ledger and, consequently, in the Vault of the participants (peers) involved in the specific transaction that generated them. Below the list of the states supported by our PoC: 1) FeeAgreementState is the representation of the agreement between a Developer and the Repository on the fee that the Repository itself will hold from each sale of package offers submitted on the Marketplace by that specific Developer. We configured a 10% fee. The FeeAgreementState also defines a custom schema in the Vault used by the EstablishFeeAgreementFlow and RegisterPkgFlow operations.
2) PkgOfferState is the representation of a package offer registered in the Marketplace by a Developer. The 3) ProofOfPurchaseState is the representation of the proof of purchase of a package offer on the Marketplace.

4)
Cash is the representation of a quantity of money owned by a Node (peer) and usable for the purchase of package offers.

C. Performance Evaluation
To test the performances of the implemented Network, four Ubuntu Virtual Machines (VMs) with OpenJDK were instantiated on OpenStack, each having the following resource profile: 2 vCPU, 8GB RAM and 40GB Storage. Each VM hosts one of the four peers i.e., Repository, Developer, Buyer and Notary.
Several tests were executed to evaluate the performance of the proposed solution, considering the following metrics: 1) Throughput, i.e., to evaluate the number of transactions per second managed by the Ledger, in relation to the number of the corresponding requests (registration, update, purchase and deletion) of an offer.
2) Offer searching time, according to a fixed number of constraints compared to the number of package offers registered on the Marketplace. For the number of constraints, values of zero, one, three and five query filters were analysed. The case with a single query filter has been differentiated in the use of the linear ID and in the use of any other parameter of a package offer. This last differentiation has been reported as all package offers searches carried out in the Marketplace operations use the linear ID.
The methodology used for collecting the measurements consisted of inserting into the Ledger a first set of 256 offers that has been increased by the same number step by step up to 4096 total offers registered. Asynchronous web clients were properly developed to perform more requests at the same time against the Web Servers of Developer and Buyer. As depicted in Figure 3a, the registration of package offers has an increasing linear trend, thus demonstrating that the insertion of new offers on the Ledger is not influenced by the number of requests submitted or by the number of states already present on the Ledger. The performance of updates for package offers also shows an increasing trend, confirming the considerations made on the performance of the registration operation. The delete function has a slightly decreasing trend due to the natural increase in the time needed to search for offers as the volume of the Vault increases, this also explains why the throughput of the update operation is lower than that measured for the registration operation. The trend of the package offers purchase function has a rather constant behaviour with a value measured in the interval (1.571, 1.426).
In Figure 3b, the time required for returning the offers registered on the Marketplace has been evaluated. It can be noted a linearly increasing trend in case of no filter applied (f = 0) due to the natural growth of the Vault. On the other hand, all the other scenarios that use filters when searching offers show a constant or slightly increasing trend. The efficiency of these last operations allows to keep the search time in the Vault low and consequently have a limited impact (albeit present) on the operations previously observed.
The tests carried out shown a substantial viability of a VNF Marketplace based on the R3 Corda Blockchain Technology, with acceptable performances in terms of response time and scalability, despite the implemented Marketplace uses the Open Source version of Corda instead of a more optimized and enchanted version of Corda Enterprise.

V. CONCLUSION
The stringent performance and dynamic adaptation requirements introduced by next-generation networks imply the need to simplify the processes for procurement, deployment and management when building these networks. Motivated by this reality, this paper proposes a decentralized resource Marketplace that aims precisely to foster multi-party collaboration for on-demand service provisioning in dynamic next-generation network ecosystems. By leveraging the use of DLTs and SCs technologies, the proposed Marketplace supports trustworthy trading of distributed and heterogeneous resources across different provider domains. This was achieved by providing efficient and flexible mechanisms for crossdomain resource negotiation such as the use of distributed ledgers, unique identifiers and decentralized catalogues. To validate the suitability of the proposed mechanisms a PoC focused on the trading of VNF resources was implemented and evaluated. The observed results evidence the feasibility of a DLT-enabled Marketplace implementation in the context of real time network resource trading.