 Okay, we're live. Hi everyone. So, so we have today, Madhu Zukan and with us with the guest speakers. So today topic is blockchain based secure and federated slice program for 5G networks. And over to you, Madhu Zukan. Okay. Thanks, we've been so thanks again for giving the opportunity to have this talk. So, so I'm Madhu Zukan. So I'm assistant professor mainly affiliated with the university college Dublin island. And also I'm working as a professor at University of all Finland. And with me, one of my PhD student Tara Keheva will be presenting today's talk and he's from the University of all. And this talk is basically based on the research work target is currently doing under the, the European project. Horizon 2020. So, so the topic is about secure, secure. We call it as a SFS broker which will be designed as a part of this horizon project. Okay, so let's go to the outline so so the outline is we will be talking discuss a little bit about why it's slicing it's important and what is the role of this slice broker in. And then we look at why blockchain is important in the network slice brokerage. And then we will discuss what is our proposed SFS broker architecture and its components. Then we'll present like how we have implemented this thing on top of the Fiji network and some experiment result to show like why this research is important. So the first half of the, like, the talk will be delivered by myself and I will hand over to the second half. Okay, so before we move into the network slicing so we have to, I think you might already know about Fiji network so the network slicing came as a part of this Fiji network. When we look at the Fiji network it is, it is a complex ecosystem like we mainly design in order to interconnect IoT devices and enable the IoT based services. So, since we are interconnecting IoT, IoT is why are the Fiji network it is going to provide services for different sectors. It can be like autonomous driving vehicles or it can be a smart parking spaces or it can be a smart city scenario or it can be a healthcare scenario or it can be power management or the smart grid case. So it's basically interconnecting everything around our world, the human society. So that's why I am saying Fiji is not just a mobile. Another mobile network it is a complex ecosystem which is interconnecting different system. When we look at like what are the applications of this Fiji network so we already identified some of the use cases with Fiji network can be used like autonomous driving drones for 4k or 8k video holographic TV augmented reality. So there are many applications which will be built on top of this Fiji network. So this Fiji application has a very diverse set of requirements and implementing this Fiji application on the Fiji network is a challenging task. So what is the challenge we found is like how we can optimize this Fiji network in order to support each and every application. When we look at different application, it has different set of requirements, the network level requirement or the security requirement or the privacy requirement. So it can be a different level of requirements we are needed in order to support each and every application. So basically how to optimize the network to provide each application is a challenge. So if we use like one network, one physical network, it's not going to fit into all of these applications. So that means we need to find a solution like how we can optimize this Fiji network to each and every application and satisfy the requirement. So on this aspect the network slicing concept came up. The main idea of the network slicing is how we can slice the physical infrastructure into multiple virtual networks. That means you have one physical infrastructure which has the network resources and you already have resources. It can be computer resources or it can be storage resources. So you have complete infrastructure with all the resources. We call it as a physical infrastructure and you can take this physical infrastructure and you can build multiple virtual network on top of this physical infrastructure. The method we are going to have this kind of virtual network is called as a network slicing. So once you slice the network into different, can you go back to previous slide? So when you slice the network into different slices, so basically you can optimize each slice in order to provide the different services which is needed. For example, you can optimize one slice in order to provide the healthcare services. You can use another slice to optimize another slice to provide another service, maybe like Internet of Things kind of scenario. So the network slicing concept is like one of the pillars of this Fiji network, how to enable the Fiji service. Then let's look at like what is this slice brokering means. So the slice brokering mechanism comes when the different users or we call them as a tenant wants to get a network slice in order to enable one of his network services. Let's say we have this hospital and he wants to create the slice in order to provide the healthcare services. What he need to do is like he can request a network slice from the one of the resource provider. So the resource providers are the mobile operators or the cloud service providers or even local mobile operators. So there are many people who can provide the resources. So the tenant can request a network slice from a network resource provider in order to enable one of its services. So in this process, so we need a person who can ensure like the network service request, the tenant will get a slice according to his service requirement. So in this point, the slice brokering mechanism is important because the network slice broker is the one who make the connection between the service request and the resources provider. So the base on the resource request coming from the tenant network slice broker can find a suitable resource provider to create the network slice in order to support this tenant service. So this network slice broker in scenario can be very complex because when you create in one particular slice, the resources can be coming from the multiple resource provider. It doesn't have to be coming from one mobile operator or one cloud service provider. So you can combine the resources from multiple resource providers and create one slice. So that is called as like a federated network slicing. So that means like you are combining different resources and create a one single slice for in order to enable the service. That is more likely to have in the more 5G use cases because you need the service from the different resources provider. And these resource providers, as I mentioned, it can be a different people. It can be a mobile network operator or even local 5G mobile operators or even the cloud service providers or different different resource providers can become a part of this ecosystem. Okay, so then let's look at like what are the why we need blockchain in this network slice broker in scenario. So I have mentioned in this network slice broker in system, there are different stakeholders are involved. And also with 5G, there will be a lot of IoT based services will be also enabled. That means the ecosystem of this in this in this network slicing domain is going to be expanded both in horizontal and vertical domain because of the different industrial application and also the scaling up of the consumer volume and also the number of operators or the resource resource providers with going to be So then how we can establish in the trust between these different stakeholders in order to enable the network slicing. It's a challenge. And the blockchain is an ideal solution to establish one of the ideal solution to establish the trust between these different stakeholders and also in the blockchain is powered up with the smart contract. So we can use smart contract to automate most of the processes which is related to the network slice broker in in few slides later you will see like how we have automated this slice broker in process using the smart contract. And then, sorry, can you go back to this slide. Yeah, so, and also another benefit is like the transformation of the 5G services from the centralized to decentralized because when we look at the 5G, architecture we can see there are a lot of decentralized services because a computing is getting popular. So you can have the AI services already at the age with mobile mobile. Computing capabilities so that's why and also 5G is consists of a lot of local 5G operators in this kind of scenario. We have to go for the decentralized architecture. So the blockchain is another tool we can decentralize this 5G architecture. And also, since we are like multiple people are involved with the slice broker in. And also the payments handling is very important like because whenever you buy a service from a provider, you have to pay for that service. So in order to enable a marketplace, a blockchain is an idea solution. We have seen a lot of lot of research work has been done how we can enable the marketplace for the network slice broker. And on top of that, we can also improve the security in this network slice broker in process. So now we are going to present like what is the solution we have proposed. So I will hand over to Tharakar so he can continue with that presentation. Okay, thank you Dr. Sankar. So I will present the content related to our recently accepted journal papers. So we have included the we have to entitle this as a surface broker secure federated slice broker. And basically, we have applied this particular application of the federated slice broker, broker mechanism through the blockchain into facilitate the factory infrastructure. So here, I think if I can briefly point the deployment or even the use case. So you can see there are multiple production sites, which will be emerge in future manufacturing ecosystems. And each of these production sites require highly individualized kind of connectivity requirements. So, for example, as Dr. Monsang has elaborated previously. So different connectivity requirements, different resource requirements, for example, the computing power, or even the storage requirements and also some other functions. And also there are different security requirements, which will be individualized or even distinguishable between each and every consumer groups. So to facilitate that we have developed this surface broker mechanism. So in this surface broker you can see we have segregated several several components in the workflow. So in the surface broker architecture, we have distinguished the several components include, which is called prime mover, which received the resource request, and also the mediator, which is computing, which is formulating the slice slice network slice to deliver for particular resource requirement. And also the security manager component, which is like validating or even defending the slice broker ecosystem from the DOS attacks. And also finally the global slice manager, which includes the business logic to invoke the resource providers according to the slice requirement. So in this use case we have basically used the game theory and the reinforcement learning in order to formulate the optimal slice for a particular resource request. And also we have used the security manager to validate and validate and filter out the legitimate resource request and also the resource provider inward messages according to security specification designed in the blockchain. So that's the overview of our work that we have recently published. And if I elaborate on the components of the particular proposed architecture, so the prime mover is the very first component which receives the consumer request from the factory, so any other tenant. So we have deployed the API, for example, the application processing interfaces to interconnect or even expose the service to the different tenant groups. So in this API we have specified what are the specifications to pass the SFS broker in order to create the slice for the future consumption. And in this resource request we can clearly distinguish two types of varieties of resource parameters. We can say that the resource demand quantities, for example, how many cloud storage they need and also how many computing power, for example, the processor core or something. Or any other let's say any other connectivity requirements or even the functional requirements. So these can be even when segregated into resource demand quantity. And also the security requirements which is most important. And these security requirements include what are the key specifications, for example, what is the bit length of the RSA or DSA keys which will be used in the message authentication. And also what are the symmetric encryption algorithms, either it is AES25A6 or even AES128 or whatever. So these security requirements and the resource demand quantities will be received by the SFS broker in order to formulate the optimal resource, in order to instantiate the particular network slice to deliver the consumer to fulfill their connect to it. To secure the slice requirements and basically the prime mover captures this particular resource request and also using the resource demand quantities and security requirements. The prime mover creates the slice blueprint and forwards this to the next component is the mediator. So in the mediator, we have included it in the paper itself. So the mediator, so the main inputs are the consumer demands and the resource availability. So based on that, the table one, which is, this is something related to the game theory based algorithm, which will be used to compute the optimal resource, optimal slice for particular resource request and these values will be computed and stored in the ledger and the mediator formulates the ideal slice, which will be a federated slice or even single resource provider slice and invokes the global slice manager component for the slicing instantiation. So we have now received the resource request from the consumers and now we have the specification through the global mediator, what are the parameters and what are the resource providers to, which can fulfill this particular resource request. And the next step is the slice instantiation. So the global slice manager receives that particular the specification or the instantiation specification from the mediator based on this game theory based algorithm. And the global slice manager invokes this particular resource provider slice managers to instantiate the federated slice. So in this use case, there can be either singles resource provider or even multiple resource providers, which will be generating the federated slices. So in this use case, this global slice manager includes the business logic or the API specification to invoke these slice managers to instantiate the network slice. So for example, if it is Katana slice manager, so this Katana slice manager's API specification has to be encoded on the global slice manager. So this is the component which integrated with the slice managers of the resource providers. And also on top of all, the security service manager is there. So security service manager is basically performing a profile based verification on the resource request received from the consumer groups as well as the resource providers. So the main idea is to defend the slice broker by the colluding or even single malicious user, which will make the slice brokering service and the infrastructure unavailable for the legitimate users. So that's the main requirement of integrating the security manager for this particular architecture. So I have just summarized the security manager's role over here. So in this security manager function summary, you can see the malicious, there are three different attacks we have identified or even defined. And in this first attack is the malicious chance explicitly send the enormous number of resource requests to flood the slice broker. So in this particular use case, in this particular attack scenario, the malicious attackers, they will deliberately send a massive number of resources. Requests to flood or even make this slice brokering service unavailable for the legitimate tenants. So we have used the profile based mechanism to limit or even restrict and filter out the only allowed or even authorized number of resources. Requests from one particular tenant per day or any other time period. So that's the key idea. So this profile information stored in the ledger itself. So since it is stored in the ledger, we assume that this cannot be forged unless it has got the full computing power of the entire blockchain network which will be on our scope. So we assume that in this, in such scenario, this specification cannot be forged or modified. So it, so whatever, whatever the specification defined on this ledger, ledger for particular resource, particular tenant will be remain as it is. And this will prevent unauthorized number of resource requests for being forwarded to the network, the slice broker. So that's how we are protecting against the malicious tenants. And also, we can see malicious tenants explicitly send enormous number of resource requests to overutilize these providing infrastructure. For example, one malicious resource, one malicious tenant can utilize all of the resource providers infrastructure. So he can ask, I need 100 GB, 100 GB and I need 1000 cost and also I need some other fully utilization requirement. So in this case, he has hold, he can hold the entire infrastructure and make the infrastructure unavailable for the legitimate type of users. So we also prevent that using the security manager. So in the security managers, we have defined as we have previously done for the number of malicious requests, number of requests within a specific time period, we have defined what is the, what is the number of maximum number of authorized virtual machines in the next storage or even authorized the CPU course for particular tenant or even any other, any other consumer. So we did clear define that and this validation has been performed at each time when the resource request has been received from the tenant. Using this methodology, we have prevented the overutilization of the resource provider through the blockchain based slice broker. So, and also the malicious resource providers deliberately send resource offers which cannot be delivered. For example, this can also be happened that the slice broker do not have, the slice broker doesn't have infrastructure of his own, but so the slice broker interacts with the resource providers on behalf of the consumer. And in this case, if the malicious resource provider claims that he has this much of storage or this much of whatever the resources. So the legitimate tenants cannot, tenants will attempt to request and instantiate this particular resource, resources or even the network slices within this resource scope. And it will not be delivered. So this also can be eliminated using the profile based specification. So this profile based specification defines what is the maximum available or what is the available, really available quantities of the resources for a particular resource provider. So that's how the security manager is functioning. So it is the, it is kind of previous pre validation of the resource request and the resource provider offers or you can just provide a messages prior processing through the SFS broker. So I will just go through the workflow. So in this workflow, you can see the 10 slides request and these 10 resource request includes these resource resource quantities as the security requirements. And this validation is also happening happened in parallel and slice request, after the verification, verified 10 resource request with security requirements will be formulated to using as a network slice blueprint. And the slice selection algorithm will be running to check the resource availability and also the security services and the slice selection will be happened. And the slice manager will be invoked to make sure that that slice has to be what slice has to be instantiated and what are the specifications of the slice and notifies the slice is ready finally. And also slice creation and offer towards the tenant. And also the most important part is that we can even facilitate the secure service level agreement and monitor, which is like defines the limitations of the and also the terms and conditions of this network slice establishment for the between the consumer and the resource provider. So, we also facilitate that according to our project deliverable what we have recently contributed as horizon 2020 in spy 5G plus project so likewise we have facilitate these three, these slice creation as well as this SLSS establishment using our SFS broker. So, if I summarize the benefits of the proposed SFS broker. So, the most important part is the improved security. So, we have performed the request validation against those tactics so what we have we have summarized or even I have defined what are the potential dose attacks or even how these dose attacks will impact to the legitimate tenants as well as the resource providers and also the slice broker. And we have used optimal slice selection mechanism using reinforcement learning and game theory and also from our results we have reflected that our work provides lower consumer prices. So, the key idea is to make the key idea is that our slice network slice is not limited to one particular resource provider. This resource our slice created from the SFS broker is a combination of combination of multiple resources provided by let's say the cheaper or even lower price lower priced resource units and it is a combination which will be eventually deliver lowest price to the consumer. So, it is beneficial for the consumer because it is not from not defined as a single commodity it is a kind of combined commodity composite commodity. So, likewise the consumer gets that benefits by these composite commodity which is combined with lower prices lower priced resources and also the workflow automation can be performed through the smart contracts. So, for example, this is important when the number of resource request is frequent and also it is when the number of tenants are being increased so manually or even semi autonomous processing of these slice broker or slice service level agreement establishment will be resource intensive and also maybe human resource intensive or even any other computational resource intensive if it is being centralized. So, if it is being processed by the cloud server and these type of barriers or hurdles have been eliminated through the integrating the smart contracts and the delivery capability of the federated slice. So, more resource provider utilization. So, as I mentioned earlier, so the slice will be a combination of multiple resource providers. So, even though they do not have capability to deliver the entire slice requirements, still they can contribute to the federated slice by the availability of whatever the resources they have already in their hand. So, that is beneficial for the resource providers they do not idle. So, they can earn as much as earn at least some at least whatever the possible possible amount within their delivery capability. And also the scalability is scalability can be achieved through the decentralization. So, as I mentioned earlier, so instead of making the service centralized, so these particular the slice broker can be decentralized. So, for example, this is important when we are considering the local 5G operator like resource providers. So, in this use case, in this scenario, for example, if a particular city consists of multiple local 5G operators operating to facilitate different services, for example, hospitals or smart city and also the vehicular networks or even manufacturing. So, to deliver the slice brokering service for this particular resource providers, there is no need to connect or even invoke the centralized slice brokering service on the country itself. So, instead we can facilitate the slice brokering to be instantiated in the city, city's local computer or even whatever local server itself and make sure that the operation is executing locally in their local node. So, likewise, so the service expansion is possible with wider capability when compared with the centralization through the decentralized integration of the surface broker or the slice broker mechanism. So, these are the key benefits we have achieved from the surface broker and also some of these achieved due to the integration of the blockchain. And also I just go through the implementation. So, in the implementation we have, this is also according to the project deliverable specification. So, we have used high pleasure fabric blockchain to encode this whatever the logic we have developed in the algorithm using the Java based smart contracts and also we have used the, we have used JavaScript SDK to instant initiate the to commit the transactions to the ledger and we have used the rest API as the integration service of the for the IoT nodes, IoT tenants and also the other services which will invoke the slice brokering service and and also and also for the infrastructure we have simulated using the open stack infrastructure using Deus stack which is the developer version of the open stack. So we have used the Deus stack to do stack instance in our local machine to simulate the resource, the actual resources provided by the Generic Resource Provider and we have used OpenMano and also the Katana Slice Manager which is more important over here. So we have integrated Katana Slice Manager with the the open stack or even Deus stack infrastructure and using the southbound interface and we have exposed the northbound interface of the Katana Slice Manager with the Global Slice Manager component of the SFS broker. So that's how we have implemented that and we have even distinguished the functionality as a different smart contracts or even though it is not as same as the Ethereum smart contracts we have we can define or even differentiate the services based on their functionality using using the function declaration and on the object creation of the SDK. So we have distinguished like these services into a smart contracts and prime mover, mediator training and also the Global Slice Manager which encodes the Slice Manager specification, business logic specification and I will just go through the test results. So we have performed experiment on that and we have gone through several important type of evaluations and also we did some comparisons with the state of art. So we have compared with the NSB chain which is which is also blockchain based Slice broker. So in the NSB chain and the Federator Slice we have what we have evaluated is the resource provider utilization So what we have identified is that the NSB chain always offers the network slice for the cheapest option. So cheapest network slice or cheapest resource provider who offers the particular network slice will be the finalized network slice offering resource provider So in this case the NSB chain utilization is always remain one as single resource provider even though the number of resources have been increased. So in contrast in contrast our Federator Slice broker. So Federator Slice broker provides utilization of multiple resource providers to within their capabilities within the limitations of the capabilities they can contribute to federate the slice. So utilizing this particular approach we have we have observed that when the number of resources being increased the slice resource provider utilization is also getting increased so that means in general so that means more resource provider when the number of resources being increased there is more opportunity to the resource providers to deliver their available resources and sell their available resources to the consumers and earn some money. So like from that we have observed that it is beneficial for the resource providers to as they can contribute to this marketplace within according to their capabilities they do not want to have to deliver the entire slice based on the consumer requirement. But they as much as they they have they can contribute and also earn money so resource provider we have indicated that our resource provider utilization is higher when compared with the NSB chain. And also we have identified the mean Federator Slice cost. So we have numerically assigned a numerical value assigned to each and every component it can never be resource resources and also the resource request. So using that we have we have simulated through programtical simulated this marketplace scenario so we can we and we have observed that main federated slice mean federated slice cost is lower when compared with the NSB chain and our private surface broker. So the key reason is that as I mentioned earlier so the federated slice is composite composition of the lower price offering resource providers resources so likewise from this approach so the surface broker delivers lower cost lower cost slice for the consumer so it is even beneficial for the consumers as well. So there is no you will let's say in contrast let's say if if one if one particular resource will has available with one particular resource provider and if such scenario is there so even though the this resource this resource provider has better pricing or not for the other resources which are available with other resource providers so the consumer has to depend on this particular resource provider so in contrast we have eliminated that that particular approach so we have if this in such scenario so the resource provider can get that particular resource resource which is available with that particular resource provider only from its and the rest of the rest of the resources he can get from the other resource providers so that's how we have achieved better price for the consumers in through the federation so that is that is why this federation is beneficial for the consumers in terms of the cost. And also we have evaluated we have compared the candidate resource provider percentages so we have defined this percentage availability of the availability of resource providers to deliver particular resource requests so we have observed that when the number of resource providers have been increased so. When the number of resource providers has been increased so yeah when the number of resource providers have been increased only the success rate of the other state of art what we have compared is been increasing so for example, if. If the number of resource providers are limited to 10 or something like the 10 or any other 10 or 50 or whatever the success rate or even the even the capability to select or the number of candidate resource providers to deliver the resources are still lower when compared with the. When compared with the state of art and our work so our work provides more wider availability of the resource providers to deliver a consumer request so that the key idea is to. Provide the consumer more more resource provider more resource provider candidate means more competitive competitive market it is beneficial for the resource providers because they can. They can sell whatever they are available resources as according to the specification and also it is beneficial for the consumer because when the market becomes competitive he has better selection and also he has more competitive pricing eventually so that's why we have focused on this particular. A particular success rate feature so what we have observed is that through the Federation we can provide more candidates candidate resource providers eligible to deliver the particular. Slice through the Federation so in this that's so it is important when the in terms of competition perspective. And also we have we have evaluated this with scaling up the number of resource providers and also we have observed this with the number of. Scale and the scaling number of resources so we have. We have observed. This this observation and. Indicated the. Indicated the results so when we can consider the limitations and future work so the key observation what we have identified is. The block mining latency is increasing the end to end latency for example we have used the block mining. We have used the the sequential workflow we have defined the sequential workflow and each and every. Output of the each and every execution step will be included in the laser and the block will be mined before execution of the next step so that's so in this in this approach we can identify the sequential steps are consistent within the business workflow and also this will be used as a kind of record which is like. Which is which proves that the which ensures the non-repudiation of the data data and also the transaction workflow so the block mining latency is kind of. Problem that we have observed and also the storage overhead so it is a common problem not only for our work so the blockchain laser is growing always when the transactions are completed so this overhead is kind of performance intensive performance. It is impact on impacting on the performance of the for computing nodes it is not it doesn't matter for the big big servers but still if we are using kind of lightweight computing nodes. We it will be a big problem so and also the privacy anonymity and unlinkability of the transaction records must be improved so we have used the public laser so this public laser includes kind of. Public transaction data so we have to ensure privacy of these particular. Transaction records and the conclusion includes that the we can conclude that the veteran into a slice broker creates the values of the future dynamic network slice procurement process and also the blockchain integration improves the performance and the transparency of the slide selection operation and also the improvement. Of the blockchain in terms of confidential and consensus process will be. Reducing the gap between the teleco teleco applications and the application of the blockchain for the network slice brokering so these things we have we have identified as future research work of us so we just want to acknowledge that. The Academy of Finland 60 flagship project which is from university of fall and SFI connection of projects so it is from university college Dublin and also use 2020. Inspire 5G plus project so we deliver we have we have defined this particular work mostly aligned to their specification to specification on our our role. So the reason I we have included the key publications what we have included so this journal paper title that's blockchain based slice broker to facilitate factory as service and also blockchain and game theory convergence for network slice brokering so it is accepted to computer magazine. And also this how does attacks can be mounted on network slice broker and can they be mitigated using blockchain so these three papers are the key publications. What we have. Published according to this particular work. Yes, I think, thank you very much for the. Participation and I think it's good if you can raise some questions and answers questions. Yeah. Yeah, thanks thanks mother son can talk and. And if, and mother son already shared all the links for his research in the chat if someone is interested in check out. Okay, and I think we have some questions in the chat so first question I'm going to take from Brett, can you define give me three algorithms vectors. The actors right. Yeah I think that you can unmute yourself if you have like more clarification on the question. So is the wall that I guess they answered the game theory it's going to be in a paper the first one that you have. So I was asking if it was vector based. Yes, so we have defined the algorithms. Yeah, so basically the resource providers and the consumers have been defined as the actors. Okay, any more questions. Yeah. Thanks a lot guys for your presentation. I just have one quick question. So this NSB agent that your benchmark your proposal against the NSB rate. So have you I mean I'm just curious to know how you are I mean read that paper and understood the algorithm and implemented that chain and compared it against yours or how did you benchmark it I just don't understand. So we have like mostly what we did was we have benchmarked against the the the the slice cost right. So we have and also the resource provider utilization in terms of the resource provider utilization we have benchmarked against SFS broker and NSB chain. So my the key idea is that NSB chain when we if you go through the pseudo code I think you can see NSB chain is always offering offering or even selecting the resource provider based on the price. For example, if particular if I will explain like that so let's say that if particular resource request is there this resource request needs some set of resources from a particular resource provider and whoever the resource provider provides the lowest price for this particular resource request will be selected from the NSB chain. I think I'm correct on the NSB chain specification. So that's how it is working in the NSB chain. But the thing is that in this case in to deliver particular resource request so only one resource provider will be selected. So let's say if this particular let's say that if in such in such case in the if the if a particular resource is available for one particular resource provider still this resource provider will be selected based on their pricing and also the availability. And other resource providers will be idle so they cannot deliver the resource they cannot deliver their services and get the get payment or any contribution to the network. So we have eliminated that using the federation concept. So in this federation concept we can if this particular resource is available within what this particular resource provider let's say resource provider a and we can create that resource from the resource provider a and the rest of resource resources we can open for competing from the competitive market for the other resource providers if they can deliver these. deliver these other resources, except this particular resource available with the resource provider A. Others can offer, others can give their offers and based on these offers, we can compute or even select the federated slice. So using that concept, so we have opened up more resource providers to utilize the resources which are available within, and we have eliminated the limitation of aligning or even adapting towards one particular resource provider in particular scenario. So that is good in terms of consumer as well as in terms of the resource provider. So they can utilize the resources what they have already in their hand regardless of the unavailability of some resources requested in the slice request. So we have computed, we have simulated in the implementation perspective, we have simulated the resource request and also resource offers from the resource provider direction and perform the computer, perform the run of the algorithm through the program. Yeah, I just want to really appreciate thanks a lot for taking your time. I think when this, this poll and all these things comes to mainstream, this IC practical, very practical use case, it's getting used. Thanks a lot guys. Any more questions? Okay, so I think no more questions. So, and I think we have no more questions on chat as well. Okay. Thanks, thanks guys. Thank you. Thank you. Okay, thank you. Thank you. Okay. Thanks. Thank you. Thank you. Thank you very nice.