O-RAN Architecture and Use Cases

everyone my name is martin ryanski and i'm the ceo and co-founder of remedylabs a spinoff of the poznan university of technology in poland and we are a research and consulting company focusing on wireless communications specifically 5g and beyond and now also currently on open run so our meeting today is on on oran architecture news cases where i'd like to touch upon several aspects of open run as per oran alliance definition first of all a few words about myself and i've been involved in 5g development since 2012 where i've been a work pocket leader for the eu funded project 5g now and later i was working as a run architecture consultant as at huawei r d office in sweden and i'm also a co-author of a book entitled from lte to lt advanced pro and 5g published by arthur house two years ago and i did my phd on radio resource management for lte and 5g and specifically on traffic steering so that's also a use case that we are going to speak about today as russell said the slides will be available in let's say 10 days um when i'm back from from my vacation also regarding the housekeeping rules um i tried to get to 45 minutes for the webinar as a typical case but i it might be a little bit longer so i i will try to get to one hour no longer than that but but i will try to to get a little bit shorter than okay so let's get down to the business um here is our outline for today we'll start with a little bit of introduction to sketch to sketch uh and put the context of where we are and then we are going to speak about the the oran itself what it is and what are the different let's say entities and uh also practicalities in terms of who is working on that it will be a short overview but but it will be there um and then we'll get into let's say the meet meaning the oran architecture where we are going to discuss the let's say the blocks and the interfaces in between them and their roles and then we also going to speak about some deployment scenarios and implementation aspects here the later section is about run intelligent controller or rig that is the the heart let's say of the system in terms of the radio resource management then we are going to speak about the oran use cases um that the oran alliance specifies and then we are going let's say a little bit deep dive into the traffic steering use case and in that case i'm going to discuss the the things that are related to the oran alliance description of that use case and the practicalities and the different operation within the non-real-time rig and near real-time rig the different messaging and the different parameters and of course the policies that is let's say the important part of the the oran alliance definition for the interaction between those and then as a final point we are going to see also um some let's say a toy scenario that we did in remedylabs discussing the x up interactions um to realize that specific use case so we are going from let's say the big overview then going down to the details and then also see some practical example to show what why do we think that the oran alliance definition and the aura as such an open run is is important so that would be the outline so let me now start with a little bit of a background to set up the scene and let's start with a little bit of introduction um we are in the 5g area i'm not going to go into the details of the 5g as such but it is in the context of 5g so i would say this is the overview picture and what we are going to focus right now in this particular webinar this session is the iran meaning the the base stations that are controlled um with with some external applications and and and the way it is approached within or an alliance and this openness in in the run architecture uh so we are going to see also a little bit of m2 and three interfaces to the control plane and user plane of 5g core but we are going to focus on ng-run as such of course within as you will see within open run there is also it's also defined for the 4g or lt base station so we are going also to see that block but anyway it's a part as well as of the ngram so now when we are focusing getting into the open run what's currently happening so as you might already have known regarding the basics of openrun we are going from the traditional telco approach where we have iran being the black box and and all the interfaces within that are closed and subject to uh being um in the hand of of one vendor onto the open run where firstly we are splitting the different functions and they can could be developed or deployed by different vendors like ceo or central unit d distributed you need are you remote you need we are going to see that uh over and over throughout this uh this session and the important part of that is the orange box here or the run intelligent controller being something extracted from the run and towards openness in terms of the management of the network being that radio resource management or self-organizing networks functions that are basically responsible for managing radio resources and the operation of the network this is where the ai and the whole things related to automation of the radio network comes into play so why are we going into that direction um those are the promises of open run basically this aggregation um we are disaggregating the functions of the different parts of the system open ecosystem because we will have different actors like cudu vendors but also rig vendors but also x up developers as you will see this is basically the concept where where the new players come into the open interfaces basically mean that there will it will be possible to to have an open the truly open interfaces to to allow having those in interoperability between different vendors the coupling hardware from software so all of that as you will also see can be virtualized of course beyond the the real hardware that needs to be there being the the actual um rf generators and intelligent management this is what comes into play with the run intelligent controller that is as you will see then split into two different elements um now you don't have to worry about all of the abbreviations russell has already sent you within an email there is a lot of them and um that's just to show you that there are there and there will be in the in the presentation but basically it's um it's from one side we are used to that within the telco domain on the other hand the run the open run and open run alliance and all that nomenclature is pretty new so that might be useful for you as well and with that i would like to get into the uh auran itself or open run uh oran with the dash is defined by oran alliance we are going to see also those different actors later on so how are we approaching that what are the different elements um this is pretty much a simplified protocol stack for the radio interface between the base station and the user where we have the lower layer processing than for example a scheduler and a mac layer then we have layer two protocols like radio link control and then packet data convergence protocol treating the whole packets and then at the end we have radio resource control controlling all of the different parameters and controlling the radio con condition the radio connection with a particular user on the other hand in the lower part we have the user plane the processing of the packets with the sdap being the new protocol developed for um for 5g new radio now basically the first important part is that we are splitting the the control processing from the user plane processing um already here now if we are getting into the open run as such um those are the entities defined by oran alliance they are called the e2 nodes all of them are e2 nodes and we will see how that could be also defined in a flexible way so that we can have e2 nodes shared as a different let's say combination of those but basically they have the o meaning they are defined or aligned with the oran alliance specifications we within free gpp we also have du we have also a cu being the central unit and we have also cocp and cup being control plane and user plane the important part of that is that of course that needs to comply with free gpp specification but the o added to this uh is there so that we can comply with foreign alliance specifications specifically that they allow and have the functionalities needed by oran alliance we are going to see what exactly they are then they are also connected to the 5g core so amf and upf and as you can see this is the user plane split and control plane uh user plane control plane split so they are connected to the core network but we are not going to touch this part too much in this webinar what is important is that we have those entities defined within oran alliance with the split lower layer split within the physical layer where some part is done at the radio unit and the other part at the distributed unit now getting further and more importantly to the functions of open run and the already mentioned radio intelligent controller is it is split onto two parts one is near the so-called near real-time run intelligent controller and the other one is non-real-time run intelligent controller we're going to also discuss those differences later on but the important part is that they basically or oran defines those two entities and defines interfaces of those towards the e2 nodes so that this is the the o coming up here so in order to be compliant with the orange specifications or the du to be compliant with that it needs to support the e2 interface and the whole let's say procedural aspects related to that and if we are speaking about the automation and radio resource management we have the higher layer one the non-real-time rig being let's say a self-organizing network function alike we are going to see the details of that but basically it's something like that it's it's longer parameter exchange or reshaping of the of the let's say changing the parameters for the radio network whereas the near real-time run intelligent controller is dealing with radio resource management but those slower functions like traffic steering like interference management like mobility management like spectrum management and things like that whereas of course we have a real-time radio source management it doesn't disappear and it's not controlled by the rig it's still in the mac domain so the real time processing and the real-time resource allocation is still there and it's it's within the um odu so we have a real-time control loop for automation of the radio resources assignment near real time and non-real-time rig throughout that webinar we will be using the small n with rt versus the big n or large n or capital n with a non-real time to just differentiate between those two because they are com called rig but it's split into two different functions now let's take a look a little bit closer to those entities and getting the full picture we already spoke about the blue things here and we spoke about those orange things here but there is more to that so the entities defined within auran also include all cloud so basically the cloud computing platform comprising um the nodes to host the oran functions the blue ones and also the bricks um as well as supporting functions basically the cloud platform and then we have the logical nodes hosting different layers as already mentioned in the previous in the previous picture like a lower layer physical a lower physical layer than higher physical layer and then radio link control mac and so on so forth and then the central unit split into user plane and control plane um now near real-time rig and non-real-time rig are also logical nodes one enabling the actual near real-time control and optimization of the run via fine-grained data collection so it's getting the the data and then performs processing and then controls the the the actual data processing within the the base station um and the non-real-time rig that includes aiml workflows and policy-based guidance or applications so it's basically setting up the the policies towards the near real time rig we're going to see that at the end how exactly does that mean what is an actual policy and how that impacts the operation itself so stay um till the end of the webinar it will be it will getting clearer what that exactly mean now within near real-time rig there is an important part called an x-app or an x-ups which means a set of applications that are designed to run on non or near real-time rig they basically are independent of the near real-time rick and they might be provided by third-party so near real-time rig provider but also can be coming from different vendors specifying and focusing on specific aspects like for example interference management or mobility management for different use cases and finally we have the thing called smo so service management and orchestration being a system supporting the orchestration of the whole thing below it includes also non-real-time rig to control the near real-time rig but it also is responsible for let's say setting up the things below and we are going to see those different interfaces and the messages and the things that are relating to to the exchange between those different entities so those are the building blocks of open run from the oren alliance specifications now we already mentioned oren we already mentioned 3gbp but who are other entities that are relevant here and what are the different relations between them so first of all we have free gpp already mentioned that defines the standard so the architecture for 5g and the radio interface and the operation of the radio network or network and so on and so forth within our context of the radio access network run we have the mono being management orchestration also c o c p c u u p already mentioned and discussed the d u so distributed unit and the interfaces e 1 f 1 c f 1 u we are going to see them also when we get to the the architecture point the important thing is that those are identified within the oran alliance specifications and definitions um and then we have the the famous oran alliance um and of course if we are getting from free gpp standards to the rnln specifications some of that getting into but also other features like core network user equipment and other things that are not strictly related to run so of course that relation is not one to one whereas oran alliance specifies the entities that we already mentioned so smo non-real-time rig near real-time league and the interfaces that we're going to see so a1 e2 open front hole and also the way the du is split into du and remote radio unit or the remote or radio unit within that file layer that already was already mentioned and then important also player in that area is the onf so open networking foundation whereas we have the sd-run projects they have established the sdram project um so software defined run and again the oren alliance specifications are input to the onf sd-run but not all of them are taken into account the um inf as the iran is focusing on building the the exemplar platform for uh orange based design choices and this is called micronus rig so they are focusing on building an open source rig and below they will be using the for example oran specified emulators to to basically allow x-app developers to test their solutions and allow also operators to test the different x-apps for the same purpose we're going to see that a little bit later on and then one important player in that field also is a telecom infra project or a tip and specifically within the area of our run domain and even more specifically within the area of radar resource management there is a run intelligent and automation subgroup that is aiming to use that micronos rig to develop and deploy ai-based excepts for run use cases like self-organizing networks radius of management and so on so summing up from one left side we have the reference design the architecture and the interfaces and nodes um there is an exemplar platform and there is a use case development where the operators are setting up for example priorities and having the possibility to to set the scene and having an environment to test those different solutions of course there are more and there are more will be happening for example oran policy coalition to promote those policies within the governments and standardization bodies to adopt the oran concept and um also other entities like cloud platform providers for interoperability testing x app stores and things like that similar to what we have like um [Music] google play or app store with x app store where the different entities and the software vendors will be able to provide those x apps for let's say choosing by the operator to to run in specific rigs so that would be let's say one of the perspectives related to the different entities now we are focusing in that uh particular webinar or an alliance so there are two more things i would like to mention here one is oran alliance virtual exhibition encourage you to go there where you can find a different demonstrations videos from the solutions from different vendors and use cases um they are also hosting the oran open summit it was like two days ago where where they basically we're discussing or showing to the public what are the plans for the next developments within that also there is the so-called auran software community or osc being the collaboration between oran alliance and linux foundation to support the creation of run software in terms of or in a way that it's open um currently available software that you can download from the oran software community web page is so called share release from december 2020 but they are also planning uh the next the d release somewhere in the middle of 2021 so what kind of products do they have within that you can download the whole software it's um it's there you can download and check what's inside and also try to run it on your on your platform they are developing pretty much all the different entities that were mentioned within the oren architecture so odu high odu low then central unit so reference implementation of the specific protocols and entities and interfaces between them the near real-time rig of course a platform to support x-apps the non-real-time rig to support the setting up the policies and the interface of a1 and then um some open source sample x ups and so basically you can have a hello world x up to be run on non-real-time rig where you can check out how it works and what are the different communication between the different entities and then the smo on top of that there are also let's say across layer projects like simulation integration and testing and infrastructure elements so that you can combine the whole or an architecture let's say yourself if you're interested into the details i encourage you to go to the oran alliance white paper to get a sketch and then to the specific specification based on which some part of this material has been prepared also the the cherry release of the software on the other hand the onf presentation on the sd-run and white paper as well as joining those so those are the the resources recommended to get into the specifics of um of the open run and omf also is working very closely with the oren alliance now those are the selected oran alliance specifications i'm not going to go into the details of that don't worry it's just to show you the uh the naming of them and then what are the different contents from those specifications the materials in this webinar has been prepared so we took a little bit from here and there to make sure that we basically provide let's say right nomenclature and the right let's say places and the functions that are defined by by open run alliance so that would be it regarding the introduction to oren and now um we're getting to part number two where we are going to discuss a little bit more details in the architecture and then in the in the rig okay so that's a big picture of auran architecture we already discussed the cu du and so on and near real-time rig x apps and all cloud small done real-time rig so we're not going to repeat that the important thing is that the the blue ones are defined by free gpp with um an input from uh or an alliance or they are built around the or an alliance to support those different uh as well as the interfaces like e1 f1 and of course the ng towards the core network of 5g and also oe node b being the let's say the lte version that is also supported by oran and then the orange ones relate to what is specified by or an alliance now in terms of the interfaces if you are speaking about a1 interface so from non-real-time rig to near real-time rig we have policy enrichment in for ml so machine learning model management and policy setting towards near real-time rig and from the other hand the near real-time rig exchange with the non-real-time rig the policy feedback so how that policy that you my dear non-real-time rig provided works in in the network now e2 is the important interface because it actually touches and gets into the specific entities within the base station so from one side we can control what is happening within that base station so from near real-time rig monitors suspend override control via policies towards the the lower layers or towards the actual entities that execute functions and from the other hand we get the data collection and feedback from those entities now we have the f cups and interfaces so the orchestra the typical orchestration functions like configuration reconfiguration registration security and then performance of the actual entities like the the the hardware of mutual functions and that's o1 interface you can see that it's getting to each of that entity here except to the oru because o1 is ffs so far far the study for remote unit or radio you need but they have the open front hall and plane so management plane for that as well being pretty much doing the same things for the for the for the lower layer of physical and then o2 interface pretty much same uh so f cups and and platform resources management for the underlying um cloud computing platform now what is important to mention here also mentioned before are the control loops so the first control loop the the real-time control loop below 10 milliseconds is the actual scheduler that is inside the odu and that is not subject to what the or an alliance is specifying or can it can control that via policies we are going to see that exactly in our example at the end but it's pretty much doing their thing inside the otu so it's not open then we have near real time meaning near real time in terms of timing is more than 10 millisecond and less than one second and here we have functions like interference management so setting up the different resource blocks to be allocated or the number of resources for specific let's say slice or specific user type or things like that or the traffic steering mobility management saying basically which user should hand over from what cell to other cell or to change the sell or add a cell or add a new node to to the resource pool and then finally we have non-real-time functions uh like already mentioned self-organizing networks uh like mobility load balancing or pretty much mobility load balancing can get into neural temperature as well but things like um orchestration or controlling the lower layer functions um or the new real-time leak via policies and what are those policies how we can use them it will be um in the in the next section so as you can see we have the let's say e2 nodes the the blue ones then near real-time rig with x-ups and then non-real-time rig with smo together with the all cloud now how that can be deployed do we have to have all of those different entities separated do we have to have different oculoup and so on so forth so from one side the implementation option is that they are desegregated so we have all those different entities and then near real-time rig and then non-real-time rig and smo have to have connection to those via o1 interface and e2 interface to each of that node but we can also do differently so we can aggregate them in different ways so for example we can have an e2 node that corres basically it consists of odu all cu cpu p and then we only have one e2 interface so there is a flexibility there but the price to prepaid for that implementation is that you have to have of course um the way to identify the internal node that you want to control what i mean by that will be shown in a second now what we can aggregate that in a different way so there are only selected ones from the orange specifications like we can also combine the central unit with near real-time rig and then we might have all nodes integrated so we only have a1 interface from the external entity and then near real-time rig can be also built together with the actual base station device so we also can have a distributed implementation as we had in lte case all right so let's now get to the near real-time rig this is where we are focusing on this webinar and this is where the use cases then will be discussed so the internal architecture now let's zoom in to the near real-time rig and see what are the some of the specifics within that so of course we need to have the a1 termination and e2 termination towards the let's say northbound and southbound and then internally accept x apps of course we need to handle them in such as certain way so we have a so-called shared data layer together with the database where we have read write of the radio access network so the e2 nodes information as well as from the ue side um we also have x-app subscription management so that we might have different x-apps we put one of them and then it need to be identified somehow and then there need to be some interaction between them and set up and then we have for that purpose we have the message interaction between the internal functions um so we have let's say a bus where we can let's say provide for example the different parameters to the same x up or to the other entities within the near real time rig um and then we might we need to have some kind of conflict mitigation to resolve some overlapping requests so for example we have one x up being the mobility load balancing and another one the pretty well known thing from from the past and mobility robustness optimization or traffic steering in that way what it they all have the same impact on the actual user and the network so they basically say please move that user from that cell to that cell but they might do that for different reasons for example mobility load balancing might do that because um there is an overload in that cell so we want to move that user to another cell to offload some traffic whereas in the same time the other x up i don't know the mobility robustness optimization can say well there is a lot of handovers that have failed on that area so we might switch the boundary so that the same user that's just moved from that cell to that cell moves back and then we will have a ping pong if we don't have the config mitigation function that basically tries to look what is happening in the network what are the potential action to be taken down there in the e2 nodes and then tries to align them somehow and then there are supporting functions like f cups for the x apps and the internal aspects and security schemes for for the x up so that would be basically the internal architecture of the near real-time rig now how we can deploy that we already saw a little bit of that in the previous section but there might be different implementation options so for example we might have a centralized near real-time rig where the whole genode b or e node b or several genotys or several cocps and dus are handled by the same near real-time rig so we basically get all the measurements from all the neighboring cells and all the neighboring users have been in a certain area to a single near real-time rig basically it means that we collect all the data and then have a can have a single action to be taken having a holistic view or we might have a distributed new real-time rig where each function each e2 node can be controlled by its own near real-time rig basically it means that we might have a specific near real-time rigs for each of the e2 nodes that are handled or composed within um one near real-time rig entity but with separate functions or separate neural time rigs internally now so what is important here is that the oren alliance specifications allows us to have that flexibility we might combine the different entities together split them apart have a centralized view or have a specific aspect here so that that is um of course an advantage the disadvantage of that is that we need to have that implemented or having the possibility to have that implemented in the e2 um interface that is responsible for providing measurements and controlling certain functions we need to know which actual e2 note are we talking to so that one of the thing that will be then propagated in the in the next section um of our webinar is the key performance measurement function that needs to be in each of the e2 node now in that case we have new real-time rig that has three different e2 nodes each of them is different so we have e c o c p c o u p and d they are on a different let's say logical entities and each of them need to have that function so key performance measurement function and this is actually that is a free gpp defined du with key performance measurement function as an example giving it the o inside the name and that example might be that it goes over e2 interface providing the audio message like a number of available prbs number of used prbs number of users handled and so on so forth and then of course the integrated or encapsulated transparent container for other measurements and let's take a look and as an example of that so odu measurement within the 5g let's say standalone architecture we have the performance measurement container where we might have well we have a single e2 interface it might be include all of the different entities or a single one so we have audio performance measurement container ocucp performance container and up performance container but we are looking into specific odu as in the previous example what is inside here now here they will be different because they treat or they relate to different aspects of that connection so for example odu as you remember it has inside scheduler so it deals with physical resource blocks so what do we have here we have the cells that it covers it we have the number of prbs 273 that's the number from the three gbp specifications related to the bandwidth and how we distribute that bandwidth and then we have odo measurement format for 5gc or for epc so for standalone version of 5g and non-standalone version uh where the the gnode b is connected to the evolve packet core now if we are focusing as in the previous picture on the odu for 5gc we might see again encapsulated thing where we have for example slice id or qi so 5g quality of service indicator that will be different if we have epc connected so so in that way we are encapsulating certain deployment depending on um or having the specifics in a bigger entity so from a general pm container we get to the open container and then we get to the one that is related to specific deployment of 5g and in such a way we are handling those different elements so we will get into those specific parameters later on in the in the use case discussion so keep them in mind all right but before we get into specific uh use case auran has specified a set of use cases with phase one and split into phase one and phase two most likely due to the some kind of prioritization and most likely by the operators so what operators are let's say putting or pushing for certain use cases they are mentioned here and they are all discussed in the oran alliance white paper so i'm not going to discuss all of them just focus on the different let's say aspects of those so we have for example low cost run white box hardware or traffic steering that we are going to focus or quality of experience optimization or massive mimo or quality of service based resource allocation and then in phase two we have run sharing or slicing or basically a handover or mobility management for different use cases like v2x or or for drones so we can see that they are both either specific for v2x for example for uh unmanned uh aerial vehicles or very general like traffic steering because it might be for different use cases or slices treated let's say with the different options of how we control that what we are going to focus right now is the traffic steering scheme so let's start with what actually traffic steering is um traffic steering basically is how to steer the traffic and in the mobile network's case it means basically what connection or to what cell the or to what base station the user is connected uh and it might be more general so if we have multiple radio access technologies like for 4g 5g wi-fi and others so we need to decide which which radio access technology then to which cell and then for example which band and in that band we might have multiple component carriers so which component carriers and of course we have dual connectivity and so it might be a decision that we need to have that primary base station and secondary base station connected for that user and then of course traffic so it might be traffic type like voice connection versus mbb connection uh it might be they might be treated by different uh cells so why are we handling that what's the problem here so the typical traffic steering mechanisms treat all the use in the same way and we take the average values um and they are typically limited to cellular selection or handover parameters basically whereas the boundary of the base station and then based on that of the cell and then based on that when the user moves it is just handed over to another cell but if they don't they they don't take into account that this is a v2x user and it might not need to be switched to another cell and it need to be treated in a different way and this is specifically a challenge within 5g where we have slicing where we have lte with the 5g when we have standalone non-standalone version heterogeneous networks different types of cells and thousands of different frequency bands so traffic steering is a very important use case has also been treated by onf and it's also been treated by oran alliance uh within those uh example x ups so what what do we want to have so what what's the purpose of that particular use case is that we want to have a customization possibility firstly from the operator's perspective so each operator might have different strategy for a specific type of user and secondly depending on type of the service or i don't know um having a different slice assigned to a different user we might treat them in a different way so different use cases might have different ways we treat them so we want to have the possibility to allow flexibly or configure the different optimization policies um and we might leverage ml to enable intelligent traffic steering control so what is specified um to what are the potential required data that we would like to have to to take that particular decision so for example the typical one that are used in the all typical traffic seeing mechanisms rsrp rsrq all the measurements that we typically have then from the other hand we have connection mobility handover statistics cell load statistics and ue performance statistics so if you gather them all we have a lot of data from a different sources treating or saying a different things that then collectively can be used to have a specific user having a specific um let's say treatment and specific behavior um that has its own unique um allocation now what what is their realization first of all we need to have those two entities like non-real-time rig and the near real-time rig where through for example learning we can learn that this is i don't know a street the users are moving here and if they are a car and have specific slice type they might be moving and then they might be treated one way and the learning mechanism can basically say to the x up controlling the handover that it does that in a certain way for one type of user and does it in a different way for another user so let us now look into the specific node responsibilities within the oran alliance application or handling of that use case and that architecture that we already mentioned so from top the smo or rather the non-real-time rig defines and updates the policies to guide the behavior of the tsx up that is sitting down in the near real-time rig performs of course the uh the statistical analysis of the data and provides policies and enrichment and information like rf fingerprints that are basically then seen and collected also separately now then we have so so from that part where we are basically learning and then setting up some policies over a1 we are sending the a1 policy so declarative or non-declarative declarative policy to enable that implementation within the near real-time rig and additional information for example that um rf fingerprints saying for example if the user is in that particular place and if their its measurements are like that that that and that then that would be a specific policy so that um the x up in the near real-time rig can interpret and enforce that policy for a specific user it might be a little bit difficult to understand right now but we are going to look in a specific example uh in a second so we are going to look into how exactly that might work and over e2 interface after the decision that for example that user needs to move from that cell to that cell is going over e2 interface via the control messages and e2 nodes are the ones that are collecting the data and then executing certain actions now so let's get down to specifics now what are the ts policies that the non-real-time rick can sense to near real-time rig well that's a traffic steering policy example from directly from the oran specifications of a1 application protocol where what we might find here is that yeah we might do it per ue per slice id so for specific type of slice or for specific quality of service id so for specific service or we might do it for a certain cell id so so it it is flexible we might do that differently for different cells and then on the other hand we might have um for a specific cell that and for specific user or a group of user saying that that user shall use or that service shall use that cell or should avoid that different cell or should be forbidden for that user that it should not reuse or should not be moved to that cell and this is kind of let's say um a description that you firstly might easily understand what is happening here and you might control that based on some measurement later on so the example the particular example here uh for example we have a ueid 855 and then we have tsp which is traffic steering policy cell id at least 39 and 40 so exact cell id and the preference for that particular ue is preferred or for 81 and 223 it's forbidden and so on and so forth so it might be slightly uh that we actually tell that that ue should not be moved to that cell it's forbidden for him it should only use the cells that are mentioned directly here based on some measurements and so on now even more specific example so assume we have a scenario it's also taken from the from the oren specification where you have a ue or several ues and we have a macro base station that controls two different cells so a and cell b they are on low bands so let's say 800 megahertz 700 megahertz they have 20 megahertz bands or 10 megahertz bands on narrowband and allow low latency on the other hand we have high speed cells or i know high speed but with wider bands um but on higher frequency there is a lot of resources and we can very fastly transmit to ue the data that it needs now so those are typically treated as mbb cells we want to transmit certain data and then it needs to be a huge pipe of data to be able to transmit whereas for voice calls we would rather not have hand over every uh 10 meters but we would rather have a single larger base station a lot very little resources but the user is having a good reliable connection here and also for control plane we would rather have a macro cell and then small cell as an additional resources to to handle our mbb connection so that is a specific uv configuration it belongs to the slice id one it has two connections voice connection which is defined by three gpp in five qi one and nine for mbp connection and it basically enters that area of those four cells so now how it exactly works in if we take into account the the the oran scenario so on top of the everything non-real-time rig the slower thing understands the requirements and characteristics of that services and it decides that well we have voice connection and control plane connection so we put it in low band either by measurements or by machine learning or by operator setting it needs to be covered by let's say the b cell it's it's the largest cell and that will be a p cell so primary cell so the one that is the user is connected while mbb connection we preferably go to higher frequency bands covered by small cell c or d whatever it doesn't matter the this is preferable cells and because of its consuming a lot of resources we would rather avoid um low bands this is then sent to near real-time rig so since policies for different services and so on we are going to see that and for all of the cells of concern so what happens here to achieve that behavior that we before uh seen we need to have two policies sent from non-real time right to near real time rig so firstly we are steering voice services to be served by cell b basically saying um for slice ad1 cosid1 we are setting the cell b with preference shall and that's a primer cell whereas um we might have um for the for the voice also cell b and it's not primary so it might be secondary cell whereas for policy 2 for mbb uh it's again ue one slice id1 quality of service 89 in that case it should avoid cell b and a because it would consume a lot of resources and it should prefer cell c and d basically being allocated the resources where they are and then non-real-time rig needs to locate that ue and enforce that policy and actually tell the aoe to do that so what's happening later basically the control message for that ue says please hand over to cell p for a p cell and add um cell a for voice so it's handled here and then adds a secondary cell for the second service so now the ending the end story is that the ue has connection to two base stations and having service being transmitted to it from different cells that are uh treated for that specific service all right so that's uh let's say uh from the standard now what we have done is we have implemented similar scenario and try to enforce uh certain policies via x ups that we developed so that scenario is as follows again we have a base station with two frequency bands and then we have some small cells around um [Music] when we have two types of users the voice ue mmb we so a gray one and a black one they are distributed randomly on that area and then we would like to check what are the different policies have what different policies might have impact on that particular um that particular cell or that particular let's say network so the architecture is as follows we have a macro site having two cells and then a lot of small cells with again each of them has two cells on the two different frequencies and then on top of that we have freak that is controlling all of them at once so that's a centralized one and then we have the actual cell allocation or cell association x up as we call it and it's an actual traffic steering so it steers the traffic to specific cell which means it's basically having connection to all of them and and distributing users accordingly so now how it operates is very simple um it basically measures the the the signal from each of the base station and if the policy is default it allocates the one that is closer or the strongest signal but we might treat them specifically if it's a voice user we move it to the macro side if it's an mbb user it's close enough we move it to the small cell so it's pretty simple in terms of concept now the api looks as follows we have certain parameters input parameters like the measurements and then aoe class association policy um and then we have certain policies for example um like a default policy which we actually don't have any preference for type of cell another is offload so we have a preference for example for the voice ue to avoid pico cells and um mbb ues to prefer pico cells and so on and so forth exactly the ones that we saw in the specifications and we might have two different vendors that have that are allocating different weights to those preferences so there is another degree of freedom and by that we can basically have the same preference like avoid but it has a different meaning so now how it exactly works so if we have a policy default basically meaning if you are close to a base station it doesn't matter what types of cell is it we basically allocate you so we have voice use on the left hand side and then these are the basically areas that the users are connected when they are voice users so you might see that the mbb users voice users pretty much treated the same way independently or where with which type of the cell it is and which type of the service is it basically they are allocated the same cells if it's a voice user and it's here and also uh connected to that genome b if it's um mbb user it's also connected here but if we apply policy offload which is just sending from the non-real-time rig to near-real-time rig we already have the difference so mbbuis are rather moved and forced towards the g node b's uh whereas the voice users pretty much are moved to the macro site so we are separating those types of users now how does that look in the performance perspective um here we have that topology so four small cells one macro site and the users here we can see that those are connected to the small cells that's bit rates and that's the target performance what we can see is if it's default basically we just don't care what type of user is it we might have a very strong outage for the mbpu is because they need to consume a lot of resources and they are all connected to the macrobase station whereas if we apply that policy offload what that means is that we basically decrease that outage by half because we force some users to move there and it doesn't actually matter here that actual performance what is important here is that by just sending a certain policy and having that same algorithm we might have a different operations what is important here also to see is that there is still outage now if we have those different policies this is the default one the offloading one and then separating one we might go towards having less and less outage of that user but what is more important is that if we add another x ups doing slightly different things that's one more result in a time domain so what happens here is that we have a situation where we have certain requirements we have certain outage and then 10 of the ues change service from voice to mbb and then over time it seems that the outage is getting bigger so after some time the policy is changing from let's say a learning mechanism in non-real-time rig it says oops we have now a little bit let's say higher outage it increases over a certain threshold so it changes the policy and then we are getting towards less outage and it's even less than before so in that way we are trying to do that over time so we are looking on the performance measurement we are getting higher than changing the policy over a2 in a1 interface and then moving some of the users out and even if we do not explicitly say please use the offload mechanism it will do that automatically now what if we add more except that that's the the let's say the final part i don't want to to extend the timing uh too much anymore but so let's say that's our situation right now we have a cell association x up that actual traffic steering but in the same case for the same use case we might add some more x ups for example spectrum management x up explained in a second and we can add resource allocation x up so there are separate x ups doing different things but they are all related to that specific use case and by stealing specific policies we might have a different meaning here so the smx are basically what it means is it basically prefers that frequency or that frequency um based on i don't know some kind of uh pricing for example the the lower band is this higher price than the the upper bound and so on then the ca x up we already mentioned so we have certain allocation now we might change that allocation based on some priority and then resource allocation x apps are basically controlling the behavior of the scheduler so we already have the users allocated to certain cell and to certain frequency and then we might have a different bandwidth allocated so if we have voice users in small cell they are allocated less resources than the mpp user so we are basically forcing the mbb user to have higher bandwidth if it's in the in a small cell so spectrum management band it's basically having either we are focusing on cheap bands we want to go to higher frequency if possible or performance we don't care about if it's cheap or not meaning that the lower frequency like 800 megahertz is higher cost we only care about the performance itself and the other x up that we added is resource allocation x up basically controlling the scheduler for example it prefers macro sites we add we give more resources to that cell if the user is mbb and if it's in that cell it gets less or more resources so we can control the number of resources not the actual resource allocation by the scheduler but just control the preference and of course the different vendors that or the different operators might set a different policies to that particular algorithm so what happens here if we remember we have a policy association offload meaning we allocate more users to more mpp users to small cells we have certain 0.3 or something if we now add the policy allocation reservation that we just mentioned we all have an outage oh of course that's a specific scenario here but we with additional x up we are basically achieving our result where the end goal is we pretty much want to decrease or increase the performance decrease the outage and then we might do that by adding x ups and by having that modularity we just have a freak it's still the same architecture we just add another x up and it's controlled by a certain policy so to the summary because it's already been an hour so to the summary using that oran approach allows to add intelligence from external entities so we might have this ix ups we have already getting the control out of the the actual base station we might control the run behavior by declarative policies which are pretty obvious if you read them it's not let's say some variable called i don't know um x 22 45 it's it's just said that traffic steering policy for that cell and that user is that or that you should avoid or prefer it's very simple it allows to combine combine various applications to realize certain objectives so we focus on certain objectives a traffic steering use case but there might be different x ups and then it allows hierarchical and modular approach to resource management so we have those hierarchy so upper layer middle layer lower layer and we separate the concerns by that and we have an um flexible and modular radio access network as we saw where we can combine the e2 nodes or have them separate [Music] so that's it thank you for attention and thank you for um being here so long and i hope uh you enjoyed it and also i'd like to thank again russell for for having me here and for having that opportunity and one final word before i give it up to to russell if you're interested in those topics and other topics related to to wireless you can check out our blog and also you can subscribe to to our newsletter there will be more and more things related to oran coming up

Channel: Rimedo Labs

Views: 5,595

Rating: 4.8778625 out of 5

Keywords: ORAN, O-RAN, 5G, RIC, RAN

Id: otlUOgwitmU

Length: 69min 0sec (4140 seconds)

Published: Sun Feb 28 2021