 Okay, you're now live. Vipin, if you want to kick it off, take it away. Thanks everyone. Thanks for joining today. And so a little bit introduction that who we are, like, so this is telecom sick, hyperledger telecom sick. We started this three years back and the focus is around the technical and business level use cases around telecom. And we have, we started this guest speaker series and today we have Francis with us. And thanks Francis, first of all, accepting our invitation and over to you. Thank you. Thank you again. Thank you a lot. And thank you a lot for the invitation. It's a great pleasure to be here presenting this work that I did with in collaboration with Lawrence Ashupani. And well, the time of making this publication that you have here in the bottom of the slide, both of us were at the CTTC, which is a research institution in Barcelona in Spain. But now only me is working at CTTC. Lawrence is now at Ericsson, but it doesn't matter. So in today's talk, I will first provide a brief motivation and production to the problem of network sharing and how blockchain can help on this. Then I will provide some details on the Oran architecture and the architectural solution, extension that we propose to deliver at blockchain in this kind of networks to enable the automation of the French sharing use case. And next I will show you some preliminary results that will be obtained. And finally, I will provide some concluding remarks and some discussion points. So to start, let me say that our thesis is that it is unclear how revenues will sustain improvements of 5G and beyond networks. And these together with the high cost associated to the radiocese network, which is typically in the order of the 70% of the total cost of the network. So this imposes the need of cutting, for cutting both cad-tex and not ex-cost, you know? In this regard, in front of this situation, we find in plan sharing a promising solution that would not only allow to share some costs among operators and among participants, but this would also lead to a new ecosystem where we would have new players that would participate and somehow revolutionize communication systems by providing fresh and specialized functions and solutions. Of course, plan sharing, is part of the benefits of plan sharing, are provided by a novel plan in 5G related to network virtualization and the openness boosted by initiative like overrun. But nevertheless, when we say that such openness at the same time leads to a kind of new economy of sharing, which entails several challenges such as security, last or reliability, you know? So to address this, to fully leverage the potential of the openness provided by frameworks like ORA, we find in blockchain a very promising tool because it provides key properties like immutability, decentralization, transparency, security as well, which are expected to provide important benefits to operators, mostly in terms of reliability and trust. Apart from that, even that with blockchain is possible to remove costly intermediaries or third parties when for instance, setting agreements, we expect that many operations can be automated and performed from the cloud, especially for management and operation of the network. And this is very useful for the use case of plan sharing that we want to target here in this publication. And this would enable the automation of procedures related to slicing provisioning, BNF allocation, SLA assurance, and payment as well. But of course, if we dig a little bit deeper, we can realize that using blockchain would lead to a kind of service paradigm where the SLA can be defined by a smart complex. And with the assistance of AI, you could also warranty that these agreements are fulfilled. So before getting into the blockchain part, let me provide some concept on the Oran architecture and framework in this slide. So basically Oran is an initiative started by the Oran Alliance, which is formed by operators and vendors in Telecom, which can be Oran, DMT, Vodafone, China Telecom, and a very long list nowadays. And the primary goal of the Oran initiative is to basically to lower the cost of the network, of network deployments, especially for the Oran segment. And to achieve this, Oran has so far proposed a set of specifications and regulations to realize an open and intelligent radio-assisted network architecture that favors multi-vendor of interoperability, meaning that an interested vendor operator can develop components and interfaces which will be open and which will collaborate openly. So the main characteristics of Oran are first of all, radio-assisted network desegregation, which is for modularization purposes and is very helpful to separate hardware from software. And with this, it is possible to use generic hardware, which is also useful to save cost and provide higher flexibility in deployment. Second important characteristic is openness, which is mainly supported by the definition of open interfaces, and which would enable the interaction of components from multiple vendors. And in essence, this would generate, as I said, a kind of new ecosystem where which can be used innovation and attract investments to the network. Even the very niche partners could join their business and play a differential part in it. And finally, we find intelligence, which is expected to be pervasive in the network thanks to the new element that they called Run Intelligent Controller and which can execute what they call ads apps and air apps. So the components defined by Oran are basically the SMO, which stands for System Management and Registration. Then we have the Oran Samplized Unit, which is in charge of higher L2 and L3 layers, the Distributed Unit, which is for scheduling and more real-time operations, lower layers, and the RIDER unit, where we're using our actual processes. Apart from that, as mentioned, there is the figure of the Run Intelligent Controller, the RIC, which is in fact split into the OCU and the OTH. So when it comes to the integration of Oran, of blockchain into Oran and networks in general, I wanted to highlight these relevant words. First of all, there is an architectural proposal that wants to integrate blockchain with Oran, but in this case, this was done for the sake of the purpose of you identification and authentication. But well, in any case, this is quite an interesting work, which is in fact being discussed to be included in Oran specification by the security code group. So this is a word that deserves quite a lot of attention because this is something that is actually happening. Second, but not directly related to Oran, we find that in the literature, there are significant efforts or significant efforts were made to use blockchain solutions for network sharing in general and future networks. And third and more close in spirit to our publication, we find a slice of blockading, which are distributed thanks to blockchain technology. In this case, brokers in the context of 3GPP networks are entities that provide some kind of demand mapping and kind of mediate to allow sharing resources among operators or other players in general. But in essence, that the broker is in charge of receiving requests for instance, using resources and process them and map these requests into specific actions in the network. In our work, in our case, we focus on the radio access network and the usage of sharing. So we device the usage of blockchain to automate the cladding of the sources in an open and decentralized manner, similar to what Prokering does, but within the Oran architecture. So an overall vision of the scenario that we consider is shown here. In this example, we have two operators, one in blue and the other in orange. And these two operators are sharing some parts of the network dynamically thanks to the adoption of Oran and the usage of blockchain in this case. So here, the Intelligent Controller of Operator 2. In this example, it detects that some resources from operator one are needed. In this case, it's to make, for instance, traffic steering or handover or even to allocate a slice to meet certain QoS criteria for this UI that we have here which is represented by a car. So at the moment that operator 2 realizes of the need of having resources from other operator, it will request them through the blockchain in this case. And following this approach, the smart contract would be generated with the agreement that could be done among the operators both service provisioning and service closure would be enforced by this smart contract. Let me say that in this particular case, we consider that the agreements among operators are done by participating in an auction. But we also consider the case where operators or providers can expose their services in a marketplace. I will explain this in a moment. So following this same example, the two operators, here we show some of the architectural blocks that would allow the kind of proposed blockchain-enabled network sharing. Basically, we have a set of orange components that I described before, but there are also some new components for the integration of blockchain into all this. The proposed elements and interfaces are shown in red, but basically there is an external blockchain system in the middle, which could be, for instance, permissioned by Perleger Fabric Blockchain to put an example, and which can be connected to a marketplace as well, where an interested player can publish or acquire services. Notice that here, the players are not limited to operators or virtual operators, but also include other types like over-the-top service providers or verticals, which could access the marketplace via service capability exposure. Okay, so to interact with the blockchain system, we basically proposed a distributed run-sharing blocker, which is this block of here, and which has several components inside. The first is the blockchain adapter, which would simply provide an interface to interact with a blockchain system. And for instance, the adapter could take some SLAs and convert them into a smart contract, written in solidity or whatever is needed by the blockchain. Apart from that, I'm directly connected to admission control. There would be an action engine, which in this case would enable or put make or unprocess the offers for acquiring or releasing a specific service in this whole architecture. And of course, using the example that I showed before, here we sketch the fact that operator two in orange is getting some part of operators one infrastructure. So now, going back to the set of mechanisms that we're using this paper to change run resources, we basically differentiated between marketplace and auction. In the marketplace case, infrastructure owners publish their services dynamically, which of course leads to lower flexibility than the action because offers are kind of discreet and may not fully adapt to dynamic needs of potential buyers. But nevertheless, as you will see now in a moment, this approach is more efficient in terms of the overhead because you don't have to support this negotiation that you have in an action. So in contrast for the action mechanism, we use, well, we use the reverse auction whereby users can basically publish a service request and then potential sellers submit bits, submit the offers to this request. It's kind of the opposite to an action, no? So with this kind of action, basically the best offer wins and the agreement is automatically done, no? Okay, so with this kind of approach, you can notice that this allows for a higher flexibility because it can adapt better to customer needs. But however, as in opposite to the marketplace, this solution entails more overhead and as you will see now, poor scalability. So here I just wanted to show a flow diagram of the action and to somehow illustrate which components are involved in it. So there is a part in the orchestration that decides to acquire a specific service at the beginning. So based on that, a request is submitted to the blockchain in the form of a smart complex. And the smart complex can be identified by the orchestration of another operator, this case the operator hearing in blue. And based on admission control, this operator will decide to participate in the action or not, depending on if it has the resources or another things, no? So provided that the action is successfully done and the operator wins the action, then the service is agreed and put into motion. So resources are allocated automatically according with this, no? And of course, when closing the service, the payment is automatically enforced thanks to this smart complex. This is basically the same, but for the marketplace. So I think there's no need to lose time with it. But now before getting into the results that we obtain, let me show a little bit the considered scenario in the med list that we have used so far. So basically we have a cellular-based random deployment with users and with sources distributed among two, four, and up to eight operators. And in this setting, we evaluate the action and the marketplace approaches enabled by in this case, generic proof-of-world-based blockchain system. So we didn't dig into specific implementations like hyperledger fabric or Ethereum or whatever. So we kept this more theoretical in this case. And well, we compare that to the legacy approach where there is no a dynamic exchange of resources, no? So for the metrics that we considered, we have considered capacity utilization, user satisfaction and efficiency in terms of the load of a base station with respect to the load that is requested to that base station given user's activity. And for user satisfaction, let me say that we use this formula that you have here which basically includes the perception of users towards the service that they obtain. In this case, this is computed in terms of the bandwidth allocated to the users. And we also consider price into the equation. And as for the blockchain, we consider delay and overhead basically. And finally, let me say that to simulate all this, we used a very simple course term implementation as we did in MATLAB. You can find all the details here because it is open. So if you are curious or you want to check this, this is nothing extraordinary, but if you want to check this and discuss about this, I'm quite open. So before the graphs, I didn't want to lose the opportunity to show you some of the tools that we developed that we use to characterize the delay of blockchain applications. In particular, we have a Q-wing model that considers both timers and faults and a Q-simulator written in C, C++, no? And again, these tools are completely open. We also present them in the papers that you have cited here. And from which you have the reference at the end of the slides. But basically, we are kind of working on this analytical simulation tools for characterizing the delay of blockchain. Okay, in any case, let's now see some of the results. First of all, we focused on the performance improvement provided by the blockchain-enabled solutions, the action and the marketplace in terms of the metrics that I mentioned before. So here we have the results in terms of capacity, satisfaction, and efficiency for each possible number of operators that we had. So basically we have two, four, and eight operators that can coexist in the same deployment. So as you can see, both action and marketplace solutions improve the legacy case in all the cases. But notice that in this case, the action is typically more efficient as we could expect and that the marketplace provides a higher capacity utilization, no? And again, this is because the offers are some kind of discreet. So the offers in the marketplace, I mean. So operators obtain typically more resources than needed, which can at the same time be used for new users that connect to the system. I think I didn't mention that at the beginning, but this is important because here we are assuming kind of open futuristic scenario where users are not specifically tied to a specific operator. So they can request temporary usage of the network to different operators dynamically. So basically we have users having short services kind of in the order of minutes and which connect to give an operator different types of the simulation. Okay, so when it comes to the blockchain overheads, here we provided a comparison of the action and the marketplace solutions for each, again, for each number of operators. And also here we consider different lobes in terms of user requests, which are denoted by the lambda parameter that appears at the top of each figure, no? On the left, we have the extra delay for validating transactions in the blockchain. In the right, we have the overhead in terms of transactions per second, but the plans are equivalent, so I will focus only on the delay. And as you can see, the delay increases a lot for the action mechanism when the number of operators and users increases. Typically the delay is okay for low lobes of users, but it scales very quickly, that's becoming an issue, no? The marketplace in contrast is far more sustainable in this sense and it allows for maintaining low delays and overhead as well, even for a high number of operators exchanging resources and users load. To conclude this part, I wanted to show an interesting use case with two operators in this first case, there's an operator owning all the resources in the network and there's another operator, potentially a virtual operator without resources. But with some users. So here we plot the temporal evolution of the service received by the users on the premises of the first operator, even for users belonging to the virtual operator. And as shown here in the legacy case, the one on the left, many users do not get resources, so capacity drops very quickly, very significantly. So a satisfaction because here we're so plot satisfaction. Nevertheless, when enabling the kind of blockchain sharing solution, we see that the results are improved quite a lot, even when the base stations are fully loaded in this case, no, because the gray points indicate that the mean PS load in this case, no. The other case is when each operator owns 50% of their resources here without sharing it is okay, but satisfaction is not that good. However, when being able to share the resources dynamically, we see significant improvements in both metrics, especially in satisfaction. And to conclude this presentation, let me say that we see in blockchain very nice opportunity for automating network management and by removing the long interactions with third parties like regulators. Such automation can bring the, to use network sources more efficiently, which at the same time can contribute to economic sustainability. Besides, we have the openness that blocks in and runs. So this, we understand that it can provide more or higher competitiveness in networks, which can lead to more investments and enhancements of the quality of telecommunication systems. For instance, by this real global connectivity could be achieved. Also the properties of blockchain technology like transparency, mutability, and so on. This lead to increasing class and reliability among network sharing players, which is quite a good news. And as for the challenge, we saw that the communication overhead can be an issue, especially for the action that we show. Likewise, let me say that the transaction confirmation latency can represent also a critical aspect, depending on the blockchain solution that you adopt. In our case, we assume the centralized mechanisms, fully decentralized mechanisms, like Provo4, which may incur into too much delay in our head basically. So typically for operators, they would prefer permissioned blockchains, which can be much faster and much more scalable. Okay, as for the stability of the blockchain in terms of consistency, this is something that I didn't show very much, but we just only depends on the type of consensus adopted. But this is something that has to be considered as well. And finally, as Partially said, scalability can become a huge problem with the kind of solutions that we considered in our analysis. So that's all from my side. I really appreciate the time and that you have me here today with you. So if you have any question that I can answer, I will be delighted. So thank you, thank you a lot. Thank you, thank you. Will have me for having this insight information on ORN and blockchain. So participants can raise their hands or they can unmute themselves and can ask questions as well. So for you, I have one question will help me, that you used a queuing model, right? So I want to understand where you are using actually this queuing model, which part? Is it on broker side or off means on RAN side, like RIG side, where exactly you are using this queuing model? Yeah, in this work in particular, we use the kind of simulation, which is a simple implementation that we did in MATLAB. So we don't use the queue model, but the queue model, we have been using this in other papers, but only to characterize the queuing delay that we have extended that you may have in proof of work blockchain system. And what kind of auction engine you use? Like I saw one auction engine thing. So if you can explain more on that side. Yes, for the auction, we considered a reverse auction. So every time we, for instance, every time an operator obtains a new user and this user needs resources from parts of the network that that operator does not have, then it will issue a request to the blockchain system in the form of a smart contract, requesting the amount of resources that it needs in terms of capacity and time, basically. When this kind of auction request is perceived by the other players, they decide to get into the game or not, depending if they have resources available or not in that part of the network. And they decide to meet a bit in this case that can be accepted or not by the host operator in this case. This is the kind of mechanism that we adopted for the auction. And we have one more question from John. He said, thanks for great presentation. Do you have any examples or use cases for network slicing and smart contracts? Yeah, in fact, they have a great one, which is reference number six, and which is the work from Nima from this loop. You have it here. And basically they provided an implementation with Hyperledger fabric of this exactly, of a broker for leasing and acquiring network slices. If I am not mistaken, I mean... Yeah, and could you share this reference like once more, like you also mentioned some working groups, right? Which is working on ORN and blockchain things. Yeah, that reference is the third one, which is called VIRAN Blockchain-Enabled Reductions Network with decentralized identity, management and privacy preserving communication. This is from some people at University of Lascaux, and they are very active in ORN study group in security. I could join some meetings because they invited me and I could see that they were proceeding with this solution as a specification, as a standard for... So it means people are considering this blockchain and ORN things and the standards as well, right? Yes, and let me say as well, because I actively participate and contribute to ITU focus groups, and particular focus group on autonomous networks. And we are working, they are interested in fact in blockchain and we are working on proof-of-concept application or using blockchain to kind of validate these X-Apps that you may have in ORN and other intelligent-based network architectures. So from this part, I know that they would be very glad and honored to get some input from this interest group in Hyperledger Fabric to provide some kind of introduction of the activities that you do and these kind of things. I'm aware that a very nice collaboration could arise from there. Yeah, even as David said that even Linux Foundation Networking and Linux Foundation Edge is also interested that ORN and Hyperledger can collaborate together. Even if you are interested, we can start something on this as a subgroup in Hyperledger Telecomsick. So yeah, we've been touched. Let's see how we can proceed further on this. For the NEMA also. Yeah, I'm sure. Please go ahead. Yeah, so NEMA is also here. So he's also working on this network slicing blockchain kind of things, right? And we have some papers on SLA and decentralized identities. So yeah, it means in any how people are working on ORN things and it means because all things have come under Linux Foundation so it's easy to collaborate between ORN team and if we can start something as a subgroup or we can write some solution brief together with ORN or in a community. So that will be really good. It would be very nice in my opinion. Yeah, so we've been touched. So we will continue on thread. That's what we are working on and let's see how I did a lot. Okay. Yeah. So I think we don't have more questions. So let me check on YouTube as well. Nothing. So thanks, thanks. Will help me. Thank you so much. Yeah. And meanwhile, thanks. Yeah, Christina is saying thanks. Okay. So thanks, thanks everyone for joining us today and will help me. We will see that how we can collaborate further in her hyperledger telecom secret group. And thanks again. Thanks for joining everyone and thank you for your presentation. Thank you. Thank you a lot for the invitation and for your time. Thank you. Yeah, the presentation is, I shared it. I think they will upload it to the web, to the wiki. Yeah, wiki, yeah, we will upload another. Fine, thank you. Thank you a lot. Goodbye.