 Hi all, my name is Alah Goldner, and today I'm going to talk about file to slicing, file to slicing is a piece of cake, and we are going to discover why we can see that definitely speaking of monetization for the network service provider before file G, and before slicing came into the play. It was mostly about the service being fast, basically the bandwidth of the service, and perhaps several types of service. This is without really a differentiation of which services the satisfying SLA would be provided by the service providers to the customers, including enterprise and consumer customers. Actually the key functionality that it is bringing, it is on how the network itself in a new different way would be monetized, and we can definitely see by the survey that service providers are responding to, that the major growth is actually for the next few years, would actually be a monetization through the network slicing, by actually providing services with differentiated SLA, for customers including enterprise, including private customers, and actually differentiated payments for those types of slides and this is something which will grow as 5G deployment grows. We can see that by the survey which was implemented through a different service providers, again another survey by Ondia this time, that the major trend that they see for 5G is not just providing a different data tires for a different customer, for how much they pay, or for the bandwidth of the service that they are getting, but actually differentiated plans for different customers, and the variety of those differentiated plans. So we do not see that many already responding, that they have clear plans on how exactly they do it, but we know that innovation is really there, and those who actually plan to provide those different monetization plans will also be able to monetize 5G and not just build the network without really getting back for their investment. Just one more business slide to show you before we move to the technical aspects of the solution. And this is about changing the focus for 5G if for the timeframe of two years, we mostly see still the objective of improving system capacity, offer faster speeds to end users. For the timeframe of five next years, we really see the objective for 5G of addressing new market and services. Then we say new market speech is mostly to address and new types of customers, enterprise customers, we see there are 42% actually believing in it and changing their 5G focus. And this is where network slicing is strongly coming into the play. Here we just wanted to highlight several different types of the different services which are coming along this 5G and would be leveraging high bandwidth, low latency, mobility, mass device, actually those characteristics that 5G brings and differentiate from a previous generation. I would say that the key here is the combination of high bandwidth and low latency which goes along this gaming. Industrial automation, format device, high bandwidth, mining services, emergency service. The important point here is that each one of those categories do not necessarily require all altogether like high bandwidth, low latency, along this mass device and so on. All those are different characteristics for each one of the service. And for each of those types of the service, the objective is to build the slice, matching those service parameters. Boy, another word have slices and then put a new service on the slices that we already have or create a new slice which makes the characteristic and the requirements of service which basically would satisfy the service requirements, the SLAs of the service providers. And this way we can actually guarantee the SLA assurance within the service providers and the customer. Now, with that say, I would like to actually move to a bit more of the technical discussion on how exactly that would need to be done. So what exactly Slice Manager is? Slice Manager consists of the several parts and the definition for Slice Manager and the pieces as it builds, goes through and supported by different standardization and organization. We will talk about it a bit more specifically that process that I'm showing you right now was defined by 3GPP. So the key behind the process is the definition of life cycle of network slice and which consists of creation, modification, deletion of the network side, definition and update of the services as capabilities to the network slice. So there is a preparation phase which includes design on boarding the network environment preparation and then there is a life cycle of a network slice which is composed of creation. Then operation life cycle itself within the bigger life cycle of the network slice. The operation includes of course activation, deactivation, supervision and reporting, modification if needed. Modification comes into the play in case there are measurements or there is machine learning which identifies that something needs to be done for a slice and then scaling or healing is implemented either on the network slice level or separate network function level. Of course, the last phase is the commissioning of a slice or in another works termination. So this is the process and how 3GPP defines it. Here I am specifically talking about MDoc Slice Manager which of course is built following all those principles that I've shown on the previous picture of the different phases from which network slice is being created on boarding and actually life cycle manager being managed and in case it needs to be terminated, terminated. So it includes the solution that we build the slice design, slice automation and orchestration and slice operation and management phase and going through the different domains brand, transport and core. Now, it is very important to mention that Slice Manager in order to satisfy end-to-end service requirements need to run through a different domains brand, transport and core. Perhaps for different beams perhaps for different clouds as well. So the real solution which should be built here is to be able to get the measurements to get the real situation from all of the domain to compare it against SLA of the service and to make appropriate actions in the appropriate domain in order to keep the level of quality provided by Slice at the level which is needed by the SLA and which is needed by the service provider requirements. So horizontal integration is extremely important. Same for vertical integration because you need also to have a catalog with the slices. You need to support the ordering system. All this should be done by TVMAP APIs in the standardized way. So any slice and manager system can connect to any BSS system. Even with the charging, it also needs to be connected because there is a new charging method developed in free GPT by which Slice Manager actually reports for charging on a slice level consumption, not as a mobile session. And this is why also the integration this charging manager is needed here and all this is being supported by M.Docs Slice Manager and I'm going to talk shortly about how that exactly relates also to honor. So let me take you from the next one. Next one is actually show the lifecycle manager in a bit more details. You can see here clearly on the opposite side of the picture, the more details about the modules which compose our 5G Slice Manager on the Slice design, it's XNF and service packages onboarding, Slice and services modeling. On the Slice Automation and Orchestration it is a support of C-S-M-F, NS-S-M-F, module C-S-M-F of communication service manager function NS-S-M-F is network service management function NFV award which is defined by it's NFV, NS-S-M-Fs those are domain manager for Slice subnet meaning rent, transfer to course or C-S-M-F, NS-S-M-F being end-to-end solution actually coordinate and correlate domain manager, BNF managers of course, configuration management, common emplacement, this is the key functionality in order to understand where each location, which cloud to take a network function from for the specific Slice in order to actually satisfy the service requirements as we know for example for the low latency service the critical piece is that the distributed user plan functions runs near the user in order to maintain low latency level, policy engine of course along with the closed loop operation and then on Slice operation and management of course we have an inventory which maintains the real time view of the resources in the network, analytics machine learning and performance of manager that is needed in order to actually operate and maintain the Slice. On the downside of the picture we can actually see examples of several slides, I see using shared network functions that you can see on the core site or using the dedicated network function that you can see on the transfer site and also on the range site for instance in this particular case, UPF and SMF in one case are shared, in the other case are distributed. Now with this, I'm going to show specifically on how process of instantiation is being done. So Slice instantiation, so first of all of course, CSMF which is a communications management function this is the highest layer then the CSMF only gets a service request by its name from the upper the says layer without really knowing yet what is network characteristic of the service it get a request for instantiation of a new Slice in this example for smart factory. Now it's job is to decompose relevant enter a network Slice template retrieve configuration and placement data look for available active resources XNFs and run network Slice instantiation flow. Now the next step is XNFs resources, location, deployment and instantiation to the domain controller, free domain controller run age, transport and form. Then a dedicated 5G core functions for new network Slice allocated and deployed where dedicated are needed dedicated means that they serve only one Slice. Slice, it is typically for instance for the low latency service those residing on age and serving that Slice to get again distributed UTF in some cases even SMF close to the user. Next phase is XNFs configuration and then the last one is for the shared network functions UDM and SSF, CHF and PCF of the core they updated about new network Slice they already defined and they're going to be used in the shared mode for that same Slice. Also additional one in RF, AMF, NAF and WDF, AF and AUSF updated by UDM about the new network service that comes as the next phase of course transport configuration and then new network Slice is established and can run through, run transport and form. This is the slide number 12. I'm going to show the process of Slice operation and again, first of all the performance of full data collection PMFM are being gathered from a XNFs and infrastructure firstly in its domain then consolidated and whatever needs to be transferred is transferred to the end to end network management then performance branch notification is done in case of a need then all those performance and full data measurements are compared against the KPI in case of a breach there is an LCM action triggered in accordance with policy rules which typically includes carrying or healing up down out in of the Slice of the specific network functions by action four and then based on basic data collection, modeling, can mail analysis, the system carried out performance prediction and provides early warning. So we know about the problem in advance and can take connections in advance and not only then that event of breaching occurs. So this is the way there is, it all will not happen one day. I would say at the beginning, it will go through the system based on the statistics not necessarily based on the full AML analysis as time passes and more and more slices are being deployed in the network. We will really move to machine learning based system with the prediction where you apply your action before action any breach in the system has happened but in advance. With that said, let's move to the next plan. And I promised to show and to talk about standardization. So since this is a very hot topic there are really all of the different standardization but the end is a slicing one or another way. So if we talk about free GPP and this is probably the major one free GPP defines network slicing including use case realization and modeling for RAN and for core. And in the feed defines virtualized domain of or in another words, what Etsy NFVO should do in order to orchestrate network slicing. Etsy make of course orchestrate H platform for V-run and low latency services. The same is the organization standardization body which actually defined end-to-end network slice and how it's supposed to function across RAN, transport and core and consolidated view of assurance for the network slice and of life cycle management for the network slice. GCMF has developed a different slice profiles. MAPLISTO develops end-to-end service orchestration and APIs between domains and carriers. Specifically for the open source, the biggest walk has been done in on app on end or RAN or RAN also includes open source community in order to develop a de facto standard open source implementation for network slicing. And this is really a very, very, very important walk as we validate what actually in on app and in RAN what actually is being defined by standards in many cases by the way the category out that something has not been defined fully and then we take it back to standardization bodies. We have an ongoing relationship, it's free GPT, this Etsy is the same, this Etsy and Feeb is MAC and the only kind of, you know, we basically validate whichever they define. We provide that early implementation of whichever they define and we take it back to them in order to fix the feed system. So this is really the best possible way in which standard walks in the industry of actually validated it right away along with the definition of how that should work. Let's move and on the next slide, what I show as an example is network slice management and how it should be defined in Etsy and Feeb to show basically that, you know, as I said, all of the organization also here working together. So what you can see on the opposite side of the picture is TSMF, NSMF, NSSMF defined by free GPT communicating with NFVO and that interface is defined by Etsy and Feeb and Feeb is an orchestration defined by Etsy and Feeb and the way that whole slice and management system communicate with element management is the NF manager and whatever is exist in the system. By the way, not necessarily all of the network functions are virtual. It can be PNF, physical network function. It can be VNF, virtual network function. It can be even cloud native network functions. So the system supports, supports to supports and actually support all those types of network function and specifically on it also supports all those types of different of network functions in order to see them, to combine them into the slice to get a measurements from them and to operate them. For physical network function, of course there are some limitations in terms of auto scaling, in terms of auto healing, but whichever can be done also for PNF is being performed. This goes back a little to the definition was important to kind of show that whole definition of the network slice related management function has been defined by 3GVP because we refer to that a lot in our work. So communication service management function again is getting the communication service request like VoliTip for example, and speaking with NSMF translates actually the received requirements into a network slice related requirements and passes them to network slice management function. The network slice management function is communicated with a different domain management, also domain orchestrator and SSMF in 3GVP terminology by being called slice subnet management function. It basically splits the service network service requirements for different domain requirements and vice versa gets information from a different domain about slice operation, about slice assurance in order to be able to actually again operate and change the network slice in the end-to-end view. This is also very important slide as we talk about ONUP and we also talked about ONUP and MDoc system and I'm talking about MDoc solution for network slice and is based on ONUP or SDC or AI actually not just coming from ONUP but we co-created them in ONUP along this HNT since the very start at ONUP. So you can see on this slide definitely how widely slice management implementation is across different ONUP modules. It covers quite all of major ONUP modules as the CAI, SO, as the NC, UPS, CDS which is a relatively new module in ONUP and portal analytics entity which is the policy of entity of is about placement and homing in ONUP. So you can see here slice management on boarding, configuration and control, optimization all these is handled by different ONUP modules and quite everything is supported right now which is not that work has finished but we advancing a lot of system pieces also now in well-in-release and even as we talk really we have almost the daily discussions on the functionality of the different modules in order to support network slicing and hopefully by well-in-release it would be able to support all those different layers of slicing CSMF, NSMF, NSSMF also internal to ONUP and external provided by a vendor and then connectivity to the external NSSMF and that would basically mean that any service provider can take ONUP solution for network slice and actually deploy it. Just a few words on the POC that we ran in MDocs on actually connecting or showcasing the network slice when shenanigans is the real vendor implementation. So we had a collaboration with Mavinier for the 5G core with Stoelko for the assurance system next start for the actual service a cost service running on top of the slice and within that POC we design network slice service create, determinate the 5G core subnet with scaling in out for the core slice. The emphasis was on the core network functionality so as I said the functionality the full functionality runs across rent, transport and core and show 5G core slicing inventory that extremely important in order to see the resources of different network functions that to know in the real time on where there is a possibility to scale to heal where is the need to scale to heal and so on. So there is a road to network slicing, right? As I said previously, it all will not happen one day it is noted in one day from the system which supports a different services running over the same network. We are going to support really a virtual network provided for each type of the service and this is what slicing is about. So if we go, if we look specifically on how evolution would be done and by the way it is also important to highlight that the real advantage of the system can be implemented or can be get only when we have a 5G standalone which means a new radio along this 5G standalone core. So at the beginning of the real slicing deployment network slicing deployment, we would have capacity base perhaps service specific slices not that many of the slices I would anticipate three, four, five, six different types of slices perhaps several services is a similar characteristics running over the same slice perhaps a single one. Next step would be deploying it more at scale which is meaning more different types slices implemented in the network. Automation introduction to some level perhaps not the full ML leveraging but some automation level for scanning for healing will be there. Age computing of course because for typical 5G operation as I said, a low latency is needed and this is why this edge is coming into the play. Now as we move through I would say 2028, 2029 we would really see that coming into the big scale in terms of many, many network slices or slice instances types required in the network and the full 5G coverage would be implemented not just in some geographical places there would be a possibility to actually leverage slice but pretty much everywhere and basically all would be application driven not just for the services initially defined in catalog but really in a dynamic way when requirements for the service or for the application are coming the slice is automatically being created by the system, assured operated, assured by the system we are going there, of course the road may take a while but eventually we are heading there and in that sense, I kind of speak was from the perspective of MDEX and from the perspective of ONUP here. So also we in MDEX as I showed on the previous slice are taking our step in that direction on building our end-to-end network slice manager by ONUP requirements actually based on ONUP and when I said based on ONUP in parallel lots of work is being done actually in order to extend and enhance functionality of the network slices so whichever we are taking from there as a vendor is being enhanced all the time eventually it will be and as I said many significant steps has already been passed end-to-end systems supporting ran, transport and core across different domains, across different public and private cloud types across different wheels for PNFs, for VNFs, for CNFs support of all of those network functions for the slicing and we are getting there with that I would like to thank you and answer any questions you might have. Hello everyone, we have now taken the phone bridge live and you can ask questions of Allah via the Q and A chat we do only have about a minute or so for live questions after that you can go to a Slack channel that I will send out as a broadcast in a moment to continue the conversation. Allah there is a couple of questions already we've moved those over to the admin chat if you wanna take a look at those and respond to at least the first one. Sure, let me look into them. Chest, okay. There is NSF test in this infrastructure, in this architecture. Many vendors tell us limitation of service shown here want to deploy a site manager for each domain and then stop level. Probably the attention was to NSF MF, right? So, yes, NSF MF because NSF is a part of the core network architecture. NSF MF is the domain manager and yes, the idea here is NSF MF that NSF MF would be managing each one of the domains separately NSF MF per domain and there is NSF MF layer which is network slides management function which actually kind of coordinate and correlate those NSF MF and doing it in a closed loop operation by actually getting measurements from everyone and then providing the comments to everyone splitting it among the different domains but per each kind of the domains there would be its own NSF MF. Also, can you describe the dynamics of setting up IP? Okay, I see. And Ella, unfortunately, I'm sorry that is time for the end of our session but I have broadcasted the Slack channel. We'll move the remaining two questions that were in the Q&A chat over to the Slack channel and then you can continue the conversation via the Slack channel that was in the broadcast message. Sure, thank you very much. Thank you and thank you all for attending the session. Thank you. Bye, bye. Bye.