# On Blockchain-Based Cross-Service Communication and Resource Orchestration on Edge Clouds
## 6 Experimentation and Results  
In this section, initial evaluation results are presented, aiming to demonstrate the benefits and feasibility of our proposed approach. For the assessment, the following experimental setup has been used. A virtual machine instance of 4 vCores and 8 GB of memory running Ubuntu 18.04 was used to deploy a test Hyperledger Fabric network v1.4 with two Fabric Peers with all instantiated smart contracts. OSM v8.0.4 as the MANO component, Openstack 5.4.0 as the VIM and the developed Service Orchestrator were deployed in a Virtual Machine (VM) with the same specifications. The Service Orchestrator is developed in Python ([[https://github.com/jdimol/cs_osm_client](https://github.com/jdimol/cs_osm_client)]([https://github.com/jdimol/cs_osm_client](https://github.com/jdimol/cs_osm_client))) and the API was built using the Flask framework. The client is implemented as a python script interacting with the Blockchain and NFV layer as depicted in Figures 3 and 4. Our evaluation scenario is performed using a single EC. We evaluate our solution in terms of orchestration time overheads and resource consumption compared to known practices in the literature for cross-service communication. In terms of time overheads, OSM takes an average of 38 s to perform the cross-service orchestration (consumer slice instantiation) while all API and Blockchain interactions add an average of 2-s overhead. Thus, the interaction between the client, the Blockchain layer, the Service Orchestrator and the OSM corresponds to the 5% of the total cross-service orchestration time, which is considered insignificant for practical purposes. As far as scaling is concerned, depending on the version of Fabric and the programming language the Smart Contracts are developed, Hyperledger Fabric can perform from 194 transactions per second, up to 592 transaction per second (commit to ledger operation) for our assets size ([[https://hyperledger.github.io/caliper-benchmarks/fabric/performance/](https://hyperledger.github.io/caliper-benchmarks/fabric/performance/)]([https://hyperledger.github.io/caliper-benchmarks/fabric/performance/](https://hyperledger.github.io/caliper-benchmarks/fabric/performance/)) (accessed on 31 January 2021)), while Openstack can process up to 5 transactions per second for network creation ([[https://docs.openstack.org/developer/performance-docs/test_results/openstack_load/index.html#create-neutron-networks](https://docs.openstack.org/developer/performance-docs/test_results/openstack_load/index.html#create-neutron-networks)]([https://docs.openstack.org/developer/performance-docs/test_results/openstack_load/index.html#create-neutron-networks](https://docs.openstack.org/developer/performance-docs/test_results/openstack_load/index.html#create-neutron-networks)) (accessed on 31 January 2021)), which is the operation needed to enable CSC. Taking also into account that Openstack is one of the industries standards for Cloud, Edge and NFV infrastructures, it is evident that the service instantiation at the NFV layer is the bottleneck in terms of scaling for the establishment of CSC. Additionally, the proposed architecture focuses on the minimization of the required computing and network resources for cross-service orchestration. For example, in typical cross-slice communication solutions, an intermediary network slice is deployed to establish the communication between the provider's slice and the consumer's one [10]. In terms of resources, this solution demands extra computing and network resources, such as VCPUs,Memory and Connection Points, in the VIM, where the slices are located. Considering the simplest scenario, which requires an intermediate network slice just for traffic forwarding, a VM with a minimal Linux distribution allocates at least one VCPU and 512 MB RAM. Furthermore, the more complex requirements the CSC establishment has the more resources the intermediate slice consumes.